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 6313AA00E6 for ; Wed, 12 Jun 2019 05:21:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E64791D108; Wed, 12 Jun 2019 05:21:13 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 2361E1D107 for ; Wed, 12 Jun 2019 05:21:11 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2019 20:21:11 -0700 X-ExtLoop1: 1 Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.110.186]) by fmsmga005.fm.intel.com with ESMTP; 11 Jun 2019 20:21:09 -0700 Date: Wed, 12 Jun 2019 18:03:39 +0800 From: Ye Xiaolong To: William Tu Cc: Qi Zhang , John McNamara , Marko Kovacevic , Karlsson Magnus , Topel Bjorn , dev@dpdk.org Message-ID: <20190612100339.GA32720@intel.com> References: <20190515083842.15116-1-xiaolong.ye@intel.com> <20190530090707.36290-1-xiaolong.ye@intel.com> <20190530090707.36290-2-xiaolong.ye@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v2 1/3] net/af_xdp: enable zero copy by extbuf 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" Hi, On 06/11, William Tu wrote: [snip] >> @@ -294,16 +326,26 @@ eth_af_xdp_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) >> >> desc = xsk_ring_prod__tx_desc(&txq->tx, idx_tx + i); >> mbuf = bufs[i]; >> - >> - desc->addr = (uint64_t)addrs[i]; >> desc->len = mbuf->pkt_len; >> - pkt = xsk_umem__get_data(umem->mz->addr, >> - desc->addr); >> - rte_memcpy(pkt, rte_pktmbuf_mtod(mbuf, void *), >> - desc->len); >> - tx_bytes += mbuf->pkt_len; >> >> - rte_pktmbuf_free(mbuf); >> + /* >> + * We need to make sure the external mbuf address is within >> + * current port's umem memzone range >> + */ >> + if (pmd_zc && RTE_MBUF_HAS_EXTBUF(mbuf) && >> + in_umem_range(umem, (uint64_t)mbuf->buf_addr)) { >> + desc->addr = (uint64_t)mbuf->buf_addr - >> + umem->mz->addr_64; >> + mbuf->buf_addr = xsk_umem__get_data(umem->mz->addr, >> + (uint64_t)addrs[i]); >> + } else { >> + desc->addr = (uint64_t)addrs[i]; >> + pkt = xsk_umem__get_data(umem->mz->addr, >> + desc->addr); >> + rte_memcpy(pkt, rte_pktmbuf_mtod(mbuf, void *), >> + desc->len); >> + } >> + tx_bytes += mbuf->pkt_len; >> } >> >> xsk_ring_prod__submit(&txq->tx, nb_pkts); >> @@ -313,6 +355,9 @@ eth_af_xdp_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) >> txq->stats.tx_pkts += nb_pkts; >> txq->stats.tx_bytes += tx_bytes; >> >> + for (i = 0; i < nb_pkts; i++) >> + rte_pktmbuf_free(bufs[i]); >> + > >Is it ok to free the mbuf here? >If the AF_XDP is running pmd_zc=true, the packet mbuf is still in the tx >ring and might not be sent out yet. For pmd_zc=ture case, here mbuf->buf_addr has been exchanged to available addr dequeued from umem->buf_ring, rte_pktmbuf_free would just call the free callback umem_buf_release_to_fq to enqueue the addr to the buf_ring. Thanks, Xiaolong > >Regards, >William >