From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id B513629CD for ; Tue, 25 Oct 2016 15:20:02 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id b80so163492717wme.1 for ; Tue, 25 Oct 2016 06:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=4iiGtWm0ULvSEf7RETpxy6x6eCN3t/Dhj5vCVpGksMQ=; b=sahHP4RdbXraej4ulaYKxrFaZqhj6v9N0XxYv9sbXr5KsTDZQmw0mGNZ6OE7cpwzVL tL1IjSpq+kJywAkunpdrkIgvvyJ94TvV/u2cgeqw5P2zEVGDF/I1NNKlo12s+aM+iT7Y WGt00maRMtaK24G8vjyeW+Nd3EJ0Ot6QdcBQLkXdoGvagHoezeDRqfhmMGOvuELhg72V 0iLZ0tkaebc3y2MiYUTsUuTcN8yZ/D177FxWvCNHXeBAC+0uZhgqyLyMxoYcGep5d2xq IW5lk5EVy7v7p/cBm/oVeXNGhlarsEhQzADYw/oi+MsiNYv9Jq6cfqonGfpaiFhgqokB NUJA== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=4iiGtWm0ULvSEf7RETpxy6x6eCN3t/Dhj5vCVpGksMQ=; b=iPeYvOyr4PWwh5EINpEnBkQ+yaVi67k2tcPeyOMV7Izofve3CdePf/oxTBLJs0uYsc iVlU9Qft7HHuI3kIgjLtL54uHbTvgOIbaJ4LBScbp2B0Pmp+VXurf3rnNVUmDLWWXCYC dD4P6n+yGb2hJs4IHAN4jdkAbchLYmkcyW9tHqaJV4d6LTFZIIKH6l81AVExpnZZWu56 a1JGISg9wjNJQV3diaK1HsD4pkYYpVUBY23V4C7wQ6LidvlonBRG2XHltNT+a01E1emD +sqEaB20dT0Q2waZi6l2EDD0SvwzA9lLSuuO3wUWpv0f/i/Uw62e2NwEaIVGmJXPW1uf wRVw== X-Gm-Message-State: ABUngvctkwjYx+neF1VDGwPjaXx0WqaL9AnsBdCMNons2cKaeDswy9cb8/UtcasWcqum/A2f X-Received: by 10.28.74.216 with SMTP id n85mr3585167wmi.39.1477401602447; Tue, 25 Oct 2016 06:20:02 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id r62sm3678907wmd.4.2016.10.25.06.20.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 06:20:01 -0700 (PDT) From: Thomas Monjalon To: Olivier Matz Cc: dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= , "Ananyev, Konstantin" , "Richardson, Bruce" , "Wiles, Keith" Date: Tue, 25 Oct 2016 15:20:01 +0200 Message-ID: <3276523.JP7xya6XdT@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <39b70924-0e66-478c-36ea-dd18d27ed8a6@6wind.com> References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC359EA8B8@smartserver.smartshare.dk> <39b70924-0e66-478c-36ea-dd18d27ed8a6@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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:20:02 -0000 2016-10-25 15:00, Olivier Matz: > On 10/25/2016 12:22 PM, Morten Br=F8rup wrote: > > From: Ananyev, Konstantin > >> From: Bruce Richardson > >>> On Mon, Oct 24, 2016 at 11:47:16PM +0200, Morten Br=F8rup wrote: > >>>> From: Bruce Richardson > >>>>> On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote: > >>>>>> 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= > >>>>> value to the second cacheline, but it appears that NXP are usin= g > >>>>> the port value in their NIC drivers for passing in metadata, so= > >>>>> we'd need their agreement on any move (or removal). > >>>>> > >>>> If a single driver instance services multiple ports, so the port= s > >>>> are not polled individually, the m->port member will be required= to > >>>> identify the port. > >>>> In that case, it might also used elsewhere in the ingress path, > >>>> and thus appropriate having in the first cache line. > >> > >> Ok, but these days most of devices have multiple rx queues. > >> So identify the RX source properly you need not only port, but > >> port+queue (at least 3 bytes). > >> But I suppose better to wait for NXP input here. > >> > >>> So yes, this needs further discussion with NXP. > >=20 > > It seems that this concept might be somewhat similar to the > > Flow Director information, which already has plenty of bits > > in the first cache line. You should consider if this can be > > somehow folded into the m->hash union. >=20 > I'll tend to agree with Morten. >=20 > First, I think that having more than 255 virtual links is possible, > so increasing the port size to 16 bits is not a bad idea. >=20 > I think the port information is more useful for a network stack > than the queue_id, but it may not be the case for all applications. > On the other hand, the queue_id (or something else providing the same= > level of information) could led in the flow director structure. >=20 > Now, the question is: do we really need the port to be inside the mbu= f? > Indeed, the application can already associate a bulk of packet with a= > port id. >=20 > The reason why I'll prefer to keep it is because I'm pretty sure that= > some applications use it. At least in the examples/ directory, we can= > find distributor, dpdk_qat, ipv4_multicast, load_balancer, > packet_ordering. I did not check these apps in detail, but it makes m= e > feel that other external applications could make use of the port fiel= d. Having some applications using it does not mean that there is a good justification to keep it. I think the data must be stored inside the mbuf struct only if it increases the performance of known use cases significantly. So the questions should be: - How significant are the use cases? - What is the performance drop when having the data outside of the stru= ct? The mbuf space must be kept jealously like a DPDK treasure :)