From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by dpdk.org (Postfix) with ESMTP id 89CA5DE4 for ; Mon, 15 Jun 2015 22:47:30 +0200 (CEST) Received: by pdjn11 with SMTP id n11so80713167pdj.0 for ; Mon, 15 Jun 2015 13:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=IwoTRIRMl9WWfn5a3UXA5XHeJBLcpEMk8ZTAcPGm5vE=; b=Uoy1DpSPM5wFurVL5h/XxdUMbm+YzbYMTdlCQTSEg39M9KVeYypyZ4NP84kD7Hh/ej 7CdTn1cXIUasbnbRNwQOP/Ti8KjildQ93tvXntgRhd+nATWqYHPzvDST1IRXFMeF0ODc au9HQlSOkSLcbAb9hbFtPjIrMloNSvkb0oJPHPqMqJCHA0wXMugGjMVucrdyti4lw/qi /NEEZMMWbQhoxgiH2vMLyE6lEhUmtR+5PtbaIUTQNDJ5djVQPaO55Y+7Pa7sLrNaH+HL ndoQq9sDnbr42Fwoyj0pumfw/O8RKtoR9REXyzIeSj82/J7b7joT+6qN2GzWJnLu+rEA lBJA== X-Gm-Message-State: ALoCoQmkftOMjCkqALHcALSXfdTKd8mz4kdGwjp20fDDfNWqPaFBfGDsBg8zdh7S6+kKHrubELVI X-Received: by 10.68.215.66 with SMTP id og2mr51132040pbc.20.1434401249724; Mon, 15 Jun 2015 13:47:29 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id v8sm13130322pdm.89.2015.06.15.13.47.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 13:47:29 -0700 (PDT) Date: Mon, 15 Jun 2015 13:47:26 -0700 From: Stephen Hemminger To: "Ananyev, Konstantin" Message-ID: <20150615134726.65feca71@urahara> In-Reply-To: <2601191342CEEE43887BDE71AB97725836A0AA03@irsmsx105.ger.corp.intel.com> References: <20150615141258.GA580@bricha3-MOBL3> <557EE1A0.609@6wind.com> <2601191342CEEE43887BDE71AB97725836A0A8A8@irsmsx105.ger.corp.intel.com> <557EECFF.3090402@6wind.com> <20150615152346.GC580@bricha3-MOBL3> <2601191342CEEE43887BDE71AB97725836A0A8FB@irsmsx105.ger.corp.intel.com> <20150615153943.GD580@bricha3-MOBL3> <2601191342CEEE43887BDE71AB97725836A0A91C@irsmsx105.ger.corp.intel.com> <20150615160208.GE580@bricha3-MOBL3> <2601191342CEEE43887BDE71AB97725836A0A952@irsmsx105.ger.corp.intel.com> <20150615162259.GA384@bricha3-MOBL3> <2601191342CEEE43887BDE71AB97725836A0AA03@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "Damjan Marion \(damarion\)" Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline 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, 15 Jun 2015 20:47:31 -0000 On Mon, 15 Jun 2015 18:34:13 +0000 "Ananyev, Konstantin" wrote: > > > > -----Original Message----- > > From: Richardson, Bruce > > Sent: Monday, June 15, 2015 5:23 PM > > To: Ananyev, Konstantin > > Cc: Olivier MATZ; dev@dpdk.org; Damjan Marion (damarion) > > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline > > > > On Mon, Jun 15, 2015 at 05:10:44PM +0100, Ananyev, Konstantin wrote: > > > > > > > > > > -----Original Message----- > > > > From: Richardson, Bruce > > > > Sent: Monday, June 15, 2015 5:02 PM > > > > To: Ananyev, Konstantin > > > > Cc: Olivier MATZ; dev@dpdk.org; Damjan Marion (damarion) > > > > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline > > > > > > > > On Mon, Jun 15, 2015 at 04:59:55PM +0100, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > > > > > As I can see, vector TX is the only one that calls __rte_pktmbuf_prefree_seg() directly. > > > > > All others use rte_pktmbuf_free_seg(), that does ' m->next = NULL' anyway. > > > > > For vector TX - yes, need to verify that it would not introduce a slowdown. > > > > > Konstantin > > > > > > > > > > > > > But if the function is only directly called from one place, and that doesn't > > > > have a problem, why would we bother making any change at all? > > > > > > > > > For future usages? > > > But sure, if you believe that we can safely remove 'm->next = NULL' at RX path, > > > without any changes in the __rte_pktmbuf_prefree_seg() - > > > that seems fine to me. > > > Konstantin > > > > > > > If we find it's not safe, we can add in the change to __rte_pktmbuf_prefree_seg > > as you suggest. > > > > One other question: based on this, do you think it's safe to also remove the > > assignment to NULL from the pktmbuf_alloc function? I suspect it should be safe, and > > that should help any traffic-generator type applications that use that function > > extensively. > > So it will be setup to NULL, either by: > - mbuf constructor. > - TX full-path free descriptors code. > - upper layer code that uses 'next' pointer explicitly. > ? > > I can't come-up with some breakage scenario off-hand. > But that means that we have to should avoid resetting tx_offload in pktmbuf_alloc() too, right? > Otherwise there probably wouldn't be any real gain. > Konstantin > > > > > /Bruce > > The issue is when mbuf is used once by something and it sets it to non-NULL packet is sent then freed. then the free packet is picked up by one of the drivers using "fast path" Rx code. IMHO the "fast path" Rx code has to go away. All the special allocation code should call rte_pktmuf_reset and then only set the fields that are special for the received packet. The compiler should be able to remove the redundant stores, and it would prevent bugs I am seeing where some fields are not set in some drivers.