Ramsay, Lincoln <lincoln.ram...@digi.com> wrote: [ patch looks good to me, I have no further comments ]
> > For build_skb path to work the buffer scheme would need to be changed > > to reserve headroom, so yes, I think that the proposed patch is the > > most convenient solution. > > I don't know about benefits/feasibility, but I did wonder if (in the event > that the "fast path" is possible), the dma_mapping could use an offset? The > page would include the skb header but the dma mapping would not. If that was > done though, only 1 RX frame would fit into the page (at least on my system, > where the RX frame seems to be 2k and the page is 4k). Also, there's a > possibility to set the "order" variable, so that multiple pages are created > at once and I'm not sure if this would work in that case. Yes, this is what some drivers do, they allocate a page, pass pageaddr + headroom_offset everywhere, except build_skb() which gets the pageaddr followed by skb_reserve(skb, headroom_offset). > > This only copies the initial part and then the rest is added as a frag. > > Oh yeah. That's not as bad as I had thought then :) > > I wonder though... if the "fast path" is possible, could the whole packet > (including header) be added as a frag, avoiding the header copy? Or is that > not how SKBs work? No, you can either have skb->head point to the page (build_skb), or skb->head needs to be kmalloc'd (napi_alloc_skb for example). Both can have page frags. In the second case, at least L2 header needs to be in skb->head (and ip stack would pull in L3 header as well later on anyway).
