From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 03CB7A0350 for ; Tue, 1 Mar 2022 18:05:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D804D40DF6; Tue, 1 Mar 2022 18:05:12 +0100 (CET) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by mails.dpdk.org (Postfix) with ESMTP id 9BBE340DF6 for ; Tue, 1 Mar 2022 18:05:11 +0100 (CET) Received: by mail-pf1-f173.google.com with SMTP id x18so14798069pfh.5 for ; Tue, 01 Mar 2022 09:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wrExJCLy9NshyM5YmdDbRN7nL5P43eVAk8BkjbTFlcs=; b=4ni0o394MiR8uLHqPM/X7gdsphuEfdwDX/rdXhTLMupb6M4O5NyHsB3TIvJoHqAH8i Yvtsoc5cKbAew8XYe6qHYxzICaDyM13jQ7ZcWKqEDLnZCrhXekZ3Qj8tbjr8Yk0X6gEM VdMtFLFdfyh6leE9fYXhP/pgs8Fuq5jseVCTgLdqbvZICfH9l9v8HrqF196jf8U6YcF1 Nqdrwudpt3fCGAd6ql3NQPo+i4/eMRxeC8+Qgc0PnzL1tTz9ZqjoC0XOnC7GK6ywXb3w K8alWc4+DzfXak0VCnLITu8wd5/5sbtYNmxyVqI/kDYQx06jGcxwsTK0FI1gLFUXCvkP cY6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wrExJCLy9NshyM5YmdDbRN7nL5P43eVAk8BkjbTFlcs=; b=RjJ0qw/hjttfzDGiJ+aimlcv/xkeA/Y9S4Ql7PQIKi3S+M+aAnvLtRRrwgBxVnhs8g RnzPXnYjSMDH6/xBESi+nBQRD6+adS6TLu38n7kRCYqL3QtbOfRjgEvuuspzWQ2b4hr1 XOM5Y0COOmeXuhYGDZsP343Z7Rl3uZpEpeKRc/Jhi2IyF0KWyY9euTEDUjIhTKqymNb9 kzzRv/EWy4Eukw8UrbaNkcpaFT1BwHh/DDacRQwIBMNmbigdHiKwzjUg6GWcHkXJgIiH 5fkfxz/VMkEHRg+mXU+F8XiT2K4bXTwYrRWfQ/vTvb4Pxuu+SWNaDCPTrK7J3CTAccSu yZVA== X-Gm-Message-State: AOAM532B5pF0v0toVor0d66eyjDLg1isy+Ii2nHzmc/jZslmw0WS7rpJ fjsvciB0J5V4QCccz0RtLx1rjA== X-Google-Smtp-Source: ABdhPJxZom3Z9ds/p+m8hWbkBe2dwK9/wxyot35uOHx+ZMvzFeBoDBlguesH2UX7c7ZUXu/ddvTGjw== X-Received: by 2002:a05:6a00:8cc:b0:4cb:b981:2676 with SMTP id s12-20020a056a0008cc00b004cbb9812676mr28487166pfu.5.1646154310773; Tue, 01 Mar 2022 09:05:10 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id kb6-20020a17090ae7c600b001bee8664d82sm1285793pjb.35.2022.03.01.09.05.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Mar 2022 09:05:10 -0800 (PST) Date: Tue, 1 Mar 2022 09:05:06 -0800 From: Stephen Hemminger To: David Marchand Cc: "Zhang, Yuying" , dev , Maxime Coquelin , "Xia, Chenbo" , dpdk stable Subject: Re: [PATCH v1] net/vhost: clear data of packet mbuf after sending pkts Message-ID: <20220301090506.6fed12a5@hermes.local> In-Reply-To: References: <20220301072802.1349736-1-yuying.zhang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Tue, 1 Mar 2022 10:47:32 +0100 David Marchand wrote: > On Tue, Mar 1, 2022 at 10:02 AM Zhang, Yuying wrote: > > > -----Original Message----- > > > From: David Marchand > > > Sent: Tuesday, March 1, 2022 4:44 PM > > > To: Zhang, Yuying > > > Cc: dev ; Maxime Coquelin ; > > > Xia, Chenbo ; dpdk stable > > > Subject: Re: [PATCH v1] net/vhost: clear data of packet mbuf after sending pkts > > > > > > On Tue, Mar 1, 2022 at 8:29 AM Yuying Zhang wrote: > > > > > > > > The PMD frees a packet mbuf back into its original mempool after > > > > sending a packet. However, old data is not cleaned up which causes > > > > error in payload of new packets. This patch clear data of packet mbuf > > > > before freeing mbuf. > > > > > > This patch looks wrong to me. > > > What is the actual issue you want to fix? > > > > eth_vhost_tx() frees the packet mbuf back into its original mempool every time after a packet sent without clearing the data field. > > Then packet transmit function will get bulk directly without reset. New generated packet contains old data of previous packet. This is wrong. > > With the proposed patch, if the mbuf refcnt is != 0, you are shooting > the data while some other part of the application might be needing it. > > Plus, there should be no expectation about a mbuf data content when > retrieving one from a mempool. > The only bytes that are guaranteed to be initialised by the mbuf API > are its metadata. > > > If there is an issue somewhere in dpdk where the mbuf data content is > expected to be 0 on allocation, please point at it. > Or share the full test that failed. > > Agree. There is no guarantee that mbuf you get was not just used by some other driver or library. Only the fields in rte_pktmbuf_reset are guaranteed to be set.