> I wonder if anyone has actually benchmarked this. Yes. And you forgot to add in the IP/TCP 4 byte long options as well.
> given that it also takes a few cycles for skb_reserve to increment > to pointers in struct sk_buff. But, OK, I guess it makes sense if > actually does save time on average. Basically its going to cost 1 clock and its a live dirty L1 line anyway. > >let the driver writer to take care the future skb_reserve() will be > >4 (or 8 or whatever) bytes alignedex. > >It might even make sense to be L1 cahe line aligned... > > Yes. What I would like even more is an alloc_skb variant > that would take the net_device as a parameter and perhaps an indication > about whether the sk_buff was going to be used for sending or receiving. The only thing that knows the needed alignment is the driver. So it makes no sense to do it another way > This wrapper could then look at a precomputed field in net_device that > would specificy optimal alignment, based on where the packet was going The wrapper would make everything slower, constrain devices to its API and the like. Midlayer crap does not work. If there is one thing we have learned again and again that is it. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
