From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: mbuf changes Date: Tue, 25 Oct 2016 15:20:01 +0200 Message-ID: <3276523.JP7xya6XdT@xps13> References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC359EA8B8@smartserver.smartshare.dk> <39b70924-0e66-478c-36ea-dd18d27ed8a6@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= , "Ananyev, Konstantin" , "Richardson, Bruce" , "Wiles, Keith" To: Olivier Matz 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) In-Reply-To: <39b70924-0e66-478c-36ea-dd18d27ed8a6@6wind.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 :)