On Sun, Aug 13, 2006 at 05:04:31PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
> Hello!
>
> > E1000 wants 16K buffers for jumbo MTU settings.
> >
> > The reason is that the chip can only handle power-of-2 buffer
> > sizes, and next hop from 9K is 16K.
>
> Let it use pages. Someone should start. :-)
>
> High order allocations are disaster in any case.
>
>
> > If we store raw kmalloc buffers, we cannot attach them to an arbitrary
> > skb because of skb_shared_info(). This is true even if we
> > purposefully allocate the necessary head room for these kmalloc based
> > buffers.
>
> I still do not see. For non-SG paths, you have to keep header and data
> together, you just do not need anything clever. And it does not look
> like you can. If you have a fixed space for header, you already have
> a space for refcnt to make skb_shared_info().
>
> For SG paths, TCP_PAGE() seems to be enough and even better than
> kmalloc()ed buffers.
What if we will store array of pages and in shared info
just like we have right now. So there will only one destructor.
e1000 will setup head/data/tail pointers to point to the area in the
first sg page.
Those drivers which do not have sg support can use head/data pointers
like before, but destructor should be changed in that case.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
