Re: [RFC PATCH 00/14] Introducing AF_PACKET V4 support

[John Fastabend <john.fastabend@gmail.com>]

On 11/13/2017 05:07 AM, Björn Töpel wrote:
> 2017-10-31 13:41 GMT+01:00 Björn Töpel <bjorn.topel@gmail.com>:
>> From: Björn Töpel <bjorn.topel@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.
> 

Works for me.

> * 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.
> 
> * Minimize the size of the i40e zerocopy patches, by moving the driver
>   specific code to separate patches.
> 
> * Do not introduce a new XDP action XDP_PASS_TO_KERNEL, instead use
>   XDP redirect map call with ingress flag.
> 

Sounds good we will need to add this as a separate patch series though.

> * Extend the XDP redirect to support explicit allocator/destructor
>   functions. Right now, XDP redirect assumes that the page allocator
>   was used, and the XDP redirect cleanup path is decreasing the page
>   count of the XDP buffer. This assumption breaks for the zerocopy
>   case.
> 

Probably sync with Andy and Jesper on this. I think they are both
looking into something similar.

Thanks,
John

> 
> Björn
> 
>