From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Kirsher Subject: Re: [Intel-wired-lan] [RFC PATCH bpf-next 00/12] AF_XDP, zero-copy support Date: Wed, 16 May 2018 11:14:49 -0700 Message-ID: <2af597cb63e5211ab76c1fef75cb294d6fe88bc0.camel@intel.com> References: <20180515190615.23099-1-bjorn.topel@gmail.com> <20180516170427.7jq74odw62myg55x@ast-mbp> Reply-To: jeffrey.t.kirsher@intel.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-kp1Bs28URIY8OnDAEjkq" Cc: willemdebruijn.kernel@gmail.com, daniel@iogearbox.net, ast@fb.com, netdev@vger.kernel.org, qi.z.zhang@intel.com, mst@redhat.com, michael.lundkvist@ericsson.com, intel-wired-lan@lists.osuosl.org, brouer@redhat.com, =?ISO-8859-1?Q?Bj=F6rn_T=F6pel?= , magnus.karlsson@gmail.com, magnus.karlsson@intel.com To: Alexei Starovoitov , =?ISO-8859-1?Q?Bj=F6rn_T=F6pel?= Return-path: Received: from mga11.intel.com ([192.55.52.93]:17991 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbeEPSN3 (ORCPT ); Wed, 16 May 2018 14:13:29 -0400 In-Reply-To: <20180516170427.7jq74odw62myg55x@ast-mbp> Sender: netdev-owner@vger.kernel.org List-ID: --=-kp1Bs28URIY8OnDAEjkq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2018-05-16 at 10:04 -0700, Alexei Starovoitov wrote: > On Tue, May 15, 2018 at 09:06:03PM +0200, Bj=C3=B6rn T=C3=B6pel wrote: > >=20 > > Alexei had two concerns in conjunction with adding ZC support to > > AF_XDP: show that the user interface holds and can deliver good > > performance for ZC and that the driver interfaces for ZC are good. > > We > > think that this patch set shows that we have addressed the first > > issue: performance is good and there is no change to the uapi. But > > please take a look at the code and see if you like the ZC > > interfaces > > that was the second concern. >=20 > Looks like we're not on the same page with definition of 'uapi'. > Here you're saying that patches demonstrate performance without > a change to uapi, whereas patch 1 does remove rebind support > which _is_ a change to uapi. > That was exactly my concern with the previous set. >=20 > The other restrictions that are introduced in this patch set > are actually ok: > - like in patch 12: 'no redirect to an AF_XDP enabled XDP Tx ring' > this is fine, since this restriction can be lifted later without > breaking uapi > - patch 11: 'No passing to the stack via XDP_PASS' > also fine, since can be addressed later. >=20 > > To do for this RFC to become a patch set: > >=20 > > * Implement dynamic creation and deletion of queues in the i40e > > driver >=20 > can be deferred, no? >=20 > > * Properly splitting up the i40e changes >=20 > Imo patch 11 and 12 are reasonable in terms of size > and reviewable as-is. I don't think they have to be split. > Would be nice though. > =20 > > * Have the Intel NIC team review the i40e changes from at least an > > architecture point of view >=20 > As Alexander pointed out in patch 11, if you split it into > separate file the changes to i40e core become pretty small and > I think Intel folks (Jeff, Alexander, ...) will be ok if we merge > this set via bpf-next tree asap and clean up, refactor, share > more code with i40e core later. I am fine with the i40e changes in this series go through the BPF tree, since majority of the series is BPF changes. We just need to address Alex's comments on patch 11 & 12. I only have 1-2 patches currently in my queue against i40e and they are not affected by the changes in this series, so Dave should not have any merge issues when pulling. > > * Implement a more fair scheduling policy for multiple XSKs that > > share > > an umem for TX. This can be combined with a batching API for > > xsk_umem_consume_tx. >=20 > can be deferred too? >=20 > I think the first 10 patches in this set is a hard dependency on i40e > patches, so the whole thing have to reviewed and landed together. > May be the first 5 patches can be applied already. >=20 > Anyway at this point I still think that removing AF_XDP and bpf > xskmap > from uapi is necessary before the merge window, unless this patch set > (including i40e changes can land right now). > Also I'd like to see another NIC vendor demonstrating RFC for ZC as > well. > The allocator api looks good and I don't anticipate issues, but still > I think it's necessary to make sure that we're not adding i40e-only > feature. >=20 > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan@osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan --=-kp1Bs28URIY8OnDAEjkq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiTyZWz+nnTrOJ1LZ5W/vlVpL7c4FAlr8dRkACgkQ5W/vlVpL 7c6XyA//Ygz/BvzOXholz7ynTZs08d+VUzEeoH3iPcA6aZZlsBP4V7YzrIcraT5V bgrUjrcwIj3r2L3iq87VUG7rfkK884fkWXN2d+MJxBmTWWNaO6EBYgnJ40vkrXo3 hgrRG4UtXaw0ykG/0YcOBzSgCHLEnUDfQ95g7wEDcGFo6dI6LH9xXdBvjWAcskW2 ajfNJ736udhXibRarsKTIwt1xn27XoIxQVGQQkEoXvlRigehLvPcxXHVc4tWJ6u0 DvQxHKBIPU2vKWN2RNDlVECO25E15BhuKc9oiZsJr/ucxOafXVM5ACNo/z4ubicC kXRqhcFDsIr/J6r11+CJhu15TDFvds9CLcMk0CgoCX+xN9f/RTCDHIrPRB8eTcfa kp5DpACdCOWQjjUyDIQunkKAOTR8D61wkf75+ByoIR2n0HcAUTMXngRiKjD3wKEN Dy2SuoPqX4WAR4eePJfWPmoq0MQu0rsw4L8yEdvOhD1lx+f8Ucn0x/UYHdoCazl0 1HcKUkyCox3VViraTITl9FXIBFC6JcqXMwi8JG7FqLWqvEqwquwD16n3985C2lY0 crSrEg4vUfME5okoBXeBvw3celchfNihJfrHAr0oXVz8ZKe6HrCTXqWt6NTAI7+s ObLaBpPDMeYJl+Xprfiwp6Dwpa9cEEHHyvzHbzdM7ORJbn563Ow= =HylU -----END PGP SIGNATURE----- --=-kp1Bs28URIY8OnDAEjkq--