Hi Andrew, > -----Original Message----- > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > Sent: Wednesday, July 28, 2021 3:57 PM > To: Xueming(Steven) Li <xuemi...@nvidia.com> > Cc: dev@dpdk.org; Slava Ovsiienko <viachesl...@nvidia.com>; > NBU-Contact-Thomas Monjalon <tho...@monjalon.net>; Ferruh > Yigit <ferruh.yi...@intel.com> > Subject: Re: [RFC] ethdev: introduce shared Rx queue > > On 7/27/21 6:42 AM, Xueming Li wrote: > > In eth PMD driver model, each RX queue was pre-loaded with mbufs for > > saving incoming packets. When number of SF or VF scale out in a switch > > domain, the memory consumption became significant. Most important, > > polling all ports leads to high cache miss, high latency and low > > throughput. > > > > To save memory and speed up, this patch introduces shared RX queue. > > Ports with same configuration in a switch domain could share RX queue > > set by specifying offloading flag RTE_ETH_RX_OFFLOAD_SHARED_RXQ. > > Polling a member port in shared RX queue receives packets for all member > > ports. > > Source port is identified by mbuf->port. > > > > Queue number of ports in shared group should be identical. Queue index > > is 1:1 mapped in shared group. > > > > Shared RX queue is supposed to be polled on same thread. > > > > Multiple groups is supported by group ID. > > > > Signed-off-by: Xueming Li <xuemi...@nvidia.com> > > It looks like it could be useful to artificial benchmarks, but absolutely > useless for real life. SFs and VFs are used by VMs (or containers?) > to have its own part of HW. If so, SF or VF Rx and Tx queues live in a VM and > cannot be shared.
Thanks for looking at this! Agree, SF and VF can't be shared. > > Sharing makes sense for representors, but it is not mentioned in the > description. Yes, the major target is representors, ports in same switch domain, I'll emphasis this in next version.
