On Tue, 21 Feb 2017 14:54:35 -0800 Tom Herbert <t...@herbertland.com> wrote: > On Tue, Feb 21, 2017 at 2:29 PM, Saeed Mahameed <sae...@dev.mellanox.co.il> > wrote: [...] > > The only complexity XDP is adding to the drivers is the constrains on > > RX memory management and memory model, calling the XDP program itself > > and handling the action is really a simple thing once you have the > > correct memory model.
Exactly, that is why I've been looking at introducing a generic facility for a memory model for drivers. This should help simply drivers. Due to performance needs this need to be a very thin API layer on top of the page allocator. (That's why I'm working with Mel Gorman to get more close integration with the page allocator e.g. a bulking facility). > > Who knows! maybe someday XDP will define one unified RX API for all > > drivers and it even will handle normal stack delivery it self :). > > > That's exactly the point and what we need for TXDP. I'm missing why > doing this is such rocket science other than the fact that all these > drivers are vastly different and changing the existing API is > unpleasant. The only functional complexity I see in creating a generic > batching interface is handling return codes asynchronously. This is > entirely feasible though... I'll be happy as long as we get a batching interface, then we can incrementally do the optimizations later. In the future, I do hope (like Saeed) this RX API will evolve into delivering (a bulk of) raw-packet-pages into the netstack, this should simplify drivers, and we can keep the complexity and SKB allocations out of the drivers. To start with, we can play with doing this delivering (a bulk of) raw-packet-pages into Tom's TXDP engine/system? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
