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 1DA21A034F for ; Tue, 1 Mar 2022 10:47:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0EF85407FF; Tue, 1 Mar 2022 10:47:48 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id D8E98407FF for ; Tue, 1 Mar 2022 10:47:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646128066; 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=beyIr1A3e8s8P+E8w81WOY1hmP35LgYccHUxfNo6ob9b7AW2MKU0mxXOEJgL+FEplS+WxL 9v/dCb22u+Ug0QVJ2w0I38c+GtZ06gqiRo+3ZYSH7QEn/VeO+UDtgg9iWW4OU/N6DEMQyu K3cA1kiJhr1/s4RKqk/FwLuTgBYPICs= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-155-aQQjTu2ENTm8oHIGmSJjGg-1; Tue, 01 Mar 2022 04:47:45 -0500 X-MC-Unique: aQQjTu2ENTm8oHIGmSJjGg-1 Received: by mail-lf1-f69.google.com with SMTP id v13-20020ac2592d000000b004435f5315dbso2274393lfi.21 for ; Tue, 01 Mar 2022 01:47:45 -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=DW7j9YCj6YOxiBbr1dRTxs2ONPbGIJvCcYcVhibGg5A89TnHsiWp/WU+FCr2kFWxG1 l4cyNf3XdOso1WaUnvPqYcEKiRJBsAy4vIYpECVVpVQTiDdOqQPH0LPCAsUVVUfyF8NH hWCgxnlPVFfGdIeu1YF1ztu1cx+n/lhvFH8hdt5NQpBNlfWkJi1e5/E+R4Ef20JzQpAP fuKjrj/UDhhFk97hzZSw1ZYgElg61Nn9QanrwUfVMfMWD2hXiINj3B4x2sDKUEEetRut 82j19xvCceyg9NfGUfMjOJ9LGfLmOrL9EMQGkUlZ0pp+pEreAse9QnTc7PJ5C4jZpjhE Y54Q== X-Gm-Message-State: AOAM533CxdBxgpDevtHFF1zDq3lIQZ89lQOHgv5gQHjikqrtWOSNCcld vbEhOIwxSWlP2e9y7hnqWH2v4Tmeqr7FXJEw2E942WNDpYPNhkwXK6xAJBuR5Y/6M2KadlcRMs0 OouxpI/m50z5yY5PePOik2qM= X-Received: by 2002:a2e:a4dc:0:b0:246:4205:98e7 with SMTP id p28-20020a2ea4dc000000b00246420598e7mr16320946ljm.55.1646128063842; 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: 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, 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