From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 6379E11C5 for ; Tue, 25 Oct 2016 15:48:25 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id c78so25574316wme.0 for ; Tue, 25 Oct 2016 06:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=DeUDCPbUF9mYSmz7SWw3lH/lfWcE0PhvmD1zfzN1rSc=; b=shmVZsqw9elPvBKcCw0LyCTZiMMHi9whjooMHg6aFjq5OyqRuQ99L9yC0S95sxRHJZ ySBG2SCAzTWLuaMeNxjxiWf7N0dXxSNk4nY+XSje8moMLhubMOXffkWJAa9jaE1HnE8A eN3ONK2gId6VG8filLIKiKrGZm1HTZJY4C9E1fzkEofGK+BETUXnptnOL55k0/t0iuRt gZMLogrenc9V4sDZK2Y9wo5E0tfh3WTkirIaMOqtFU0axA/MdjCj/+UzDP6VQwVGaAU3 iKVcqWZZFAL6twG6KRiM3DVS9kxuTprVANbPjM0AdQ60J788ZN6FPfjs3yULORxKKs/6 yQ+A== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=DeUDCPbUF9mYSmz7SWw3lH/lfWcE0PhvmD1zfzN1rSc=; b=Qz+lfysAAg3nFsMOHiYRDWLK2Swsc+Tn4JxgnGYIiOwo69RbPqSWYQWaWL9DmGFvFD MzQIzozdw53V7T4KwaExaTTApHtBajMo7Pq5/f5LEXUo6KqX7K2gjU3+UW8SCJTmDvK8 rX/jTEvuO4Le9DWDGcBxJcDD5ek3KfreeuQL7NyBew6g8N0EjI9EKJjCW9Am/PBrAcBm Lk/7yj3XUP699BabHSZpna5fWD/OkAzqJrxJpY6NyiA51EabeIiMaJxpi2g0czJIJ9LG udfrAEE2ak12jOswiRyIsfCBOIq+Ih2mqAZ6EdAin1qLugZhFN+U9C2eH/zzepPVu1Wu ztnQ== X-Gm-Message-State: ABUngveBb9dzj9297Qi7e9m6RT4uzh5knF3uxjaFHelPBQ7ShR6obXu1r2tg5OIMalAfHJxD X-Received: by 10.28.226.136 with SMTP id z130mr3739871wmg.0.1477403305103; Tue, 25 Oct 2016 06:48:25 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id r1sm25189065wjc.43.2016.10.25.06.48.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 06:48:24 -0700 (PDT) Date: Tue, 25 Oct 2016 15:48:17 +0200 From: Adrien Mazarguil To: Morten =?utf-8?Q?Br=C3=B8rup?= Cc: Bruce Richardson , "Wiles, Keith" , dev@dpdk.org, Olivier Matz , Oleg Kuporosov Message-ID: <20161025134817.GL5733@6wind.com> References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <7910CF2F-7087-4307-A9AC-DE0287104185@intel.com> <20161024162538.GA34988@bricha3-MOBL3.ger.corp.intel.com> <20161025093915.GJ5733@6wind.com> <98CBD80474FA8B44BF855DF32C47DC359EA8B7@smartserver.smartshare.dk> <20161025110444.GK5733@6wind.com> <20161025111357.GA43504@bricha3-MOBL3.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC359EA8BA@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EA8BA@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] mbuf changes 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: Tue, 25 Oct 2016 13:48:25 -0000 On Tue, Oct 25, 2016 at 02:16:29PM +0200, Morten Brørup wrote: > Comments inline. I'm only replying to the nb_segs bits here. > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Tuesday, October 25, 2016 1:14 PM > > To: Adrien Mazarguil > > Cc: Morten Brørup; Wiles, Keith; dev@dpdk.org; Olivier Matz; Oleg > > Kuporosov > > Subject: Re: [dpdk-dev] mbuf changes > > > > On Tue, Oct 25, 2016 at 01:04:44PM +0200, Adrien Mazarguil wrote: > > > On Tue, Oct 25, 2016 at 12:11:04PM +0200, Morten Brørup wrote: > > > > Comments inline. > > > > > > > > Med venlig hilsen / kind regards > > > > - Morten Brørup > > > > > > > > > > > > > -----Original Message----- > > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > > > > Sent: Tuesday, October 25, 2016 11:39 AM > > > > > To: Bruce Richardson > > > > > Cc: Wiles, Keith; Morten Brørup; dev@dpdk.org; Olivier Matz; Oleg > > > > > Kuporosov > > > > > Subject: Re: [dpdk-dev] mbuf changes > > > > > > > > > > On Mon, Oct 24, 2016 at 05:25:38PM +0100, Bruce Richardson wrote: > > > > > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote: > > > > > [...] > > > > > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup > > > > > wrote: > > > > > [...] > > > > > > > > 5. > > > > > > > > > > > > > > > > And here’s something new to think about: > > > > > > > > > > > > > > > > m->next already reveals if there are more segments to a > > packet. > > > > > Which purpose does m->nb_segs serve that is not already covered > > by > > > > > m- > > > > > >next? > > > > > > > > > > > > It is duplicate info, but nb_segs can be used to check the > > > > > > validity > > > > > of > > > > > > the next pointer without having to read the second mbuf > > cacheline. > > > > > > > > > > > > Whether it's worth having is something I'm happy enough to > > > > > > discuss, though. > > > > > > > > > > Although slower in some cases than a full blown "next packet" > > > > > pointer, nb_segs can also be conveniently abused to link several > > > > > packets and their segments in the same list without wasting > > space. > > > > > > > > I don’t understand that; can you please elaborate? Are you abusing > > m->nb_segs as an index into an array in your application? If that is > > the case, and it is endorsed by the community, we should get rid of m- > > >nb_segs and add a member for application specific use instead. > > > > > > Well, that's just an idea, I'm not aware of any application using > > > this, however the ability to link several packets with segments seems > > > useful to me (e.g. buffering packets). Here's a diagram: > > > > > > .-----------. .-----------. .-----------. .-----------. .--- > > --- > > > | pkt 0 | | seg 1 | | seg 2 | | pkt 1 | | > > pkt 2 > > > | next --->| next --->| next --->| next --->| > > ... > > > | nb_segs 3 | | nb_segs 1 | | nb_segs 1 | | nb_segs 1 | | > > > `-----------' `-----------' `-----------' `-----------' `--- > > --- > > I see. It makes it possible to refer to a burst of packets (with segments or not) by a single mbuf reference, as an alternative to the current design pattern of using an array and length (struct rte_mbuf **mbufs, unsigned count). > > This would require implementation in the PMDs etc. > > And even in this case, m->nb_segs does not need to be an integer, but could be replaced by a single bit indicating if the segment is a continuation of a packet or the beginning (alternatively the end) of a packet, i.e. the bit can be set for either the first or the last segment in the packet. Sure however if we keep the current definition, a single bit would not be enough as it must be nonzero for the buffer to be valid. I think a 8 bit field is not that expensive for a counter. > It is an almost equivalent alternative to the fundamental design pattern of using an array of mbuf with count, which is widely implemented in DPDK. And m->next still lives in the second cache line, so I don't see any gain by this. That's right, it does not have to live in the first cache line, my only concern was its entire removal. > I still don't get how m->nb_segs can be abused without m->next. By "abused" I mean that applications are not supposed to pass this kind of mbuf lists directly to existing mbuf-handling functions (TX burst, rte_pktmbuf_free() and so on), however these same applications (even PMDs) can do so internally temporarily because it's so simple. The next pointer of the last segment of a packet must still be set to NULL every time a packet is retrieved from such a list to be processed. > > However, nb_segs may be a good candidate for demotion, along with > > possibly the port value, or the reference count. Yes, I think that's fine as long as it's kept somewhere. -- Adrien Mazarguil 6WIND