From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 116DDA00E6 for ; Wed, 20 Mar 2019 10:22:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B57E4493D; Wed, 20 Mar 2019 10:22:36 +0100 (CET) Received: from mail-vk1-f196.google.com (mail-vk1-f196.google.com [209.85.221.196]) by dpdk.org (Postfix) with ESMTP id 076BA493D for ; Wed, 20 Mar 2019 10:22:35 +0100 (CET) Received: by mail-vk1-f196.google.com with SMTP id x140so371207vke.5 for ; Wed, 20 Mar 2019 02:22:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KX+jfN4oagA2zgUEqzdDRjzPY+v3jEjem6wYbJ7/oaU=; b=DowbU+rULAvM/rQSb2WFBzuT+yMrnagBCrs64IHZIScsWpHcsRLNahOivLLkGQBpod tU6uHivR/aMP/rm/IWDtO/d20YYzBdTNiDH+wpn/vzdRkK40oWv9YgUlPJJ9fi4NLYz+ 0ztyVNKW9637M2W3n0tfPI2YFqVA+xrYa6BxAUjVMUMaW22vcT1GWJhx+09f+MgoqPHp Cqz3GqlNjTcW9V5UGPCaqU9XgDKCW3ypwplVa5hv82MW4+ncUpt/7mFL9CpjXjaMqg4M 9eRmy/x54a5StzDrHZLueSK+5Sl6kmpznJBUf+4PsPjnj5QvUy5Y9UKOYCIzSS5Pz8tj jVNA== X-Gm-Message-State: APjAAAXvu0vsVam1lkfivtYr9rqZXQzA1GoHgflOkvqBiPlELg9OabQQ Ar3iPWgfnWvoEoHhwL4hmqTla9omI8Ybif0Vi0tj2g== X-Google-Smtp-Source: APXvYqwdZlI7sdXnQeT58I/1TdBUa45d5lXEclb7lZE8uq8n4xIrLm7odSvIH7f7ipONYZ8p64iJAPNip+JbdLl5Ocs= X-Received: by 2002:a1f:7d4e:: with SMTP id y75mr830414vkc.53.1553073754243; Wed, 20 Mar 2019 02:22:34 -0700 (PDT) MIME-Version: 1.0 References: <20190301080947.91086-1-xiaolong.ye@intel.com> <20190319071256.26302-1-xiaolong.ye@intel.com> <20190319071256.26302-6-xiaolong.ye@intel.com> In-Reply-To: <20190319071256.26302-6-xiaolong.ye@intel.com> From: David Marchand Date: Wed, 20 Mar 2019 10:22:23 +0100 Message-ID: To: Xiaolong Ye Cc: dev , Qi Zhang , Karlsson Magnus , Topel Bjorn Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 5/6] net/af_xdp: enable zero copy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190320092223.vQcBzTxIOkbPpoU95R_4wvJLXg40ni6PENPnBU9x4AI@z> On Tue, Mar 19, 2019 at 8:17 AM Xiaolong Ye wrote: > Try to check if external mempool (from rx_queue_setup) is fit for > af_xdp, if it is, it will be registered to af_xdp socket directly and > there will be no packet data copy on Rx and Tx. > > Signed-off-by: Xiaolong Ye > --- > drivers/net/af_xdp/rte_eth_af_xdp.c | 128 ++++++++++++++++++++-------- > 1 file changed, 91 insertions(+), 37 deletions(-) > > diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c > b/drivers/net/af_xdp/rte_eth_af_xdp.c > index fc60cb5c5..c22791e51 100644 > --- a/drivers/net/af_xdp/rte_eth_af_xdp.c > +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c > @@ -62,6 +62,7 @@ struct xsk_umem_info { > struct xsk_umem *umem; > struct rte_mempool *mb_pool; > void *buffer; > + uint8_t zc; > }; > > struct pkt_rx_queue { > @@ -76,6 +77,7 @@ struct pkt_rx_queue { > > struct pkt_tx_queue *pair; > uint16_t queue_idx; > + uint8_t zc; > }; > > struct pkt_tx_queue { > @@ -191,17 +193,24 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs, > uint16_t nb_pkts) > uint32_t len = xsk_ring_cons__rx_desc(rx, idx_rx++)->len; > char *pkt = xsk_umem__get_data(rxq->umem->buffer, addr); > > - mbuf = rte_pktmbuf_alloc(rxq->mb_pool); > - if (mbuf) { > - memcpy(rte_pktmbuf_mtod(mbuf, void*), pkt, len); > + if (rxq->zc) { > + mbuf = addr_to_mbuf(rxq->umem, addr); > rte_pktmbuf_pkt_len(mbuf) = > rte_pktmbuf_data_len(mbuf) = len; > - rx_bytes += len; > bufs[count++] = mbuf; > } else { > - dropped++; > + mbuf = rte_pktmbuf_alloc(rxq->mb_pool); > + if (mbuf) { > + memcpy(rte_pktmbuf_mtod(mbuf, void*), pkt, > len); > + rte_pktmbuf_pkt_len(mbuf) = > + rte_pktmbuf_data_len(mbuf) = len; > + rx_bytes += len; > + bufs[count++] = mbuf; > + } else { > + dropped++; > + } > + rte_pktmbuf_free(addr_to_mbuf(umem, addr)); > } > - rte_pktmbuf_free(addr_to_mbuf(umem, addr)); > } > Did not understand how the zc parts are working, but at least looking at the rx_burst function, when multi q will be supported, is there any reason we would have zc enabled on one rxq and not others? If the answer is that we would have either all or none rxq with zc, we could have dedicated rx_burst functions and avoid this per mbuf test on rxq->zc. For the tx part, I don't understand the relation between rx and tx. Should not the zc capability be global to the ethdev port ? You might also want to look at "simple" tx burst functions like in i40e so that you only need to look at the first mbuf to check its originating pool. -- David Marchand