From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) by dpdk.org (Postfix) with ESMTP id 26A42133F for ; Wed, 9 Nov 2016 12:42:32 +0100 (CET) Received: by mail-vk0-f51.google.com with SMTP id p9so173387728vkd.3 for ; Wed, 09 Nov 2016 03:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dx/KIZi1O4Mqfp/G6M+gQUMYd1MlItyZZHevkAacCAQ=; b=ti3bwAecA5EzDM91G7zdyMC/rLG/I/XyJ38K88suQbO+CkaiVhzeqJr1V9RpuVs+gU wRr1dWKzDiKtor2ULsyvYP66D5W0Ud985d3N4tsoTolC9FH2MsLgylRmba8tSmVWVc+5 9NoH0X/xUD3iyx0s3BjC8JuxHOr+LyI1NG1FZ+ghvPZwgycr6D0oznKZ54cU7Ozpl7qm a9Bto+kTIkthVZMrdZummhVfCFqkRXdymRDDd2bfzbLIG4GLFQiiXzvl3d+vJxsg3YjF nktFSMC6VtPjCS2/7jPuipaP4l1nV1XqlJcXG+zGHSeU2OQB1h7fLTOrmnenAZ7/Voum HCyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dx/KIZi1O4Mqfp/G6M+gQUMYd1MlItyZZHevkAacCAQ=; b=HSV36Xk0SkF6/gydoUS6BnKbE3NPaRBDeZfWXtvgoYr6lSLJRDz6GzpqDPE5GB+qyh GxtQ1qgtOB9dSMiQ12Bc2iidmoE8963kECbjJh95diqp+P0F91ERwgogU3eYNaGaRwc9 jSkup2Sj8LFyi0N2k2rdKTlXKUFikpYtdSTxiso8xcDjP+rypU/QI9A00DEnvLBLJL7V jGo9W8lnSaFW9aMCxIA4v9y0XiifnnDuq6NLlhqnwvEIGdhgfsTwnqzeZwg5Vm+5c57s LSdGL4EVdvgri3Kd1RfiFViTMED79Or9sK8pb/QhM2WENikAWOk2y7iLow967PSjDBws hOOw== X-Gm-Message-State: ABUngvfXm3kMDP3kl3lHd55QUPQHKoGH69i6wWgu2qt/8ZS4jOD/ipwMWNf+d9FXH0rp+iWxCFJxUTvab7STJ5Uv X-Received: by 10.31.198.198 with SMTP id w189mr11370361vkf.26.1478691751549; Wed, 09 Nov 2016 03:42:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.79.145 with HTTP; Wed, 9 Nov 2016 03:42:30 -0800 (PST) In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <7910CF2F-7087-4307-A9AC-DE0287104185@intel.com> <20161024162538.GA34988@bricha3-MOBL3.ger.corp.intel.com> <20161025120537.GA56680@bricha3-MOBL3.ger.corp.intel.com> From: Alejandro Lucero Date: Wed, 9 Nov 2016 12:42:30 +0100 Message-ID: To: Bruce Richardson Cc: Shreyansh Jain , "Wiles, Keith" , =?UTF-8?Q?Morten_Br=C3=B8rup?= , "dev@dpdk.org" , Olivier Matz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Wed, 09 Nov 2016 11:42:32 -0000 On Wed, Oct 26, 2016 at 10:28 AM, Alejandro Lucero < alejandro.lucero@netronome.com> wrote: > > > On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson < > bruce.richardson@intel.com> wrote: > >> On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote: >> > On Monday 24 October 2016 09:55 PM, 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=C3=B8rup < >> mb@smartsharesystems.com> wrote: >> > > > > >> > > > > First of all: Thanks for a great DPDK Userspace 2016! >> > > > > >> > > > > >> > > > > >> > > > > Continuing the Userspace discussion about Olivier Matz=E2=80=99s= proposed >> mbuf changes... >> > > >> > > Thanks for keeping the discussion going! >> > > > > >> > > > > >> > > > > >> > > > > 1. >> > > > > >> > > > > Stephen Hemminger had a noteworthy general comment about keeping >> metadata for the NIC in the appropriate section of the mbuf: Metadata >> generated by the NIC=E2=80=99s RX handler belongs in the first cache lin= e, and >> metadata required by the NIC=E2=80=99s TX handler belongs in the second = cache line. >> This also means that touching the second cache line on ingress should be >> avoided if possible; and Bruce Richardson mentioned that for this reason >> m->next was zeroed on free(). >> > > > > >> > > Thinking about it, I suspect there are more fields we can reset on >> free >> > > to save time on alloc. Refcnt, as discussed below is one of them, bu= t >> so >> > > too could be the nb_segs field and possibly others. >> > > >> > > > > >> > > > > >> > > > > 2. >> > > > > >> > > > > There seemed to be consensus that the size of m->refcnt should >> match the size of m->port because a packet could be duplicated on all >> physical ports for L3 multicast and L2 flooding. >> > > > > >> > > > > Furthermore, although a single physical machine (i.e. a single >> server) with 255 physical ports probably doesn=E2=80=99t exist, it might= contain >> more than 255 virtual machines with a virtual port each, so it makes sen= se >> extending these mbuf fields from 8 to 16 bits. >> > > > >> > > > I thought we also talked about removing the m->port from the mbuf >> as it is not really needed. >> > > > >> > > Yes, this was mentioned, and also the option of moving the port valu= e >> to >> > > the second cacheline, but it appears that NXP are using the port val= ue >> > > in their NIC drivers for passing in metadata, so we'd need their >> > > agreement on any move (or removal). >> > >> > I am not sure where NXP's NIC came into picture on this, but now that >> it is >> > highlighted, this field is required for libevent implementation [1]. >> > >> > A scheduler sending an event, which can be a packet, would only have >> > information of a flow_id. From this matching it back to a port, withou= t >> > mbuf->port, would be very difficult (costly). There may be way around >> this >> > but at least in current proposal I think port would be important to >> have - >> > even if in second cache line. >> > >> > But, off the top of my head, as of now it is not being used for any >> specific >> > purpose in NXP's PMD implementation. >> > >> > Even the SoC patches don't necessarily rely on it except using it >> because it >> > is available. >> > >> > @Bruce: where did you get the NXP context here from? >> > >> Oh, I'm just mis-remembering. :-( It was someone else who was looking fo= r >> this - Netronome, perhaps? >> >> CC'ing Alejandro in the hope I'm remembering correctly second time >> round! >> >> > Yes. Thanks Bruce! > > So Netronome uses the port field and, as I commented on the user meeting, > we are happy with the field going from 8 to 16 bits. > > In our case, this is something some clients have demanded, and if I'm not > wrong (I'll double check this asap), the port value is for knowing where > the packet is coming from. Think about a switch in the NIC, with ports > linked to VFs/VMs, and one or more physical ports. That port value is not > related to DPDK ports but to the switch ports. Code in the host (DPDK or > not) can receive packets from the wire or from VFs through the NIC. This = is > also true for packets received by VMs, but I guess the port value is just > interested for host code. > > > I consulted this functionality internally and it seems we do not need this anymore. In fact, I will remove the metadata port handling soon from our PMD. > /Bruce >> > >