Re: AF_XDP. Was: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-06-04

[Daniel Borkmann <daniel@iogearbox.net>]

On 06/05/2018 10:44 AM, Björn Töpel wrote:
> Den tis 5 juni 2018 kl 03:46 skrev Alexander Duyck <alexander.duyck@gmail.com>:
>> On Mon, Jun 4, 2018 at 4:32 PM, Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>>> On Mon, Jun 04, 2018 at 03:02:31PM -0700, Alexander Duyck wrote:
>>>> On Mon, Jun 4, 2018 at 2:27 PM, David Miller <davem@davemloft.net> wrote:
>>>>> From: Or Gerlitz <gerlitz.or@gmail.com>
>>>>> Date: Tue, 5 Jun 2018 00:11:35 +0300
>>>>>
>>>>>> Just to make sure, is the AF_XDP ZC (Zero Copy) UAPI going to be
>>>>>> merged for this window -- AFAIU from [1], it's still under
>>>>>> examination/development/research for non Intel HWs, am I correct or
>>>>>> this is going to get in now?
>>>>>
>>>>> All of the pending AF_XDP changes will be merged this merge window.
>>>>>
>>>>> I think Intel folks need to review things as fast as possible because
>>>>> I pretty much refuse to revert the series or disable it in Kconfig at
>>>>> this point.
>>>>>
>>>>> Thank you.
>>>>
>>>> My understanding of things is that the current AF_XDP patches were
>>>> going to be updated to have more of a model agnostic API such that
>>>> they would work for either the "typewriter" mode or the descriptor
>>>> ring based approach. The current plan was to have the zero copy
>>>> patches be a follow-on after the vendor agnostic API bits in the
>>>> descriptors and such had been sorted out. I believe you guys have the
>>>> descriptor fixes already right?
>>>>
>>>> In my opinion the i40e code isn't mature enough yet to really go into
>>>> anything other than maybe net-next in a couple weeks. We are going to
>>>> need a while to get adequate testing in order to flush out all the
>>>> bugs and performance regressions we are likely to see coming out of
>>>> this change.
>>>
>>> I think the work everyone did in this release cycle increased my confidence
>>> that the way descriptors are defined and the rest of uapi are stable enough
>>> and i40e zero copy bits can land in the next release without uapi changes.
>>> In that sense even if we merge i40e parts now, the other nic vendors
>>> will be in the same situation and may find things that they would like
>>> to improve in uapi.
>>> So I propose we merge the first 7 patches of the last series now and
>>> let 3 remaining i40e patches go via intel trees for the next release.
>>> In the mean time other NIC vendors should start actively working
>>> on AF_XDP support as well.
>>> If somehow uapi would need tweaks, we can still do minor adjustments
>>> since 4.18 won't be released for ~10 weeks.
>>
>> That works for me. Actually I think patch 11 can probably be included
>> as well since that is just sample code and could probably be used by
>> whatever drivers end up implementing this.
> 
> The approach suggested by Alexei and Alex sounds good to us. Alex's
> review items are very much valid, and require more time to address.
> Therefore addressing i40e in the next merge windows sounds like a
> great idea.
> 
> As Alex suggests, including patch 11 together with the first seven makes sense.

Ok with it as well, and I've pushed just that, thanks everyone!