On 11/13/2017 09:33 PM, Björn Töpel wrote: > 2017-11-14 0:50 GMT+01:00 Alexei Starovoitov <a...@fb.com>: >> On 11/13/17 9:07 PM, Björn Töpel wrote: >>> >>> 2017-10-31 13:41 GMT+01:00 Björn Töpel <bjorn.to...@gmail.com>: >>>> >>>> From: Björn Töpel <bjorn.to...@intel.com> >>>> >>> [...] >>>> >>>> >>>> We'll do a presentation on AF_PACKET V4 in NetDev 2.2 [1] Seoul, >>>> Korea, and our paper with complete benchmarks will be released shortly >>>> on the NetDev 2.2 site. >>>> >>> >>> We're back in the saddle after an excellent netdevconf week. Kudos to >>> the organizers; We had a blast! Thanks for all the constructive >>> feedback. >>> >>> I'll summarize the major points, that we'll address in the next RFC >>> below. >>> >>> * Instead of extending AF_PACKET with yet another version, introduce a >>> new address/packet family. As for naming had some name suggestions: >>> AF_CAPTURE, AF_CHANNEL, AF_XDP and AF_ZEROCOPY. We'll go for >>> AF_ZEROCOPY, unless there're no strong opinions against it. >>> >>> * No explicit zerocopy enablement. Use the zeropcopy path if >>> supported, if not -- fallback to the skb path, for netdevs that >>> don't support the required ndos. Further, we'll have the zerocopy >>> behavior for the skb path as well, meaning that an AF_ZEROCOPY >>> socket will consume the skb and we'll honor skb->queue_mapping, >>> meaning that we only consume the packets for the enabled queue. >>> >>> * Limit the scope of the first patchset to Rx only, and introduce Tx >>> in a separate patchset. >> >> >> all sounds good to me except above bit. >> I don't remember people suggesting to split it this way. >> What's the value of it without tx? >> > > We definitely need Tx for our use-cases! I'll rephrase, so the > idea was making the initial patch set without Tx *driver* > specific code, e.g. use ndo_xdp_xmit/flush at a later point. > > So AF_ZEROCOPY, the socket parts, would have Tx support. > > @John Did I recall that correctly? >
Yep, that is what I said. However, on second thought, without the driver tx half I guess tx will be significantly slower. So in order to get the driver API correct in the first go around lets implement this in the first series as well. Just try to minimize the TX driver work as much as possible. Thanks, John
