From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 75D1758EC for ; Tue, 25 Oct 2016 11:39:22 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id d128so16327725wmf.1 for ; Tue, 25 Oct 2016 02:39:22 -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=f4grTxViVOJK+UHQNuY3wR0FeLH78lWch9KOjpWNHio=; b=Bx8R58sYgzlBvqCViQ/1wVEln9W3oWQnRBV9iUt2gLJnS2hwFG7hxl5BEBLgu7/Okr fvAA2muXf6a6rvIiYDiMjVR1OO0YQXnC+oeqaKr22pY4NMAbJyvp4SDyy8DiJqCJGL7h V6kiSAwVboeOaRhCPlf4Q9ChivoHf2ahpKIwKX0LiUNKEsuBSm5Vw5IGQds4SNdMsgQf A3g4pk5JKVf0XI9hsd1GbS5h/+7HdqQbtT6zZBY0zZmceARBtc7QPGe7R3tKAYxz1I6+ pEjUQ6n1adoiZExJs0fwrlwecgYS4oRXo+hOE9UgIAmyYtrcbyK2PMhWFDr2sK7js0xA dizw== 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=f4grTxViVOJK+UHQNuY3wR0FeLH78lWch9KOjpWNHio=; b=IkHv2uhjPZq+Gw+Gmur586qtcE4ZJRxEpM3B10g1pNo3Ld8fT3Y1QoVGa6vtAKbH4n sKymoJtBEkC33P9s6RbasWRVR7aECf/LFN1fAWwxSmQlsqxNXenvDaeU/fdVWnTEyCmW 2Pk4SiMJ32DmnbCc+WJfg4pGbbqDqtYuc/0/kacWqugYKCgOHbRwssgje53w9YHgryQU p6SfSiyM3n8JxGYPwn7UyhsMH+iMSgG86C4IKcg+JOWSoguESUR+mwF45P0jkqGxzmCh DJx4lJlrI8KpX6tPX/tox7RHlMamxguOXra3AePhsMzFYZxb1zjLkmuE/sdy0Lf8ZB4/ 1g7w== X-Gm-Message-State: ABUngvfEYerNEyj9ktIwHm5hsDBlHNI22QqR4lHUM9GHCxC+7CxPM/zGPlffsstQs3e/AMVN X-Received: by 10.28.227.11 with SMTP id a11mr2099460wmh.88.1477388362219; Tue, 25 Oct 2016 02:39:22 -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 129sm2621915wmq.9.2016.10.25.02.39.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 02:39:21 -0700 (PDT) Date: Tue, 25 Oct 2016 11:39:15 +0200 From: Adrien Mazarguil To: Bruce Richardson Cc: "Wiles, Keith" , Morten =?utf-8?Q?Br=C3=B8rup?= , "dev@dpdk.org" , Olivier Matz , Oleg Kuporosov Message-ID: <20161025093915.GJ5733@6wind.com> References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <7910CF2F-7087-4307-A9AC-DE0287104185@intel.com> <20161024162538.GA34988@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161024162538.GA34988@bricha3-MOBL3.ger.corp.intel.com> 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 09:39:22 -0000 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. > One other point I'll mention is that we need to have a discussion on > how/where to add in a timestamp value into the mbuf. Personally, I think > it can be in a union with the sequence number value, but I also suspect > that 32-bits of a timestamp is not going to be enough for many. > > Thoughts? If we consider that timestamp representation should use nanosecond granularity, a 32-bit value may likely wrap around too quickly to be useful. We can also assume that applications requesting timestamps may care more about latency than throughput, Oleg found that using the second cache line for this purpose had a noticeable impact [1]. [1] http://dpdk.org/ml/archives/dev/2016-October/049237.html -- Adrien Mazarguil 6WIND