lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 4 Jun 2018 16:32:25 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Björn Töpel <bjorn.topel@...el.com>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        Alexei Starovoitov <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: AF_XDP. Was: [net-next 00/12][pull request] Intel Wired LAN Driver
 Updates 2018-06-04

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ