On Sun, Oct 10, 2021 at 7:10 PM Xueming(Steven) Li <xuemi...@nvidia.com> wrote: > > On Sun, 2021-10-10 at 15:16 +0530, Jerin Jacob wrote: > > On Fri, Oct 8, 2021 at 1:56 PM Xueming(Steven) Li <xuemi...@nvidia.com> > > wrote: > > > > > > On Wed, 2021-09-29 at 13:35 +0530, Jerin Jacob wrote: > > > > On Wed, Sep 29, 2021 at 1:11 PM Xueming(Steven) Li > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > On Tue, 2021-09-28 at 20:29 +0530, Jerin Jacob wrote: > > > > > > On Tue, Sep 28, 2021 at 8:10 PM Xueming(Steven) Li > > > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > > > > > On Tue, 2021-09-28 at 13:59 +0000, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > > > On Tue, Sep 28, 2021 at 6:55 PM Xueming(Steven) Li > > > > > > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > > > > > > > > > > > On Tue, 2021-09-28 at 18:28 +0530, Jerin Jacob wrote: > > > > > > > > > > > On Tue, Sep 28, 2021 at 5:07 PM Xueming(Steven) Li > > > > > > > > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2021-09-28 at 15:05 +0530, Jerin Jacob wrote: > > > > > > > > > > > > > On Sun, Sep 26, 2021 at 11:06 AM Xueming(Steven) Li > > > > > > > > > > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: Jerin Jacob <jerinjac...@gmail.com> > > > > > > > > > > > > > > > > > Sent: Wednesday, August 11, 2021 4:03 PM > > > > > > > > > > > > > > > > > To: Xueming(Steven) Li <xuemi...@nvidia.com> > > > > > > > > > > > > > > > > > Cc: dpdk-dev <dev@dpdk.org>; Ferruh Yigit > > > > > > > > > > > > > > > > > <ferruh.yi...@intel.com>; NBU-Contact-Thomas > > > > > > > > > > > > > > > > > Monjalon > > > > > > > > > <tho...@monjalon.net>; > > > > > > > > > > > > > > > > > Andrew Rybchenko > > > > > > > > > > > > > > > > > <andrew.rybche...@oktetlabs.ru> > > > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev: > > > > > > > > > > > > > > > > > introduce shared Rx queue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 7:46 PM > > > > > > > > > > > > > > > > > Xueming(Steven) Li > > > > > > > > > > > > > > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > > From: Jerin Jacob <jerinjac...@gmail.com> > > > > > > > > > > > > > > > > > > > Sent: Monday, August 9, 2021 9:51 PM > > > > > > > > > > > > > > > > > > > To: Xueming(Steven) Li > > > > > > > > > > > > > > > > > > > <xuemi...@nvidia.com> > > > > > > > > > > > > > > > > > > > Cc: dpdk-dev <dev@dpdk.org>; Ferruh Yigit > > > > > > > > > > > > > > > > > > > <ferruh.yi...@intel.com>; > > > > > > > > > > > > > > > > > > > NBU-Contact-Thomas Monjalon > > > > > > > > > > > > > > > > > > > <tho...@monjalon.net>; Andrew Rybchenko > > > > > > > > > > > > > > > > > > > <andrew.rybche...@oktetlabs.ru> > > > > > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev: > > > > > > > > > > > > > > > > > > > introduce shared Rx queue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 5:18 PM Xueming Li > > > > > > > > > > > > > > > > > > > <xuemi...@nvidia.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In current DPDK framework, each RX > > > > > > > > > > > > > > > > > > > > queue is > > > > > > > > > > > > > > > > > > > > pre-loaded with mbufs > > > > > > > > > > > > > > > > > > > > for incoming packets. When number of > > > > > > > > > > > > > > > > > > > > representors 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This patch introduces shared RX queue. > > > > > > > > > > > > > > > > > > > > Ports > > > > > > > > > > > > > > > > > > > > with same > > > > > > > > > > > > > > > > > > > > configuration in a switch domain could > > > > > > > > > > > > > > > > > > > > share > > > > > > > > > > > > > > > > > > > > RX queue set by specifying sharing > > > > > > > > > > > > > > > > > > > > group. > > > > > > > > > > > > > > > > > > > > Polling any queue using same shared RX > > > > > > > > > > > > > > > > > > > > queue > > > > > > > > > > > > > > > > > > > > receives packets from > > > > > > > > > > > > > > > > > > > > all member ports. Source port is > > > > > > > > > > > > > > > > > > > > identified > > > > > > > > > > > > > > > > > > > > by mbuf->port. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Port queue number in a shared group > > > > > > > > > > > > > > > > > > > > should be > > > > > > > > > > > > > > > > > > > > identical. Queue > > > > > > > > > > > > > > > > > > > > index is > > > > > > > > > > > > > > > > > > > > 1:1 mapped in shared group. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Share RX queue is supposed to be polled > > > > > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > > > > same thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Multiple groups is supported by group > > > > > > > > > > > > > > > > > > > > ID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is this offload specific to the > > > > > > > > > > > > > > > > > > > representor? If > > > > > > > > > > > > > > > > > > > so can this name be changed specifically > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > representor? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, PF and representor in switch domain > > > > > > > > > > > > > > > > > > could > > > > > > > > > > > > > > > > > > take advantage. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If it is for a generic case, how the flow > > > > > > > > > > > > > > > > > > > ordering will be maintained? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Not quite sure that I understood your > > > > > > > > > > > > > > > > > > question. > > > > > > > > > > > > > > > > > > The control path of is > > > > > > > > > > > > > > > > > > almost same as before, PF and representor > > > > > > > > > > > > > > > > > > port > > > > > > > > > > > > > > > > > > still needed, rte flows not impacted. > > > > > > > > > > > > > > > > > > Queues still needed for each member port, > > > > > > > > > > > > > > > > > > descriptors(mbuf) will be > > > > > > > > > > > > > > > > > > supplied from shared Rx queue in my PMD > > > > > > > > > > > > > > > > > > implementation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My question was if create a generic > > > > > > > > > > > > > > > > > RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, > > > > > > > > > > > > > > > > > multiple > > > > > > > > > > > > > > > > > ethdev receive queues land into > > > > > > > > > the same > > > > > > > > > > > > > > > > > receive queue, In that case, how the flow > > > > > > > > > > > > > > > > > order is > > > > > > > > > > > > > > > > > maintained for respective receive queues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I guess the question is testpmd forward stream? > > > > > > > > > > > > > > > > The > > > > > > > > > > > > > > > > forwarding logic has to be changed slightly in > > > > > > > > > > > > > > > > case > > > > > > > > > > > > > > > > of shared rxq. > > > > > > > > > > > > > > > > basically for each packet in rx_burst result, > > > > > > > > > > > > > > > > lookup > > > > > > > > > > > > > > > > source stream according to mbuf->port, > > > > > > > > > > > > > > > > forwarding to > > > > > > > > > > > > > > > > target fs. > > > > > > > > > > > > > > > > Packets from same source port could be grouped > > > > > > > > > > > > > > > > as a > > > > > > > > > > > > > > > > small burst to process, this will accelerates > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > performance if traffic > > > > > > > > > come from > > > > > > > > > > > > > > > > limited ports. I'll introduce some common api > > > > > > > > > > > > > > > > to do > > > > > > > > > > > > > > > > shard rxq forwarding, call it with packets > > > > > > > > > > > > > > > > handling > > > > > > > > > > > > > > > > callback, so it suites for > > > > > > > > > > > > > > > > all forwarding engine. Will sent patches soon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All ports will put the packets in to the same > > > > > > > > > > > > > > > queue > > > > > > > > > > > > > > > (share queue), right? Does > > > > > > > > > > > > > > > this means only single core will poll only, what > > > > > > > > > > > > > > > will > > > > > > > > > > > > > > > happen if there are > > > > > > > > > > > > > > > multiple cores polling, won't it cause problem? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if this requires specific changes in the > > > > > > > > > > > > > > > application, I am not sure about > > > > > > > > > > > > > > > the solution, can't this work in a transparent > > > > > > > > > > > > > > > way to > > > > > > > > > > > > > > > the application? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Discussed with Jerin, new API introduced in v3 2/8 > > > > > > > > > > > > > > that > > > > > > > > > > > > > > aggregate ports > > > > > > > > > > > > > > in same group into one new port. Users could > > > > > > > > > > > > > > schedule > > > > > > > > > > > > > > polling on the > > > > > > > > > > > > > > aggregated port instead of all member ports. > > > > > > > > > > > > > > > > > > > > > > > > > > The v3 still has testpmd changes in fastpath. Right? > > > > > > > > > > > > > IMO, > > > > > > > > > > > > > For this > > > > > > > > > > > > > feature, we should not change fastpath of testpmd > > > > > > > > > > > > > application. Instead, testpmd can use aggregated ports > > > > > > > > > > > > > probably as > > > > > > > > > > > > > separate fwd_engine to show how to use this feature. > > > > > > > > > > > > > > > > > > > > > > > > Good point to discuss :) There are two strategies to > > > > > > > > > > > > polling > > > > > > > > > > > > a shared > > > > > > > > > > > > Rxq: > > > > > > > > > > > > 1. polling each member port > > > > > > > > > > > > All forwarding engines can be reused to work as > > > > > > > > > > > > before. > > > > > > > > > > > > My testpmd patches are efforts towards this > > > > > > > > > > > > direction. > > > > > > > > > > > > Does your PMD support this? > > > > > > > > > > > > > > > > > > > > > > Not unfortunately. More than that, every application > > > > > > > > > > > needs to > > > > > > > > > > > change > > > > > > > > > > > to support this model. > > > > > > > > > > > > > > > > > > > > Both strategies need user application to resolve port ID > > > > > > > > > > from > > > > > > > > > > mbuf and > > > > > > > > > > process accordingly. > > > > > > > > > > This one doesn't demand aggregated port, no polling schedule > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I was thinking, mbuf will be updated from driver/aggregator > > > > > > > > > port as > > > > > > > > > when it > > > > > > > > > comes to application. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. polling aggregated port > > > > > > > > > > > > Besides forwarding engine, need more work to to demo > > > > > > > > > > > > it. > > > > > > > > > > > > This is an optional API, not supported by my PMD yet. > > > > > > > > > > > > > > > > > > > > > > We are thinking of implementing this PMD when it comes to > > > > > > > > > > > it, > > > > > > > > > > > ie. > > > > > > > > > > > without application change in fastpath > > > > > > > > > > > logic. > > > > > > > > > > > > > > > > > > > > Fastpath have to resolve port ID anyway and forwarding > > > > > > > > > > according > > > > > > > > > > to > > > > > > > > > > logic. Forwarding engine need to adapt to support shard Rxq. > > > > > > > > > > Fortunately, in testpmd, this can be done with an abstract > > > > > > > > > > API. > > > > > > > > > > > > > > > > > > > > Let's defer part 2 until some PMD really support it and > > > > > > > > > > tested, > > > > > > > > > > how do > > > > > > > > > > you think? > > > > > > > > > > > > > > > > > > We are not planning to use this feature so either way it is > > > > > > > > > OK to > > > > > > > > > me. > > > > > > > > > I leave to ethdev maintainers decide between 1 vs 2. > > > > > > > > > > > > > > > > > > I do have a strong opinion not changing the testpmd basic > > > > > > > > > forward > > > > > > > > > engines > > > > > > > > > for this feature.I would like to keep it simple as fastpath > > > > > > > > > optimized and would > > > > > > > > > like to add a separate Forwarding engine as means to verify > > > > > > > > > this > > > > > > > > > feature. > > > > > > > > > > > > > > > > +1 to that. > > > > > > > > I don't think it a 'common' feature. > > > > > > > > So separate FWD mode seems like a best choice to me. > > > > > > > > > > > > > > -1 :) > > > > > > > There was some internal requirement from test team, they need to > > > > > > > verify > > > > > > > > > > > > > > > > > > > > Internal QA requirements may not be the driving factor :-) > > > > > > > > > > It will be a test requirement for any driver to face, not internal. > > > > > The > > > > > performance difference almost zero in v3, only an "unlikely if" test > > > > > on > > > > > each burst. Shared Rxq is a low level feature, reusing all current FWD > > > > > engines to verify driver high level features is important IMHO. > > > > > > > > In addition to additional if check, The real concern is polluting the > > > > common forward engine for the not common feature. > > > > > > Okay, removed changes to common forward engines in v4, please check. > > > > Thanks. > > > > > > > > > > > > > If you really want to reuse the existing application without any > > > > application change, > > > > I think, you need to hook this to eventdev > > > > http://code.dpdk.org/dpdk/latest/source/lib/eventdev/rte_eventdev.h#L34 > > > > > > > > Where eventdev drivers does this thing in addition to other features, > > > > Ie. > > > > t has ports (which is kind of aggregator), > > > > it can receive the packets from any queue with mbuf->port as actually > > > > received port. > > > > That is in terms of mapping: > > > > - event queue will be dummy it will be as same as Rx queue > > > > - Rx adapter will be also a dummy > > > > - event ports aggregate multiple queues and connect to core via event > > > > port > > > > - On Rxing the packet, mbuf->port will be the actual Port which is > > > > received. > > > > app/test-eventdev written to use this model. > > > > > > Is this the optional aggregator api we discussed? already there, patch > > > 2/6. > > > I was trying to make common forwarding engines perfect to support any > > > case, but since you all have concerns, removed in v4. > > > > The point was, If we take eventdev Rx adapter path, This all thing can > > be implemented > > without adding any new APIs in ethdev as similar functionality is > > supported ethdeev-eventdev > > Rx adapter. Now two things, > > > > 1) Aggregator API is not required, We will be taking the eventdev Rx > > adapter route this implement it > > 2) Another mode it is possible to implement it with eventdev Rx > > adapter. So I leave to ethdev > > maintainers to decide if this path is required or not. No strong > > opinion on this. > > Seems you are expert of event, is this the Rx burst api? > rte_event_dequeue_burst(dev_id, port_id, ev[], nb_events, timeout)
Yes. > > Two concerns from user perspective: > 1. By using ethdev-eventdev wrapper, it impacts performance. It is not a wrapper. If HW doing the work then there will not be any regression with the Rx adapter. Like tx_burst, packet/event comes through rte_event_dequeue_burst() aka single callback function pointer overhead. > 2. For user application like OVS, using event api just when shared rxq > enable looks strange. > > Maybe I missed something? > > There should be more feedkback and idea on how to aggregate ports after > the fundamental(offload bit and group) start to work, agree to remove > the aggregator api for now. OK. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > all features like packet content, rss, vlan, checksum, > > > > > > > rte_flow... to > > > > > > > be working based on shared rx queue. Based on the patch, I > > > > > > > believe the > > > > > > > impact has been minimized. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Overall, is this for optimizing memory for the > > > > > > > > > > > > > > > port > > > > > > > > > > > > > > > represontors? If so can't we > > > > > > > > > > > > > > > have a port representor specific solution, > > > > > > > > > > > > > > > reducing > > > > > > > > > > > > > > > scope can reduce the > > > > > > > > > > > > > > > complexity it brings? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this offload is only useful for representor > > > > > > > > > > > > > > > > > case, Can we make this offload specific to > > > > > > > > > > > > > > > > > representor the case by changing its > > > > > > > > > name and > > > > > > > > > > > > > > > > > scope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It works for both PF and representors in same > > > > > > > > > > > > > > > > switch > > > > > > > > > > > > > > > > domain, for application like OVS, few changes to > > > > > > > > > > > > > > > > apply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Xueming Li > > > > > > > > > > > > > > > > > > > > <xuemi...@nvidia.com> > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > doc/guides/nics/features.rst > > > > > > > > > > > > > > > > > > > > > 11 +++++++++++ > > > > > > > > > > > > > > > > > > > > doc/guides/nics/features/default.ini > > > > > > > > > > > > > > > > > > > > > 1 + > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > doc/guides/prog_guide/switch_representation. > > > > > > > > > > > > > > > > > > > > rst | 10 ++++++++++ > > > > > > > > > > > > > > > > > > > > lib/ethdev/rte_ethdev.c > > > > > > > > > > > > > > > > > > > > > 1 + > > > > > > > > > > > > > > > > > > > > lib/ethdev/rte_ethdev.h > > > > > > > > > > > > > > > > > > > > > 7 +++++++ > > > > > > > > > > > > > > > > > > > > 5 files changed, 30 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > > > > > > > > > > a/doc/guides/nics/features.rst > > > > > > > > > > > > > > > > > > > > b/doc/guides/nics/features.rst index > > > > > > > > > > > > > > > > > > > > a96e12d155..2e2a9b1554 100644 > > > > > > > > > > > > > > > > > > > > --- a/doc/guides/nics/features.rst > > > > > > > > > > > > > > > > > > > > +++ b/doc/guides/nics/features.rst > > > > > > > > > > > > > > > > > > > > @@ -624,6 +624,17 @@ Supports inner > > > > > > > > > > > > > > > > > > > > packet L4 > > > > > > > > > > > > > > > > > > > > checksum. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ``tx_offload_capa,tx_queue_offload_capa:DE > > > > > > > > > > > > > > > > > > > > V_TX_OFFLOAD_OUTER_UDP_CKSUM``. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +.. _nic_features_shared_rx_queue: > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > +Shared Rx queue > > > > > > > > > > > > > > > > > > > > +--------------- > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > +Supports shared Rx queue for ports in > > > > > > > > > > > > > > > > > > > > same > > > > > > > > > > > > > > > > > > > > switch domain. > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > +* **[uses] > > > > > > > > > > > > > > > > > > > > rte_eth_rxconf,rte_eth_rxmode**: > > > > > > > > > > > > > > > > > > > > ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. > > > > > > > > > > > > > > > > > > > > +* **[provides] mbuf**: ``mbuf.port``. > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > .. _nic_features_packet_type_parsing: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Packet type parsing > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > > > > > > > > > > a/doc/guides/nics/features/default.ini > > > > > > > > > > > > > > > > > > > > b/doc/guides/nics/features/default.ini > > > > > > > > > > > > > > > > > > > > index 754184ddd4..ebeb4c1851 100644 > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > a/doc/guides/nics/features/default.ini > > > > > > > > > > > > > > > > > > > > +++ > > > > > > > > > > > > > > > > > > > > b/doc/guides/nics/features/default.ini > > > > > > > > > > > > > > > > > > > > @@ -19,6 +19,7 @@ Free Tx mbuf on > > > > > > > > > > > > > > > > > > > > demand = > > > > > > > > > > > > > > > > > > > > Queue start/stop = > > > > > > > > > > > > > > > > > > > > Runtime Rx queue setup = > > > > > > > > > > > > > > > > > > > > Runtime Tx queue setup = > > > > > > > > > > > > > > > > > > > > +Shared Rx queue = > > > > > > > > > > > > > > > > > > > > Burst mode info = > > > > > > > > > > > > > > > > > > > > Power mgmt address monitor = > > > > > > > > > > > > > > > > > > > > MTU update = > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > > > > > > > > > > > > > > > a/doc/guides/prog_guide/switch_representation > > > > > > > > > > > > > > > > > > > > .rst > > > > > > > > > > > > > > > > > > > > b/doc/guides/prog_guide/switch_representation > > > > > > > > > > > > > > > > > > > > .rst > > > > > > > > > > > > > > > > > > > > index ff6aa91c80..45bf5a3a10 100644 > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > a/doc/guides/prog_guide/switch_representation > > > > > > > > > > > > > > > > > > > > .rst > > > > > > > > > > > > > > > > > > > > +++ > > > > > > > > > > > > > > > > > > > > b/doc/guides/prog_guide/switch_representation > > > > > > > > > > > > > > > > > > > > .rst > > > > > > > > > > > > > > > > > > > > @@ -123,6 +123,16 @@ thought as a > > > > > > > > > > > > > > > > > > > > software > > > > > > > > > > > > > > > > > > > > "patch panel" front-end for > > > > > > > > > > > > > > > > > > > > applications. > > > > > > > > > > > > > > > > > > > > .. [1] `Ethernet switch device driver > > > > > > > > > > > > > > > > > > > > model > > > > > > > > > > > > > > > > > > > > (switchdev) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <https://www.kernel.org/doc/Documentation/net > > > > > > > > > > > > > > > > > > > > working/switchdev.txt > > > > > > > > > > > > > > > > > > > > > `_ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +- Memory usage of representors is huge > > > > > > > > > > > > > > > > > > > > when > > > > > > > > > > > > > > > > > > > > number of representor > > > > > > > > > > > > > > > > > > > > +grows, > > > > > > > > > > > > > > > > > > > > + because PMD always allocate mbuf for > > > > > > > > > > > > > > > > > > > > each > > > > > > > > > > > > > > > > > > > > descriptor of Rx queue. > > > > > > > > > > > > > > > > > > > > + Polling the large number of ports > > > > > > > > > > > > > > > > > > > > brings > > > > > > > > > > > > > > > > > > > > more CPU load, cache > > > > > > > > > > > > > > > > > > > > +miss and > > > > > > > > > > > > > > > > > > > > + latency. Shared Rx queue can be used > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > share Rx queue between > > > > > > > > > > > > > > > > > > > > +PF and > > > > > > > > > > > > > > > > > > > > + representors in same switch domain. > > > > > > > > > > > > > > > > > > > > +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` > > > > > > > > > > > > > > > > > > > > + is present in Rx offloading > > > > > > > > > > > > > > > > > > > > capability of > > > > > > > > > > > > > > > > > > > > device info. Setting > > > > > > > > > > > > > > > > > > > > +the > > > > > > > > > > > > > > > > > > > > + offloading flag in device Rx mode or > > > > > > > > > > > > > > > > > > > > Rx > > > > > > > > > > > > > > > > > > > > queue configuration to > > > > > > > > > > > > > > > > > > > > +enable > > > > > > > > > > > > > > > > > > > > + shared Rx queue. Polling any member > > > > > > > > > > > > > > > > > > > > port > > > > > > > > > > > > > > > > > > > > of shared Rx queue can > > > > > > > > > > > > > > > > > > > > +return > > > > > > > > > > > > > > > > > > > > + packets of all ports in group, port > > > > > > > > > > > > > > > > > > > > ID is > > > > > > > > > > > > > > > > > > > > saved in ``mbuf.port``. > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > Basic SR-IOV > > > > > > > > > > > > > > > > > > > > ------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/lib/ethdev/rte_ethdev.c > > > > > > > > > > > > > > > > > > > > b/lib/ethdev/rte_ethdev.c > > > > > > > > > > > > > > > > > > > > index 9d95cd11e1..1361ff759a 100644 > > > > > > > > > > > > > > > > > > > > --- a/lib/ethdev/rte_ethdev.c > > > > > > > > > > > > > > > > > > > > +++ b/lib/ethdev/rte_ethdev.c > > > > > > > > > > > > > > > > > > > > @@ -127,6 +127,7 @@ static const struct > > > > > > > > > > > > > > > > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU > > > > > > > > > > > > > > > > > > > > M), > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RTE_RX_OFFLOAD_BIT2STR(RSS_HASH), > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL > > > > > > > > > > > > > > > > > > > > IT), > > > > > > > > > > > > > > > > > > > > + > > > > > > > > > > > > > > > > > > > > RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), > > > > > > > > > > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #undef RTE_RX_OFFLOAD_BIT2STR > > > > > > > > > > > > > > > > > > > > diff --git a/lib/ethdev/rte_ethdev.h > > > > > > > > > > > > > > > > > > > > b/lib/ethdev/rte_ethdev.h > > > > > > > > > > > > > > > > > > > > index d2b27c351f..a578c9db9d 100644 > > > > > > > > > > > > > > > > > > > > --- a/lib/ethdev/rte_ethdev.h > > > > > > > > > > > > > > > > > > > > +++ b/lib/ethdev/rte_ethdev.h > > > > > > > > > > > > > > > > > > > > @@ -1047,6 +1047,7 @@ struct > > > > > > > > > > > > > > > > > > > > rte_eth_rxconf { > > > > > > > > > > > > > > > > > > > > uint8_t rx_drop_en; /**< Drop > > > > > > > > > > > > > > > > > > > > packets > > > > > > > > > > > > > > > > > > > > if no descriptors are available. */ > > > > > > > > > > > > > > > > > > > > uint8_t rx_deferred_start; /**< > > > > > > > > > > > > > > > > > > > > Do > > > > > > > > > > > > > > > > > > > > not start queue with > > > > > > > > > > > > > > > > > > > > rte_eth_dev_start(). */ > > > > > > > > > > > > > > > > > > > > uint16_t rx_nseg; /**< Number of > > > > > > > > > > > > > > > > > > > > descriptions in rx_seg array. > > > > > > > > > > > > > > > > > > > > */ > > > > > > > > > > > > > > > > > > > > + uint32_t shared_group; /**< > > > > > > > > > > > > > > > > > > > > Shared > > > > > > > > > > > > > > > > > > > > port group index in > > > > > > > > > > > > > > > > > > > > + switch domain. */ > > > > > > > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > > > > > > > * Per-queue Rx offloads to be > > > > > > > > > > > > > > > > > > > > set > > > > > > > > > > > > > > > > > > > > using DEV_RX_OFFLOAD_* flags. > > > > > > > > > > > > > > > > > > > > * Only offloads set on > > > > > > > > > > > > > > > > > > > > rx_queue_offload_capa or > > > > > > > > > > > > > > > > > > > > rx_offload_capa @@ -1373,6 +1374,12 @@ > > > > > > > > > > > > > > > > > > > > struct > > > > > > > > > > > > > > > > > > > > rte_eth_conf { > > > > > > > > > > > > > > > > > > > > #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM > > > > > > > > > > > > > > > > > > > > 0x00040000 > > > > > > > > > > > > > > > > > > > > #define DEV_RX_OFFLOAD_RSS_HASH > > > > > > > > > > > > > > > > > > > > 0x00080000 > > > > > > > > > > > > > > > > > > > > #define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT > > > > > > > > > > > > > > > > > > > > 0x00100000 > > > > > > > > > > > > > > > > > > > > +/** > > > > > > > > > > > > > > > > > > > > + * Rx queue is shared among ports in > > > > > > > > > > > > > > > > > > > > same > > > > > > > > > > > > > > > > > > > > switch domain to save > > > > > > > > > > > > > > > > > > > > +memory, > > > > > > > > > > > > > > > > > > > > + * avoid polling each port. Any port in > > > > > > > > > > > > > > > > > > > > group can be used to receive packets. > > > > > > > > > > > > > > > > > > > > + * Real source port number saved in > > > > > > > > > > > > > > > > > > > > mbuf- > > > > > > > > > > > > > > > > > > > > > port field. > > > > > > > > > > > > > > > > > > > > + */ > > > > > > > > > > > > > > > > > > > > +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ > > > > > > > > > > > > > > > > > > > > 0x00200000 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #define DEV_RX_OFFLOAD_CHECKSUM > > > > > > > > > > > > > > > > > > > > (DEV_RX_OFFLOAD_IPV4_CKSUM | \ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > DEV_RX_OFFLO > > > > > > > > > > > > > > > > > > > > AD_UDP_CKSUM | \ > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > 2.25.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
