From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 20A17A0577; Tue, 7 Apr 2020 18:08:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 02A3C1BF02; Tue, 7 Apr 2020 18:08:19 +0200 (CEST) Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by dpdk.org (Postfix) with ESMTP id 066812BD8 for ; Tue, 7 Apr 2020 18:08:18 +0200 (CEST) Received: by mail-pj1-f67.google.com with SMTP id q16so1270290pje.1 for ; Tue, 07 Apr 2020 09:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LkMYqPL35si8joe3DcV/c8oqFFCzrnU6KMmLZd8LlPs=; b=IImEo9csqseS/mvkQzr9RuDxWzCTxKALyKdTX66ei1xTM/9CZxtTQCROPKWxQ/r8EQ VF6XCfNYmRrtN2Nt28oGX0E5Uo/xwuR7lh4FtZjbp+U1+qtSNxS19pLGPrXDC+qpmu3Y zdcK6jvR4i/QAiwAQaNUv0xbhJWQJbPEDfjBL9R2jEOh8z28dtF2oIwxxub020Tqmaze Pz2iObF7hKljLSvevbh0IDrANCw784A7KTVsh8hPz0XXgbgaP3yCGPUFzbIOHodXBmoP x8PCgiFR7ukYKKd+Hvn/3q1NVy1DODyV1Y9yDxvu7nmGnhBQ88F9z1FNvfHgiWMZUs3w NwZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LkMYqPL35si8joe3DcV/c8oqFFCzrnU6KMmLZd8LlPs=; b=M+/EnXEDv1iIPiTkXxEEg0DA3G09ZjgZ1+aOIbsu+FFth6kKfxSpPd64bf/+clNBf8 HvQJImWEEO96POh/MqYI1GecViBAzbNac6zo8rdGgT9cKlTiybExLiR5KJqC/8roq4i8 U5w8VuX0tkXIkiDduMt4iwSUXV2ssG5uE5QGkC8M8gn8RYKJv2EECQMeCZuTdOCjICCx eBC/m1F/jH8uZG4vNZQNmAMid/QaePrYo/c09YEkwukb/vPykmsqXJ+AyTp9RrqHMWmZ 6xyNPHvxK5nf2J2c1Isc7lOD6PnBRbNEW4KFRJb5hNcnQn22HwQQSuoMyEZonNPBiyH4 1Z3A== X-Gm-Message-State: AGi0PuYlDjsuszoU/izXjXxcM67UTEq3L9dhTW7/h1XhM5eMd9doBcB9 NOdiWDHbsizN2Ao295O8BqpSLw== X-Google-Smtp-Source: APiQypIHJyyhxIgPa6gQsoiq10qakGTt0pLcFplSQXYunPttKFquPbXgLhVsDeSL/2c4DJjVDuha+Q== X-Received: by 2002:a17:90b:14cf:: with SMTP id jz15mr92167pjb.36.1586275697123; Tue, 07 Apr 2020 09:08:17 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id r4sm1664941pgi.6.2020.04.07.09.08.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 09:08:16 -0700 (PDT) Date: Tue, 7 Apr 2020 09:08:05 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: wangyunjian , dev@dpdk.org, keith.wiles@intel.com, jerry.lilijun@huawei.com, xudingke@huawei.com, stable@dpdk.org Message-ID: <20200407090805.6941a61b@hermes.lan> In-Reply-To: References: <1586233383-1084-1-git-send-email-wangyunjian@huawei.com> <7da1388e-c4c6-27d5-f038-0526a39d9a8c@intel.com> <20200407083846.674ca9e4@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v3 3/5] net/tap: fix check for mbuf's nb_segs failure 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" On Tue, 7 Apr 2020 16:45:59 +0100 Ferruh Yigit wrote: > On 4/7/2020 4:38 PM, Stephen Hemminger wrote: > > On Tue, 7 Apr 2020 16:15:16 +0100 > > Ferruh Yigit wrote: > > > >>> +static void > >>> +tap_rxq_pool_free(struct rte_mbuf *pool) > >>> +{ > >>> + struct rte_mbuf *mbuf = pool; > >>> + uint16_t nb_segs = 1; > >>> + > >>> + if (mbuf == NULL) > >>> + return; > >>> + > >>> + while (mbuf->next) { > >>> + mbuf = mbuf->next; > >>> + nb_segs++; > >>> + } > >>> + pool->nb_segs = nb_segs; > >>> + rte_pktmbuf_free(pool); > >>> +} > > > > Since mbuf is going to be free, why bother with nb_segs. > > Since rte_pktmbuf_free takes NULL as an argument, and frees the m->next chain > > I don't see why not just > > rte_pktmbuf_free(pool) > > > > Chain is not constructed properly, 'nb_segs' is wrong, only 'rte_pktmbuf_free()' > call won't free all the chain but first mbuf. > > This implementation is fixing 'nb_segs' sot that 'rte_pktmbuf_free()' can work > as you suggested. > > Or I suggest iterate the list and fix all mbufs, instead of fixing 'nb_segs', > this may be one iteration less. If you look at implementation of rte_pktmbuf_free() in current DPDK version it does not care what nb_segs is set to.