Date:   Tue, 5 Jun 2018 10:44:40 +0200
From:   Björn Töpel <bjorn.topel@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        David Miller <davem@...emloft.net>,
        Björn Töpel <bjorn.topel@...el.com>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>, ast@...nel.org,
        Daniel Borkmann <borkmann@...earbox.net>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Netdev <netdev@...r.kernel.org>
Subject: Re: AF_XDP. Was: [net-next 00/12][pull request] Intel Wired LAN
 Driver Updates 2018-06-04

Den tis 5 juni 2018 kl 03:46 skrev Alexander Duyck <alexander.duyck@...il.com>:
>
> On Mon, Jun 4, 2018 at 4:32 PM, Alexei Starovoitov
> <alexei.starovoitov@...il.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@...emloft.net> wrote:
> >> > From: Or Gerlitz <gerlitz.or@...il.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.

Thanks for spending time on our work. Very much appreciated!


Björn

> Thanks.
>
> - Alex

Powered by blists - more mailing lists