From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH bpf-next v2 0/5] xsk: fix bug when trying to use both copy and zero-copy mode Date: Mon, 1 Oct 2018 13:31:46 -0700 Message-ID: <20181001133146.1b8f3810@cakuba.netronome.com> References: <1538398297-14862-1-git-send-email-magnus.karlsson@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bjorn.topel@intel.com, ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, Jesper Dangaard Brouer To: Magnus Karlsson Return-path: Received: from mail-qk1-f193.google.com ([209.85.222.193]:44486 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbeJBDLY (ORCPT ); Mon, 1 Oct 2018 23:11:24 -0400 Received: by mail-qk1-f193.google.com with SMTP id y8-v6so1614077qka.11 for ; Mon, 01 Oct 2018 13:31:51 -0700 (PDT) In-Reply-To: <1538398297-14862-1-git-send-email-magnus.karlsson@intel.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 1 Oct 2018 14:51:32 +0200, Magnus Karlsson wrote: > Jakub, please take a look at your patches. The last one I had to > change slightly to make it fit with the new interface > xdp_get_umem_from_qid(). An added bonus with this function is that we, > in the future, can also use it from the driver to get a umem, thus > simplifying driver implementations (and later remove the umem from the > NDO completely). Bj=C3=B6rn will mail patches, at a later point in time, > using this in the i40e and ixgbe drivers, that removes a good chunk of > code from the ZC implementations.=20 Nice, drivers which don't follow the prepare/commit model of handling reconfigurations will benefit! > I also made your code aware of Tx queues. If we create a socket that > only has a Tx queue, then the queue id will refer to a Tx queue id > only and could be larger than the available amount of Rx queues. > Please take a look at it. The semantics of Tx queue id are slightly unclear. To me XDP is associated with Rx, so the qid in driver context can only refer to=20 Rx queue and its associated XDP Tx queue. It does not mean the Tx queue stack uses, like it does for copy fallback. If one doesn't have a Rx queue $id, there will be no associated XDP Tx queue $id (in all drivers but Intel, and virtio, which use per-CPU Tx queues making TX queue even more meaningless). Its to be seen how others implement AF_XDP. My general feeling is that we should only talk about Rx queues in context of driver XDP.=20