From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by dpdk.org (Postfix) with ESMTP id B64922BA1 for ; Mon, 11 Jul 2016 21:41:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1862; q=dns/txt; s=iport; t=1468266063; x=1469475663; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/fAURVUZUtMdE7wVk68WxREBeApIvpzq+aKwAP8xP4k=; b=HatJbskakwK918S/HoPZaLDMS1WvIT7RykV6cyie6JAFep72GHfCO3Cv RfczHd534OYFJKLcf2QhP7d1LlGITmFapkvRXuNm206priyJPcQb+DHdJ pRcl2xtQaYYh+H/Athl6GvXxwVbvHViXzgWLw17RqNWyK+d3gvX7SPz2x s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AgDe9YNX/40NJK1dgz6BUga2boIPg?= =?us-ascii?q?XqGGAKBKjgUAQEBAQEBAWUnhFwBAQUnEz8MBAIBCBEEAQEBHgkHMhQJCAIEAQ0?= =?us-ascii?q?FCIgovz4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchieETYocAQSZGAGOSo8zkA4BH?= =?us-ascii?q?jaCPIE1bohAfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,348,1464652800"; d="scan'208";a="127600138" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 19:41:02 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6BJf2dW012321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 19:41:02 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 14:41:01 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 14:41:02 -0500 From: "John Daley (johndale)" To: Olivier Matz , "dev@dpdk.org" CC: "bruce.richardson@intel.com" Thread-Topic: [dpdk-dev] [PATCH] net/enic: decrement Tx mbuf reference count before recycling Thread-Index: AQHR2WcoteaINpTbz0ixbDTSinaCHaATWC6AgABMNcA= Date: Mon, 11 Jul 2016 19:41:02 +0000 Message-ID: References: <1468016521-20280-1-git-send-email-johndale@cisco.com> <1ca338a4-a8fe-8149-2373-d02fee3199cb@6wind.com> In-Reply-To: <1ca338a4-a8fe-8149-2373-d02fee3199cb@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.2.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/enic: decrement Tx mbuf reference count before recycling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 19:41:04 -0000 > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Monday, July 11, 2016 3:04 AM > To: John Daley (johndale) ; dev@dpdk.org > Cc: bruce.richardson@intel.com > Subject: Re: [dpdk-dev] [PATCH] net/enic: decrement Tx mbuf reference > count before recycling >=20 > Hi John, >=20 > On 07/09/2016 12:22 AM, John Daley wrote: > > In the Tx cleanup function, the reference count in mbufs to be > > returned to the pool should to be decremented before they are > > returned. Decrementing is not done by rte_mempool_put_bulk() so it > > must be done separately using __rte_pktmbuf_prefree_seg(). > > If decrementing does not result in a 0 reference count the mbuf is not > > returned to the pool and whatever has the last reference is > > responsible for freeing. > > > > Fixes: 36935afbc53c ("net/enic: refactor Tx mbuf recycling") > > Reviewed-by: Nelson Escobar > > Signed-off-by: John Daley > > --- > > Since reference counts are set to 0 when mbufs are reallocated from > > the pool, and sending packets with reference count not equal to 1 is > > probably an application error, this patch may not be critical. But a > > debug ASSERT caught it and it would be nice to have it fixed in 16.07. >=20 > Sending a packet with refcnt !=3D 1 is not an error. It can happen when u= sing > mbuf clones. So indeed it would be better to have in 16.07. >=20 > For the same reason, I also wonder if enic_free_wq_buf() should also be > updated with: >=20 > - rte_mempool_put(mbuf->pool, mbuf); > + rte_pktmbuf_free(mbuf); That is a very good point, thank you. I'll use rte_pktmubf_free_seg(mbuf) t= hough, since we are walking an array of all mbuf segments. V2 coming moment= arily. -john >=20 >=20 > Regards, > Olivier