From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by dpdk.org (Postfix) with ESMTP id BE032B39C for <dev@dpdk.org>; Wed, 17 Sep 2014 15:56:06 +0200 (CEST) Received: by mail-we0-f169.google.com with SMTP id w61so1506527wes.0 for <dev@dpdk.org>; Wed, 17 Sep 2014 07:01:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=wb4Kq28WWsIZlZiv98yDujy8grvcnjpP8Ff1fy5Sxmc=; b=EiVKnnPhPXFH9oev4CoVxqWzcAq3jm++viqTW2YjfcVtWFREhVy5tDVro/LdDn/n9v XaYTe75c1ZLGEQDXz5sV2EVbKw/m1eA9mOzljqYLUP3AMA6LjCTgn1AKBUHg/lS2VJJv 2h8P4hVzB7hioOKFCm0bYIOmY2VUF0o4iYlOGDyfD3INTnjxX+yw+Txq+/wYeXPPCgIP aVAzdNXv4iFQIbdW5YPGSCbaTPDJTL1zqphjj9fMWffHTvqpHs0iDK9qWtRxvAWLalLh vt6ZwWaAGjbdmPNneh8aushXGJS5duqK/9rNv4upVX7AXemIbOrUa6OPWAKuGUzAMnNx ukMQ== X-Gm-Message-State: ALoCoQlCsS8+FZA4/YhL+FkUiaYGvqMh9upYbzwGlPnIFXIZmOn9ydLzOS3WSn28oNKIggE2CsZl X-Received: by 10.180.96.161 with SMTP id dt1mr40773707wib.1.1410962507930; Wed, 17 Sep 2014 07:01:47 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id pc6sm22264849wjb.43.2014.09.17.07.01.46 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Sep 2014 07:01:47 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: "Richardson, Bruce" <bruce.richardson@intel.com> Date: Wed, 17 Sep 2014 16:01:37 +0200 Message-ID: <3536812.LpadffOgB2@xps13> Organization: 6WIND User-Agent: KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; ) In-Reply-To: <59AF69C657FD0841A61C55336867B5B0343F2BD2@IRSMSX103.ger.corp.intel.com> References: <1409759378-10113-1-git-send-email-bruce.richardson@intel.com> <682698A055A0F44AA47192B20141149711B1FFE6@BGSMSX102.gar.corp.intel.com> <59AF69C657FD0841A61C55336867B5B0343F2BD2@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf metadata X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 17 Sep 2014 13:56:06 -0000 2014-09-17 10:31, Richardson, Bruce: > > From: Ramia, Kannan Babu > > > > I completely agree with Cristian here, instead of leaving to applications > > where to place their meta data, we can provide a guidance by having this > > field about placement of application meta while maintaining transparency > > on the contents of application meta information. > > My opinion on this is that this is better served via documentation or a > comment in the code. The reason is that this approach is not going to be > suitable for all applications. The mbuf headroom being used by the metadata > is actually designed to be used for any additional headers to be added to > the packet - though other things can obviously be stored in it too. > Therefore the amount of metadata that can be stored in it will depend from > application to application, as any apps doing e.g. tunnelling will need the > headroom for tunnelling headers and may only be able to store a small > amount of metadata - potentially none. For larger amounts of metadata - I > would feel that anything over 64-bytes or so - I have proposed adding in a > separate userdata pointer in the mbuf structure so that apps have the > option of storing the metadata externally e.g. pointing to a flow table > entry or similar. [Please see mbuf rework patch set 3 proposal]. Because of > this, I think it's better to put in a comment in the code indicating that > metadata can go in the headroom, document this properly - including caveats > and limitations - in the documentation, and provide an example of doing > such - something we already have in the packet framework. I agree that replacing these markers by documentation give more accurate informations and (bonus) is simpler. When documentation will be embedded in the git repository, I'd like to see a patch to document these mbuf usages. > All that being said, and while I think this is a good patch, I don't feel > too strongly about it. I'm happy enough if this particular patch does not > get merged in for 1.8, as it's incidental to the overall mbuf changes. I think also it's a good patch so I keep it. -- Thomas