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 52E78A034F; Tue, 1 Mar 2022 10:47:50 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 341C841C2E; Tue, 1 Mar 2022 10:47:50 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id D01B641C2E for ; Tue, 1 Mar 2022 10:47:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646128068; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TdoqY1Pp8A7Y3Tj6e4MGo/b34wop+eTmpTgyRBMhIrU=; b=hYxc9R+5NvYhb3IeZ/4l/rL1UQSffxm4J1HmvhHxWROBfppRc7aBcf+G5OhLSxBkcLF4Vo FS1VQGZ1ArP+xUYz2W7nsYh2fx0htSXXFJ0uL5JT4qbDt4mrm7fqQjY6m4Bk1cbnm5Gyw1 wTeZiw6CpZ+gOvbBsNC1zeK6xFnHboA= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-444-7ubl22bIPeK9j9NZCqdRRw-1; Tue, 01 Mar 2022 04:47:45 -0500 X-MC-Unique: 7ubl22bIPeK9j9NZCqdRRw-1 Received: by mail-lf1-f72.google.com with SMTP id f37-20020a0565123b2500b004433d9bb4feso2275072lfv.22 for ; Tue, 01 Mar 2022 01:47:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TdoqY1Pp8A7Y3Tj6e4MGo/b34wop+eTmpTgyRBMhIrU=; b=nOirEDw/T1yuV0xMuhL1F/dbkzAnzKYXrld9fAXPLwhNt8XPc09xdW3nzGJ/RaPuRa P/d/zNIAOVcsOdatSWtxlq3zkAs3k4/e3SzEWej7jTIygZjI10PU1IPhC1UCYdsh8aXO dwoO09o1d65HWsvkSZkVgEqqS3A9P/iMHWxH/09VFqcTpbLq8USfaZIL0ND7nfQS2Mzi P6RAdxZHfEMCiD2yhmArSbEDz0F3MHmKAMPn8VlDjBKqBlUMAFMTe5qYneT8x897ZwAv pzZQ46Ld6vw0RIVwyBtzlzJXbsKGudWuvwF+HTSBuDAVJhg4G9Br39nO1SUBmtZOdlpK saCg== X-Gm-Message-State: AOAM533Ib2FoKQoQ8m6K1GzhJdDqqbKWdxy8+Z1KtMVpO5CHllBjnYmz WzqDGhJZ5c/IQZ8Fwjob3wBlcT0kE+PfbgutQtPDG84HYUkwtFbVvxFiCxDjRrWwvyEAI0pqTez Dr96U0SUA7uZjcRznAdU= X-Received: by 2002:a2e:a4dc:0:b0:246:4205:98e7 with SMTP id p28-20020a2ea4dc000000b00246420598e7mr16320941ljm.55.1646128063734; Tue, 01 Mar 2022 01:47:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJx+lFexQ93wJ4MDTdRayrkhJewCl6TWBl+2+dAlU3QR0ieTg1etHhTRO0aMecJ5pWGqST/lwSnQxmS/dTZlC30= X-Received: by 2002:a2e:a4dc:0:b0:246:4205:98e7 with SMTP id p28-20020a2ea4dc000000b00246420598e7mr16320930ljm.55.1646128063499; Tue, 01 Mar 2022 01:47:43 -0800 (PST) MIME-Version: 1.0 References: <20220301072802.1349736-1-yuying.zhang@intel.com> In-Reply-To: From: David Marchand Date: Tue, 1 Mar 2022 10:47:32 +0100 Message-ID: Subject: Re: [PATCH v1] net/vhost: clear data of packet mbuf after sending pkts To: "Zhang, Yuying" Cc: dev , Maxime Coquelin , "Xia, Chenbo" , dpdk stable Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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. -- David Marchand