* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 19:43 0% ` Ajit Khaparde
@ 2022-07-13 12:11 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-07-13 12:11 UTC (permalink / raw)
To: Ajit Khaparde
Cc: Jerin Jacob Kollanukkaran, dpdk-dev, Ferruh Yigit,
Thomas Monjalon, Andrew Rybchenko, Andrew Boyer, Beilei Xing,
Bruce Richardson, Chas Williams, Xia, Chenbo, Ciara Loftus,
Devendra Singh Rawat, Ed Czeck, Evgeny Schemeilin, Gaetan Rivet,
Gagandeep Singh, Guoyang Zhou, Haiyue Wang, Harman Kalra,
Heinrich Kuhn, Hemant Agrawal, Hyong Youb Kim, Igor Chauskin,
Igor Russkikh, Jakub Grajciar, Singh, Jasvinder, Jian Wang,
Jiawen Wu, Jingjing Wu, John Daley, John Miller,
John W. Linville, Wiles, Keith, Kiran Kumar K, oulijun,
Liron Himi, Long Li, Marcin Wojtas, Martin Spinler, Matan Azrad,
Matt Peters, Maxime Coquelin, Michal Krawczyk, Min Hu (Connor),
Nalla Pradeep, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
Rosen Xu, Sachin Saxena (OSS),
Satha Rao, Shahed Shaikh, Shai Brandes, Shepard Siegel,
Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
Veerasenareddy Burru, Slava Ovsiienko, Xiao Wang, Xiaoyun Wang,
Yisen Zhuang, Yong Wang, Ziyang Xuan, Dumitrescu, Cristian
On Tue, May 31, 2022 at 1:13 AM Ajit Khaparde
<ajit.khaparde@broadcom.com> wrote:
>
> On Mon, May 30, 2022 at 6:16 AM <jerinj@marvell.com> wrote:
> >
> > From: Jerin Jacob <jerinj@marvell.com>
> >
> > NIC HW controllers often come with congestion management support on
> > various HW objects such as Rx queue depth or mempool queue depth.
> >
> > Also, it can support various modes of operation such as RED
> > (Random early discard), WRED etc on those HW objects.
> >
> > This patch adds a framework to express such modes(enum rte_cman_mode)
> > and introduce (enum rte_eth_cman_obj) to enumerate the different
> > objects where the modes can operate on.
> >
> > This patch adds RTE_CMAN_RED mode of operation and
> > RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
> >
> > Introduced reserved fields in configuration structure
> > backed by rte_eth_cman_config_init() to add new configuration
> > parameters without ABI breakage.
> >
> > Added rte_eth_cman_info_get() API to get the information such as
> > supported modes and objects.
> >
> > Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> > to configure congestion management on those object with associated mode.
> >
> > Finally, Added rte_eth_cman_config_get() API to retrieve the
> > applied configuration.
>
> Can you also add How all this helps an application? Thanks
Random early detection (RED), also known as random early discard or
random early drop is a queuing discipline for a network scheduler
suited for congestion avoidance.
In the conventional tail drop algorithm, a router or other network
component buffers as many packets as it can, and simply drops the ones
it cannot buffer. If buffers are constantly full, the network is
congested. Tail drop distributes buffer space unfairly among traffic
flows. Tail drop can also lead to TCP global synchronization as all
TCP connections "hold back" simultaneously, and then step forward
simultaneously. Networks become under-utilized and
flooded—alternately, in waves.
RED addresses these issues by pre-emptively dropping packets before
the buffer becomes completely full. It uses predictive models to
decide which packets to drop.
it is copied from https://en.wikipedia.org/wiki/Random_early_detection
page. I have kept this URL under enum rte_cman_mode:: RTE_CMAN_RED
too.
Also I will add original specification URL too,
http://www.aciri.org/floyd/papers/red/red.html.
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/2] doc: announce region based device mapping support
2022-07-13 7:27 3% ` Xia, Chenbo
@ 2022-07-13 7:38 0% ` Sunil Kumar Kori
0 siblings, 0 replies; 200+ results
From: Sunil Kumar Kori @ 2022-07-13 7:38 UTC (permalink / raw)
To: Xia, Chenbo, Ray Kinsella; +Cc: dev, David Marchand
Regards
Sunil Kumar Kori
> -----Original Message-----
> From: Xia, Chenbo <chenbo.xia@intel.com>
> Sent: Wednesday, July 13, 2022 12:58 PM
> To: Sunil Kumar Kori <skori@marvell.com>; Ray Kinsella <mdr@ashroe.eu>
> Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> Subject: [EXT] RE: [PATCH 1/2] doc: announce region based device mapping
> support
>
> External Email
>
> ----------------------------------------------------------------------
> Hi Sunil,
>
> > -----Original Message-----
> > From: Sunil Kumar Kori <skori@marvell.com>
> > Sent: Wednesday, July 13, 2022 3:04 PM
> > To: Xia, Chenbo <chenbo.xia@intel.com>; Ray Kinsella <mdr@ashroe.eu>
> > Cc: dev@dpdk.org
> > Subject: RE: [PATCH 1/2] doc: announce region based device mapping
> > support
> >
> > Hi Chenbo,
> >
> > There are pci devices which has huge BAR memory but might not be used
> > completely.
> > Like PCIe device DDR memory is exposed over BAR with 32Gb or so.
> > So in that case user might have a requirement to mmap only areas of
> > its interest.
> > Also avoid wasting of extra memory for each pages when kernel mmaps it.
>
> This problem statement makes sense to me. About the solution, pls check
> below.
>
> >
> > Yes, it is similar to sparse mmap in vfio but I didn't find any
> > support in DPDK for sparse mmap.
> > So I picked this approach but in either case, ABI change notification
> > is needed, Right?
>
> For ABI, David & I already mentioned in another email that your notice is not
> needed anymore.
>
> What if you send the patchset to support sparse mmap in DPDK, to me, that
> seems more generic. Could sparse mmap solve your problem?
I will look into sparse mmap and analyze its feasibility to solve my problem.
Will update accordingly.
Thanks Chenbo and David.
>
> Thanks,
> Chenbo
>
> >
> > Regards
> > Sunil Kumar Kori
> >
> > > -----Original Message-----
> > > From: Xia, Chenbo <chenbo.xia@intel.com>
> > > Sent: Thursday, July 7, 2022 6:09 PM
> > > To: Sunil Kumar Kori <skori@marvell.com>; Ray Kinsella
> > > <mdr@ashroe.eu>
> > > Cc: dev@dpdk.org
> > > Subject: [EXT] RE: [PATCH 1/2] doc: announce region based device
> > > mapping support
> > >
> > > External Email
> > >
> > > --------------------------------------------------------------------
> > > --
> > > Hi Sunil,
> > >
> > > > -----Original Message-----
> > > > From: skori@marvell.com <skori@marvell.com>
> > > > Sent: Tuesday, June 28, 2022 9:54 PM
> > > > To: Ray Kinsella <mdr@ashroe.eu>
> > > > Cc: dev@dpdk.org; Sunil Kumar Kori <skori@marvell.com>
> > > > Subject: [PATCH 1/2] doc: announce region based device mapping
> > > > support
> > > >
> > > > From: Sunil Kumar Kori <skori@marvell.com>
> > > >
> > > > Adding region based device mapping support, which enables pci
> > > > device to map only required memory region instead of mapping full
> BAR.
> > >
> > > Why there will be such requirement to mmap only part of BAR when the
> > > BAR can be fully mmapped. I thought you want to enable something
> > > like sparse mmap feature in VFIO, but seems it's a feature that let
> > > driver ask for
> > specific
> > > mmap option. Could you explain the use case here?
> > >
> > > Thanks,
> > > Chenbo
> > >
> > > >
> > > > Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> > > > ---
> > > > doc/guides/rel_notes/deprecation.rst | 13 +++++++++++++
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > b/doc/guides/rel_notes/deprecation.rst
> > > > index 4e5b23c53d..8800a3eb41 100644
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > @@ -125,3 +125,16 @@ Deprecation Notices
> > > > applications should be updated to use the ``dmadev`` library
> > instead,
> > > > with the underlying HW-functionality being provided by the
> > > > ``ioat``
> > or
> > > > ``idxd`` dma drivers
> > > > +
> > > > +* pci: Update ``rte_pci_device`` and ``rte_pci_driver`` to add
> > > > +region
> > > > based
> > > > + memory mapping support. There could be a requirement to mmap
> > > > + specific
> > > > memory
> > > > + region only. Using this mechanism, pci device can be mapped for
> > > > + a given BAR at a given offset of given size.
> > > > +
> > > > + ``rte_pci_device`` will be added with following field
> > > > + ``regions[PCI_MAX_RESOURCE][PCI_MAX_REGION_PER_RESOURCE];``.
> > > This
> > > > + field
> > > > will
> > > > + specify the regions which are mapped for a given BAR.
> > > > +
> > > > + ``rte_pci_driver`` will be added with ``rte_pci_region_map
> > > > + *regions``
> > > > and
> > > > + ``valid_bars[PCI_MAX_RESOURCE]``. Using these fields, driver
> > > > + can
> > > > propagate
> > > > + its region information which are required to be mmap.
> > > > --
> > > > 2.25.1
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/2] doc: announce region based device mapping support
2022-07-13 7:03 3% ` Sunil Kumar Kori
@ 2022-07-13 7:27 3% ` Xia, Chenbo
2022-07-13 7:38 0% ` Sunil Kumar Kori
0 siblings, 1 reply; 200+ results
From: Xia, Chenbo @ 2022-07-13 7:27 UTC (permalink / raw)
To: Sunil Kumar Kori, Ray Kinsella; +Cc: dev, David Marchand
Hi Sunil,
> -----Original Message-----
> From: Sunil Kumar Kori <skori@marvell.com>
> Sent: Wednesday, July 13, 2022 3:04 PM
> To: Xia, Chenbo <chenbo.xia@intel.com>; Ray Kinsella <mdr@ashroe.eu>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH 1/2] doc: announce region based device mapping support
>
> Hi Chenbo,
>
> There are pci devices which has huge BAR memory but might not be used
> completely.
> Like PCIe device DDR memory is exposed over BAR with 32Gb or so.
> So in that case user might have a requirement to mmap only areas of its
> interest.
> Also avoid wasting of extra memory for each pages when kernel mmaps it.
This problem statement makes sense to me. About the solution, pls check below.
>
> Yes, it is similar to sparse mmap in vfio but I didn't find any support in
> DPDK for sparse mmap.
> So I picked this approach but in either case, ABI change notification is
> needed, Right?
For ABI, David & I already mentioned in another email that your notice is not
needed anymore.
What if you send the patchset to support sparse mmap in DPDK, to me, that seems
more generic. Could sparse mmap solve your problem?
Thanks,
Chenbo
>
> Regards
> Sunil Kumar Kori
>
> > -----Original Message-----
> > From: Xia, Chenbo <chenbo.xia@intel.com>
> > Sent: Thursday, July 7, 2022 6:09 PM
> > To: Sunil Kumar Kori <skori@marvell.com>; Ray Kinsella <mdr@ashroe.eu>
> > Cc: dev@dpdk.org
> > Subject: [EXT] RE: [PATCH 1/2] doc: announce region based device mapping
> > support
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > Hi Sunil,
> >
> > > -----Original Message-----
> > > From: skori@marvell.com <skori@marvell.com>
> > > Sent: Tuesday, June 28, 2022 9:54 PM
> > > To: Ray Kinsella <mdr@ashroe.eu>
> > > Cc: dev@dpdk.org; Sunil Kumar Kori <skori@marvell.com>
> > > Subject: [PATCH 1/2] doc: announce region based device mapping support
> > >
> > > From: Sunil Kumar Kori <skori@marvell.com>
> > >
> > > Adding region based device mapping support, which enables pci device
> > > to map only required memory region instead of mapping full BAR.
> >
> > Why there will be such requirement to mmap only part of BAR when the BAR
> > can be fully mmapped. I thought you want to enable something like sparse
> > mmap feature in VFIO, but seems it's a feature that let driver ask for
> specific
> > mmap option. Could you explain the use case here?
> >
> > Thanks,
> > Chenbo
> >
> > >
> > > Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> > > ---
> > > doc/guides/rel_notes/deprecation.rst | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > b/doc/guides/rel_notes/deprecation.rst
> > > index 4e5b23c53d..8800a3eb41 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -125,3 +125,16 @@ Deprecation Notices
> > > applications should be updated to use the ``dmadev`` library
> instead,
> > > with the underlying HW-functionality being provided by the ``ioat``
> or
> > > ``idxd`` dma drivers
> > > +
> > > +* pci: Update ``rte_pci_device`` and ``rte_pci_driver`` to add region
> > > based
> > > + memory mapping support. There could be a requirement to mmap
> > > + specific
> > > memory
> > > + region only. Using this mechanism, pci device can be mapped for a
> > > + given BAR at a given offset of given size.
> > > +
> > > + ``rte_pci_device`` will be added with following field
> > > + ``regions[PCI_MAX_RESOURCE][PCI_MAX_REGION_PER_RESOURCE];``.
> > This
> > > + field
> > > will
> > > + specify the regions which are mapped for a given BAR.
> > > +
> > > + ``rte_pci_driver`` will be added with ``rte_pci_region_map
> > > + *regions``
> > > and
> > > + ``valid_bars[PCI_MAX_RESOURCE]``. Using these fields, driver can
> > > propagate
> > > + its region information which are required to be mmap.
> > > --
> > > 2.25.1
^ permalink raw reply [relevance 3%]
* RE: [PATCH 1/2] doc: announce region based device mapping support
@ 2022-07-13 7:21 3% ` Xia, Chenbo
0 siblings, 0 replies; 200+ results
From: Xia, Chenbo @ 2022-07-13 7:21 UTC (permalink / raw)
To: David Marchand, Sunil Kumar Kori; +Cc: Ray Kinsella, dev, Thomas Monjalon
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Wednesday, July 13, 2022 3:18 PM
> To: Sunil Kumar Kori <skori@marvell.com>
> Cc: Ray Kinsella <mdr@ashroe.eu>; dev <dev@dpdk.org>; Xia, Chenbo
> <chenbo.xia@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: [PATCH 1/2] doc: announce region based device mapping support
>
> On Tue, Jun 28, 2022 at 3:56 PM <skori@marvell.com> wrote:
> >
> > From: Sunil Kumar Kori <skori@marvell.com>
> >
> > Adding region based device mapping support, which enables pci device
> > to map only required memory region instead of mapping full BAR.
> >
> > Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> > index 4e5b23c53d..8800a3eb41 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -125,3 +125,16 @@ Deprecation Notices
> > applications should be updated to use the ``dmadev`` library instead,
> > with the underlying HW-functionality being provided by the ``ioat``
> or
> > ``idxd`` dma drivers
> > +
> > +* pci: Update ``rte_pci_device`` and ``rte_pci_driver`` to add region
> based
> > + memory mapping support. There could be a requirement to mmap specific
> memory
> > + region only. Using this mechanism, pci device can be mapped for
> > + a given BAR at a given offset of given size.
> > +
> > + ``rte_pci_device`` will be added with following field
> > + ``regions[PCI_MAX_RESOURCE][PCI_MAX_REGION_PER_RESOURCE];``. This
> field will
> > + specify the regions which are mapped for a given BAR.
> > +
> > + ``rte_pci_driver`` will be added with ``rte_pci_region_map *regions``
> and
> > + ``valid_bars[PCI_MAX_RESOURCE]``. Using these fields, driver can
> propagate
> > + its region information which are required to be mmap.
>
> I don't think we need a new deprecation notice for this.
> We still have Chenbo current notice:
> https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst#n46
>
> Besides, my proposal hides every bus specific device representations,
> and I think it covers your needs too.
> See https://patches.dpdk.org/project/dpdk/patch/20220710061736.973563-1-
> david.marchand@redhat.com/
>
> Did I miss something?
Agree, I am about to say this :)
Sunil, with David's patchset, you can just send your patchset. David will help
clean-up the ABI for you.
Thanks,
Chenbo
>
>
> --
> David Marchand
^ permalink raw reply [relevance 3%]
* RE: [PATCH 1/2] doc: announce region based device mapping support
@ 2022-07-13 7:03 3% ` Sunil Kumar Kori
2022-07-13 7:27 3% ` Xia, Chenbo
0 siblings, 1 reply; 200+ results
From: Sunil Kumar Kori @ 2022-07-13 7:03 UTC (permalink / raw)
To: Xia, Chenbo, Ray Kinsella; +Cc: dev
Hi Chenbo,
There are pci devices which has huge BAR memory but might not be used completely.
Like PCIe device DDR memory is exposed over BAR with 32Gb or so.
So in that case user might have a requirement to mmap only areas of its interest.
Also avoid wasting of extra memory for each pages when kernel mmaps it.
Yes, it is similar to sparse mmap in vfio but I didn't find any support in DPDK for sparse mmap.
So I picked this approach but in either case, ABI change notification is needed, Right?
Regards
Sunil Kumar Kori
> -----Original Message-----
> From: Xia, Chenbo <chenbo.xia@intel.com>
> Sent: Thursday, July 7, 2022 6:09 PM
> To: Sunil Kumar Kori <skori@marvell.com>; Ray Kinsella <mdr@ashroe.eu>
> Cc: dev@dpdk.org
> Subject: [EXT] RE: [PATCH 1/2] doc: announce region based device mapping
> support
>
> External Email
>
> ----------------------------------------------------------------------
> Hi Sunil,
>
> > -----Original Message-----
> > From: skori@marvell.com <skori@marvell.com>
> > Sent: Tuesday, June 28, 2022 9:54 PM
> > To: Ray Kinsella <mdr@ashroe.eu>
> > Cc: dev@dpdk.org; Sunil Kumar Kori <skori@marvell.com>
> > Subject: [PATCH 1/2] doc: announce region based device mapping support
> >
> > From: Sunil Kumar Kori <skori@marvell.com>
> >
> > Adding region based device mapping support, which enables pci device
> > to map only required memory region instead of mapping full BAR.
>
> Why there will be such requirement to mmap only part of BAR when the BAR
> can be fully mmapped. I thought you want to enable something like sparse
> mmap feature in VFIO, but seems it's a feature that let driver ask for specific
> mmap option. Could you explain the use case here?
>
> Thanks,
> Chenbo
>
> >
> > Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 4e5b23c53d..8800a3eb41 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -125,3 +125,16 @@ Deprecation Notices
> > applications should be updated to use the ``dmadev`` library instead,
> > with the underlying HW-functionality being provided by the ``ioat`` or
> > ``idxd`` dma drivers
> > +
> > +* pci: Update ``rte_pci_device`` and ``rte_pci_driver`` to add region
> > based
> > + memory mapping support. There could be a requirement to mmap
> > + specific
> > memory
> > + region only. Using this mechanism, pci device can be mapped for a
> > + given BAR at a given offset of given size.
> > +
> > + ``rte_pci_device`` will be added with following field
> > + ``regions[PCI_MAX_RESOURCE][PCI_MAX_REGION_PER_RESOURCE];``.
> This
> > + field
> > will
> > + specify the regions which are mapped for a given BAR.
> > +
> > + ``rte_pci_driver`` will be added with ``rte_pci_region_map
> > + *regions``
> > and
> > + ``valid_bars[PCI_MAX_RESOURCE]``. Using these fields, driver can
> > propagate
> > + its region information which are required to be mmap.
> > --
> > 2.25.1
^ permalink raw reply [relevance 3%]
* Re: [EXT] Re: [PATCH v2 1/1] doc: announce addition of new ipsec event subtypes
2022-07-12 15:30 0% ` [EXT] " Akhil Goyal
@ 2022-07-12 20:44 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-07-12 20:44 UTC (permalink / raw)
To: Vamsi Krishna Attunuru, Akhil Goyal
Cc: dev, Jerin Jacob Kollanukkaran, Vamsi Krishna Attunuru,
ferruh.yigit, Anoob Joseph, mdr
12/07/2022 17:30, Akhil Goyal:
> > 27/06/2022 07:29, Vamsi Attunuru:
> > > New event subtypes need to be added for notifying expiry events
> > > upon reaching IPsec SA soft packet expiry and hard packet/byte
> > > expiry limits. This would be added in DPDK 22.11.
> > >
> > > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> > > Acked-by: Akhil Goyal <gakhil@marvell.com>
> > > ---
> > > More details on new event subtype proposal discussion are in below email
> > thread.
> > > https://patches.dpdk.org/project/dpdk/patch/20220416192530.173895-8-gakhil@marvell.com/> >
> > > v2: rephrase title and git log.
> > > ---
> > > +* ethdev: The enum ``rte_eth_event_ipsec_subtype`` would be extended to
> > add
> > > + new subtype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``,
> > > + ``RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and
> > > + ``RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11.
> >
> > While at it, would you consider avoiding future ABI breakage
> > with RTE_ETH_EVENT_IPSEC_MAX?
>
> For MAX values there is already a generic notice. Do you want to mention this here as well?
> IMO, it is not required. We can work on it, but do not need explicit mention here.
OK I forgot we had already a generic notice.
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v2 1/1] doc: announce addition of new ipsec event subtypes
2022-07-12 15:03 3% ` Thomas Monjalon
@ 2022-07-12 15:30 0% ` Akhil Goyal
2022-07-12 20:44 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-07-12 15:30 UTC (permalink / raw)
To: Thomas Monjalon, Vamsi Krishna Attunuru
Cc: dev, Jerin Jacob Kollanukkaran, Vamsi Krishna Attunuru,
ferruh.yigit, Anoob Joseph, mdr
> 27/06/2022 07:29, Vamsi Attunuru:
> > New event subtypes need to be added for notifying expiry events
> > upon reaching IPsec SA soft packet expiry and hard packet/byte
> > expiry limits. This would be added in DPDK 22.11.
> >
> > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> > Acked-by: Akhil Goyal <gakhil@marvell.com>
> > ---
> > More details on new event subtype proposal discussion are in below email
> thread.
> > https://patches.dpdk.org/project/dpdk/patch/20220416192530.173895-8-gakhil@marvell.com/> >
> > v2: rephrase title and git log.
> > ---
> > +* ethdev: The enum ``rte_eth_event_ipsec_subtype`` would be extended to
> add
> > + new subtype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``,
> > + ``RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and
> > + ``RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11.
>
> While at it, would you consider avoiding future ABI breakage
> with RTE_ETH_EVENT_IPSEC_MAX?
For MAX values there is already a generic notice. Do you want to mention this here as well?
IMO, it is not required. We can work on it, but do not need explicit mention here.
Regards,
Akhil
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/1] doc: announce addition of new ipsec event subtypes
@ 2022-07-12 15:03 3% ` Thomas Monjalon
2022-07-12 15:30 0% ` [EXT] " Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-07-12 15:03 UTC (permalink / raw)
To: Vamsi Attunuru; +Cc: dev, jerinj, vattunuru, gakhil, ferruh.yigit, anoobj, mdr
27/06/2022 07:29, Vamsi Attunuru:
> New event subtypes need to be added for notifying expiry events
> upon reaching IPsec SA soft packet expiry and hard packet/byte
> expiry limits. This would be added in DPDK 22.11.
>
> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> ---
> More details on new event subtype proposal discussion are in below email thread.
> https://patches.dpdk.org/project/dpdk/patch/20220416192530.173895-8-gakhil@marvell.com/
>
> v2: rephrase title and git log.
> ---
> +* ethdev: The enum ``rte_eth_event_ipsec_subtype`` would be extended to add
> + new subtype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``,
> + ``RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and
> + ``RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11.
While at it, would you consider avoiding future ABI breakage
with RTE_ETH_EVENT_IPSEC_MAX?
^ permalink raw reply [relevance 3%]
* Re: [PATCH] doc: announce marking device and driver objects as internal
2022-07-12 8:24 0% ` Kevin Laatz
@ 2022-07-12 11:38 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2022-07-12 11:38 UTC (permalink / raw)
To: Kevin Laatz, David Marchand, dev, techboard; +Cc: Ray Kinsella
On 7/12/22 11:24, Kevin Laatz wrote:
> On 10/07/2022 07:17, David Marchand wrote:
>> rte_driver and rte_device are unnecessarily exposed in the public
>> API/ABI.
>> Announce that they will be made opaque in the public API and mark
>> associated API as internal.
>> This impacts all bus, as their driver registration mechanism will be
>> made internal.
>>
>> Note: the PCI bus had a similar deprecation notice that we can remove as
>> the new one is more generic.
>>
>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>> ---
>> doc/guides/rel_notes/deprecation.rst | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
> Thanks for working on this cleanup, David!
>
> Acked-by: Kevin Laatz <kevin.laatz@intel.com>
>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking device and driver objects as internal
2022-07-10 6:17 13% [PATCH] doc: announce marking device and driver objects as internal David Marchand
` (3 preceding siblings ...)
2022-07-12 4:25 0% ` Hemant Agrawal
@ 2022-07-12 8:24 0% ` Kevin Laatz
2022-07-12 11:38 0% ` Andrew Rybchenko
4 siblings, 1 reply; 200+ results
From: Kevin Laatz @ 2022-07-12 8:24 UTC (permalink / raw)
To: David Marchand, dev, techboard; +Cc: Ray Kinsella
On 10/07/2022 07:17, David Marchand wrote:
> rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
> Announce that they will be made opaque in the public API and mark
> associated API as internal.
> This impacts all bus, as their driver registration mechanism will be
> made internal.
>
> Note: the PCI bus had a similar deprecation notice that we can remove as
> the new one is more generic.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
Thanks for working on this cleanup, David!
Acked-by: Kevin Laatz <kevin.laatz@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking device and driver objects as internal
2022-07-10 6:17 13% [PATCH] doc: announce marking device and driver objects as internal David Marchand
` (2 preceding siblings ...)
2022-07-11 15:01 0% ` Jerin Jacob
@ 2022-07-12 4:25 0% ` Hemant Agrawal
2022-07-12 8:24 0% ` Kevin Laatz
4 siblings, 0 replies; 200+ results
From: Hemant Agrawal @ 2022-07-12 4:25 UTC (permalink / raw)
To: David Marchand, dev, techboard; +Cc: Ray Kinsella
On 7/10/2022 11:47 AM, David Marchand wrote:
> rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
> Announce that they will be made opaque in the public API and mark
> associated API as internal.
> This impacts all bus, as their driver registration mechanism will be
> made internal.
>
> Note: the PCI bus had a similar deprecation notice that we can remove as
> the new one is more generic.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking device and driver objects as internal
2022-07-10 6:17 13% [PATCH] doc: announce marking device and driver objects as internal David Marchand
2022-07-10 8:25 0% ` Andrew Rybchenko
2022-07-11 2:16 0% ` Xia, Chenbo
@ 2022-07-11 15:01 0% ` Jerin Jacob
2022-07-12 4:25 0% ` Hemant Agrawal
2022-07-12 8:24 0% ` Kevin Laatz
4 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-07-11 15:01 UTC (permalink / raw)
To: David Marchand; +Cc: dpdk-dev, techboard, Ray Kinsella
On Sun, Jul 10, 2022 at 11:48 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
> Announce that they will be made opaque in the public API and mark
> associated API as internal.
> This impacts all bus, as their driver registration mechanism will be
> made internal.
>
> Note: the PCI bus had a similar deprecation notice that we can remove as
> the new one is more generic.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index a9fd6676be..b9cc267b30 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -38,6 +38,13 @@ Deprecation Notices
> external users may still register their bus using a new driver header (see
> ``enable_driver_sdk`` meson option).
>
> +* drivers: As a followup on the work on the ``rte_bus`` object, the
> + ``rte_driver`` and ``rte_device`` objects (and as a domino effect, their
> + bus-specific counterparts) will be made opaque in DPDK 22.11.
> + Registering a driver on a bus will be marked as an internal API:
> + external users may still register their drivers using the bus specific
> + driver header (see ``enable_driver_sdk`` meson option).
> +
> * mempool: Helper macro ``MEMPOOL_HEADER_SIZE()`` is deprecated and will
> be removed in DPDK 22.11. The replacement macro
> ``RTE_MEMPOOL_HEADER_SIZE()`` is internal only.
> @@ -49,11 +56,6 @@ Deprecation Notices
> * mempool: The mempool API macros ``MEMPOOL_PG_*`` are deprecated and
> will be removed in DPDK 22.11.
>
> -* pci: To reduce unnecessary ABIs exposed by DPDK bus driver, "rte_bus_pci.h"
> - will be made internal in 21.11 and macros/data structures/functions defined
> - in the header will not be considered as ABI anymore. This change is inspired
> - by the RFC https://patchwork.dpdk.org/project/dpdk/list/?series=17176.
> -
> * lib: will fix extending some enum/define breaking the ABI. There are multiple
> samples in DPDK that enum/define terminated with a ``.*MAX.*`` value which is
> used by iterators, and arrays holding these values are sized with this
> --
> 2.36.1
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce support for MACsec in rte_security
2022-06-29 7:40 0% ` Zhang, Roy Fan
@ 2022-07-11 15:00 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-07-11 15:00 UTC (permalink / raw)
To: Zhang, Roy Fan
Cc: Akhil Goyal, dev, thomas, david.marchand, hemant.agrawal, anoobj,
konstantin.v.ananyev, ferruh.yigit, andrew.rybchenko,
ndabilpuram, vattunuru, matan, jerinj, jiawenwu, Yang, Qiming
On Wed, Jun 29, 2022 at 1:10 PM Zhang, Roy Fan <roy.fan.zhang@intel.com> wrote:
>
> > -----Original Message-----
> > From: Akhil Goyal <gakhil@marvell.com>
> > Sent: Tuesday, June 28, 2022 8:08 PM
> > To: dev@dpdk.org
> > Cc: thomas@monjalon.net; david.marchand@redhat.com;
> > hemant.agrawal@nxp.com; anoobj@marvell.com;
> > konstantin.v.ananyev@yandex.ru; ferruh.yigit@xilinx.com;
> > andrew.rybchenko@oktetlabs.ru; ndabilpuram@marvell.com;
> > vattunuru@marvell.com; matan@nvidia.com; Zhang, Roy Fan
> > <roy.fan.zhang@intel.com>; jerinj@marvell.com; jiawenwu@trustnetic.com;
> > Yang, Qiming <qiming.yang@intel.com>; Akhil Goyal <gakhil@marvell.com>
> > Subject: [PATCH] doc: announce support for MACsec in rte_security
> >
> > MACsec support is planned for DPDK 22.11, which would
> > result in ABI breakage in some of the rte_security structures.
> > This patch is to give deprecation notice for the affected structures.
> >
> > Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 4e5b23c53d..1c3bf54d72 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -116,6 +116,11 @@ Deprecation Notices
> > pointer for the private data to the application which can be attached
> > to the packet while enqueuing.
> >
> > +* security: MACsec support is planned to be added in DPDK 22.11 which
> > would
> > + result in updates to structures ``rte_security_macsec_xform``,
> > + ``rte_security_macsec_stats`` and security capability structure
> > + ``rte_security_capability`` to accomodate MACsec capabilities.
> > +
> > * metrics: The function ``rte_metrics_init`` will have a non-void return
> > in order to notify errors instead of calling ``rte_exit``.
> >
> > --
> > 2.25.1
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 2/2] doc: announce KNI deprecation
@ 2022-07-11 14:47 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-07-11 14:47 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Ray Kinsella, dpdk-dev, Olivier Matz Olivier Matz,
David Marchand David Marchand,
Stephen Hemminger Stephen Hemminger, Elad Nachman, Igor Ryzhov,
Dan Gora
On Wed, Nov 24, 2021 at 10:48 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> Announce the KNI kernel module move to out of dpdk repo and announce
> long term plan to deprecate the KNI.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
> ---
> Cc: Olivier Matz Olivier Matz <olivier.matz@6wind.com>
> Cc: David Marchand David Marchand <david.marchand@redhat.com>
> Cc: Stephen Hemminger Stephen Hemminger <stephen@networkplumber.org>
> Cc: Elad Nachman <eladv6@gmail.com>
> Cc: Igor Ryzhov <iryzhov@nfware.com>
> Cc: Dan Gora <dg@adax.com>
>
> Dates are not discussed before, the patch aims to trigger a discussion
> for the dates.
> ---
> doc/guides/prog_guide/kernel_nic_interface.rst | 2 ++
> doc/guides/rel_notes/deprecation.rst | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
> index f5a8b7c0782c..d1c5ccd0851d 100644
> --- a/doc/guides/prog_guide/kernel_nic_interface.rst
> +++ b/doc/guides/prog_guide/kernel_nic_interface.rst
> @@ -7,6 +7,8 @@ Kernel NIC Interface
> ====================
>
> .. Note::
> + KNI kernel module will be moved from main git repository to `dpdk-kmods <https://git.dpdk.org/dpdk-kmods/>`_ repository.
> + There is a long term plan to deprecate the KNI. See :doc:`../rel_notes/deprecation`
>
> :ref:`virtio_user_as_exceptional_path` alternative is the preferred way for
> interfacing with the Linux network stack as it is an in-kernel solution and
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 2262b8de6093..f20852504319 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -48,6 +48,12 @@ Deprecation Notices
> in the header will not be considered as ABI anymore. This change is inspired
> by the RFC https://patchwork.dpdk.org/project/dpdk/list/?series=17176.
>
> +* kni: KNI kernel module will be moved to `dpdk-kmods <https://git.dpdk.org/dpdk-kmods/>`_
> + repository by the `DPDK technical board decision
> + <https://mails.dpdk.org/archives/dev/2021-January/197077.html>`_, on v22.11.
> +* kni: will be depreciated, will remove all kni lib, kernel module and example code
> + on v23.11.
> +
> * lib: will fix extending some enum/define breaking the ABI. There are multiple
> samples in DPDK that enum/define terminated with a ``.*MAX.*`` value which is
> used by iterators, and arrays holding these values are sized with this
> --
> 2.31.1
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use
@ 2022-07-11 14:07 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-07-11 14:07 UTC (permalink / raw)
To: Morten Brørup
Cc: Thomas Monjalon, Tyler Retzlaff, Stephen Hemminger, dpdk-dev,
Anatoly Burakov, Menon, Ranjit, Ray Kinsella, David Marchand,
Dmitry Kozlyuk, Richardson, Bruce
On Thu, Nov 11, 2021 at 6:11 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Thursday, 11 November 2021 12.55
> >
> > 11/11/2021 05:15, Tyler Retzlaff:
> > > On Tue, Oct 26, 2021 at 09:45:20AM +0200, Morten Brørup wrote:
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
> > Monjalon
> > > > > Sent: Monday, 25 October 2021 21.14
> > > > >
> > > > > 15/03/2021 20:34, Tyler Retzlaff:
> > > > > > The proposal has resulted from request to review [1] the
> > following
> > > > > > functions where there appeared to be inconsistency in return
> > type
> > > > > > or parameter type selections for the following inline
> > functions.
> > > > > >
> > > > > > rte_bsf32()
> > > > > > rte_bsf32_safe()
> > > > > > rte_bsf64()
> > > > > > rte_bsf64_safe()
> > > > > > rte_fls_u32()
> > > > > > rte_fls_u64()
> > > > > > rte_log2_u32()
> > > > > > rte_log2_u64()
> > > > > >
> > > > > > [1] http://mails.dpdk.org/archives/dev/2021-March/201590.html
> > > > > >
> > > > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
> > > > > > ---
> > > > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > > > +* eal: Fix inline function return and parameter types for
> > > > > rte_{bsf,fls}
> > > > > > + inline functions to be consistent.
> > > > > > + Change ``rte_bsf32_safe`` parameter ``v`` from ``uint64_t``
> > to
> > > > > ``uint32_t``.
> > > > > > + Change ``rte_bsf64`` return type to ``uint32_t`` instead of
> > > > > ``int``.
> > > > > > + Change ``rte_fls_u32`` return type to ``uint32_t`` instead
> > of
> > > > > ``int``.
> > > > > > + Change ``rte_fls_u64`` return type to ``uint32_t`` instead
> > of
> > > > > ``int``.
> > > > >
> > > > > It seems we completely forgot this.
> > > > > How critical is it?
> > > >
> > >
> > > our organization as a matter of internal security policy requires
> > these
> > > sorts of things to be fixed. while i didn't see any bugs in the dpdk
> > > code there is an opportunity for users of these functions to
> > > accidentally write code that is prone to integer and buffer overflow
> > > class bugs.
> > >
> > > there is no urgency, but why leave things sloppy? though i do wish
> > this
> > > had been responded to in a more timely manner 7 months for something
> > > that should have almost been rubber stamped.
> >
> > It's difficult to be on all topics.
> > The best way to avoid such miss is to ping when you see no progress.
> >
> > So what's next?
> > They are only inline functions, right? so no ABI breakage.
> > Is it going to require any change on application-side? I guess no.
> > Is it acceptable in 21.11-rc3? maybe too late?
> > Is it acceptable in 22.02?
>
> If Microsoft (represented by Tyler in this case) considers this a bug, I would prefer getting it into 21.11 - especially because it is an LTS release.
>
> -Morten
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking device and driver objects as internal
2022-07-11 2:16 0% ` Xia, Chenbo
@ 2022-07-11 12:36 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-07-11 12:36 UTC (permalink / raw)
To: David Marchand, Harris, James R, Walker, Benjamin, Xia, Chenbo
Cc: dev, techboard, Ray Kinsella, Liu, Changpeng
11/07/2022 04:16, Xia, Chenbo:
> From: David Marchand <david.marchand@redhat.com>
> > rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
> > Announce that they will be made opaque in the public API and mark
> > associated API as internal.
> > This impacts all bus, as their driver registration mechanism will be
> > made internal.
> >
> > Note: the PCI bus had a similar deprecation notice that we can remove as
> > the new one is more generic.
[...]
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > +* drivers: As a followup on the work on the ``rte_bus`` object, the
> > + ``rte_driver`` and ``rte_device`` objects (and as a domino effect,
> > their
> > + bus-specific counterparts) will be made opaque in DPDK 22.11.
> > + Registering a driver on a bus will be marked as an internal API:
> > + external users may still register their drivers using the bus specific
> > + driver header (see ``enable_driver_sdk`` meson option).
> > +
>
> Cc SPDK folks
>
> Thanks for your work! My only concern is using enable_driver_sdk may not be
> a good way for SPDK based on the discussion.
> http://patchwork.dpdk.org/project/dpdk/cover/20210918022443.12719-1-chenbo.xia@intel.com/
Quick summary:
- Symbols exported by DPDK by default are supposed to be for applications.
- Option enable_driver_sdk allow installing headers to build drivers.
- Driver interface is not part of the stable ABI, i.e. no compat guarantee.
- SPDK is building drivers on top of DPDK bus drivers (PCI for now).
- SPDK was asked to check whether anything else is required.
There is no decision about ABI guarantee because we lack feedbacks.
After this cleanup, the option enable_driver_sdk would be required
when working with buses, like SPDK.
Is there a real need to build against distro-provided package?
Is there a way to provide bus drivers SDK without messing with app SDK?
> But overall this idea makes sense, so:
>
> Acked-by: Chenbo Xia <chenbo.xia@intel.com>
I like the cleanup as well. It will allow more enhancements in future.
I hope and believe we can accomodate SDK needs when it will be clear.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
@ 2022-07-11 12:11 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-07-11 12:11 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin
Cc: dev, Liu, Changpeng, Xia, Chenbo, David Marchand, Aaron Conole,
Zawadzki, Tomasz
9 months have passed. Do you have any news from SPDK side?
14/10/2021 08:41, Thomas Monjalon:
> 14/10/2021 00:48, Walker, Benjamin:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> >
> > > Yes I think we need to agree on functions to keep as-is for compatibility.
> > > Waiting for your input please.
> >
> > We've added a task to our backlog to propose a stable ABI for out of tree drivers here. It's not as simple as just keeping a couple of the existing functions - we're currently manipulating structures directly. We'll need to work a bit to design the simplest possible set of functions that we need.
>
> OK thanks
^ permalink raw reply [relevance 0%]
* Re: [RFC v2 v2 00/29] Bus and device cleanup for 22.11
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
` (3 preceding siblings ...)
2022-07-09 16:30 0% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 Stephen Hemminger
@ 2022-07-11 8:38 0% ` Bruce Richardson
4 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-07-11 8:38 UTC (permalink / raw)
To: David Marchand; +Cc: dev
On Sat, Jul 09, 2022 at 10:26:15AM +0200, David Marchand wrote:
> This is a PoC for hiding the rte_bus, rte_driver and rte_device objects.
> And mark associated driver only API as internal.
>
> A good amount of the patches are preparation work on rte_bus.h,
> rte_dev.h, rte_devargs.h and rte_eal.h headers, removing dependencies
> between them. This is something I had in store for some time, maybe I
> should have dropped it from the PoC, but I think those cleanups are
> worth it in any case.
>
> Then PCI bus specific handling are moved from unit tests and examples,
> though there is still a special case left in testpmd that may require a
> new API, to be discussed.
>
> After this series, driver-only API headers for registering to buses are
> not exported anymore, unless the enable_driver_sdk meson option is
> selected.
>
> New accessors for rte_bus, rte_driver and rte_device have been added,
> marked with an experimental tag though we may declare them as stable
> right away so that users can switch to them directly. That's also
> something to agree on.
>
Yes, I think we need to make them stable.
> I simplified my series and switched to only update "external" users,
> like app/ and examples/ files.
> We need some checkpatch new checks to be sure we won't get some
> driver-only headers included in these areas. That's something I'll work
> on in the non RFC series.
>
> "Internal" users are simply using the internal headers. That helps
> greatly reducing the size of the changes.
>
> Disclaimer: again, in this v2, this series is a bit rushed (I brute forced
> compilation tests in GHA so that it passes between patches, but there still
> may be something broken...).
> Not surprisingly, the ABI check in the CI is expected to fail.
>
>
> Comments welcome.
>
This is great cleanup. Thanks for all the work on it.
/Bruce
^ permalink raw reply [relevance 0%]
* RE: [PATCH] doc: announce marking device and driver objects as internal
2022-07-10 6:17 13% [PATCH] doc: announce marking device and driver objects as internal David Marchand
2022-07-10 8:25 0% ` Andrew Rybchenko
@ 2022-07-11 2:16 0% ` Xia, Chenbo
2022-07-11 12:36 4% ` Thomas Monjalon
2022-07-11 15:01 0% ` Jerin Jacob
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Xia, Chenbo @ 2022-07-11 2:16 UTC (permalink / raw)
To: David Marchand, dev, techboard
Cc: Ray Kinsella, Liu, Changpeng, Harris, James R, Walker, Benjamin,
Thomas Monjalon
Hi David,
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Sunday, July 10, 2022 2:18 PM
> To: dev@dpdk.org; techboard@dpdk.org
> Cc: Ray Kinsella <mdr@ashroe.eu>
> Subject: [PATCH] doc: announce marking device and driver objects as
> internal
>
> rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
> Announce that they will be made opaque in the public API and mark
> associated API as internal.
> This impacts all bus, as their driver registration mechanism will be
> made internal.
>
> Note: the PCI bus had a similar deprecation notice that we can remove as
> the new one is more generic.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index a9fd6676be..b9cc267b30 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -38,6 +38,13 @@ Deprecation Notices
> external users may still register their bus using a new driver header
> (see
> ``enable_driver_sdk`` meson option).
>
> +* drivers: As a followup on the work on the ``rte_bus`` object, the
> + ``rte_driver`` and ``rte_device`` objects (and as a domino effect,
> their
> + bus-specific counterparts) will be made opaque in DPDK 22.11.
> + Registering a driver on a bus will be marked as an internal API:
> + external users may still register their drivers using the bus specific
> + driver header (see ``enable_driver_sdk`` meson option).
> +
Cc SPDK folks
Thanks for your work! My only concern is using enable_driver_sdk may not be
a good way for SPDK based on the discussion.
http://patchwork.dpdk.org/project/dpdk/cover/20210918022443.12719-1-chenbo.xia@intel.com/
But overall this idea makes sense, so:
Acked-by: Chenbo Xia <chenbo.xia@intel.com>
> * mempool: Helper macro ``MEMPOOL_HEADER_SIZE()`` is deprecated and will
> be removed in DPDK 22.11. The replacement macro
> ``RTE_MEMPOOL_HEADER_SIZE()`` is internal only.
> @@ -49,11 +56,6 @@ Deprecation Notices
> * mempool: The mempool API macros ``MEMPOOL_PG_*`` are deprecated and
> will be removed in DPDK 22.11.
>
> -* pci: To reduce unnecessary ABIs exposed by DPDK bus driver,
> "rte_bus_pci.h"
> - will be made internal in 21.11 and macros/data structures/functions
> defined
> - in the header will not be considered as ABI anymore. This change is
> inspired
> - by the RFC https://patchwork.dpdk.org/project/dpdk/list/?series=17176.
> -
> * lib: will fix extending some enum/define breaking the ABI. There are
> multiple
> samples in DPDK that enum/define terminated with a ``.*MAX.*`` value
> which is
> used by iterators, and arrays holding these values are sized with this
> --
> 2.36.1
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking device and driver objects as internal
2022-07-10 6:17 13% [PATCH] doc: announce marking device and driver objects as internal David Marchand
@ 2022-07-10 8:25 0% ` Andrew Rybchenko
2022-07-11 2:16 0% ` Xia, Chenbo
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2022-07-10 8:25 UTC (permalink / raw)
To: David Marchand, dev, techboard; +Cc: Ray Kinsella
On 7/10/22 09:17, David Marchand wrote:
> rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
> Announce that they will be made opaque in the public API and mark
> associated API as internal.
> This impacts all bus, as their driver registration mechanism will be
> made internal.
>
> Note: the PCI bus had a similar deprecation notice that we can remove as
> the new one is more generic.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply [relevance 0%]
* [PATCH] doc: announce marking device and driver objects as internal
@ 2022-07-10 6:17 13% David Marchand
2022-07-10 8:25 0% ` Andrew Rybchenko
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: David Marchand @ 2022-07-10 6:17 UTC (permalink / raw)
To: dev, techboard; +Cc: Ray Kinsella
rte_driver and rte_device are unnecessarily exposed in the public API/ABI.
Announce that they will be made opaque in the public API and mark
associated API as internal.
This impacts all bus, as their driver registration mechanism will be
made internal.
Note: the PCI bus had a similar deprecation notice that we can remove as
the new one is more generic.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/deprecation.rst | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a9fd6676be..b9cc267b30 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -38,6 +38,13 @@ Deprecation Notices
external users may still register their bus using a new driver header (see
``enable_driver_sdk`` meson option).
+* drivers: As a followup on the work on the ``rte_bus`` object, the
+ ``rte_driver`` and ``rte_device`` objects (and as a domino effect, their
+ bus-specific counterparts) will be made opaque in DPDK 22.11.
+ Registering a driver on a bus will be marked as an internal API:
+ external users may still register their drivers using the bus specific
+ driver header (see ``enable_driver_sdk`` meson option).
+
* mempool: Helper macro ``MEMPOOL_HEADER_SIZE()`` is deprecated and will
be removed in DPDK 22.11. The replacement macro
``RTE_MEMPOOL_HEADER_SIZE()`` is internal only.
@@ -49,11 +56,6 @@ Deprecation Notices
* mempool: The mempool API macros ``MEMPOOL_PG_*`` are deprecated and
will be removed in DPDK 22.11.
-* pci: To reduce unnecessary ABIs exposed by DPDK bus driver, "rte_bus_pci.h"
- will be made internal in 21.11 and macros/data structures/functions defined
- in the header will not be considered as ABI anymore. This change is inspired
- by the RFC https://patchwork.dpdk.org/project/dpdk/list/?series=17176.
-
* lib: will fix extending some enum/define breaking the ABI. There are multiple
samples in DPDK that enum/define terminated with a ``.*MAX.*`` value which is
used by iterators, and arrays holding these values are sized with this
--
2.36.1
^ permalink raw reply [relevance 13%]
* Re: [RFC v2 v2 00/29] Bus and device cleanup for 22.11
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
` (2 preceding siblings ...)
2022-07-09 8:26 3% ` [RFC v2 v2 29/29] dev: hide device object David Marchand
@ 2022-07-09 16:30 0% ` Stephen Hemminger
2022-07-11 8:38 0% ` Bruce Richardson
4 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-07-09 16:30 UTC (permalink / raw)
To: David Marchand; +Cc: dev
On Sat, 9 Jul 2022 10:26:15 +0200
David Marchand <david.marchand@redhat.com> wrote:
> This is a PoC for hiding the rte_bus, rte_driver and rte_device objects.
> And mark associated driver only API as internal.
>
> A good amount of the patches are preparation work on rte_bus.h,
> rte_dev.h, rte_devargs.h and rte_eal.h headers, removing dependencies
> between them. This is something I had in store for some time, maybe I
> should have dropped it from the PoC, but I think those cleanups are
> worth it in any case.
>
> Then PCI bus specific handling are moved from unit tests and examples,
> though there is still a special case left in testpmd that may require a
> new API, to be discussed.
>
> After this series, driver-only API headers for registering to buses are
> not exported anymore, unless the enable_driver_sdk meson option is
> selected.
>
> New accessors for rte_bus, rte_driver and rte_device have been added,
> marked with an experimental tag though we may declare them as stable
> right away so that users can switch to them directly. That's also
> something to agree on.
>
> I simplified my series and switched to only update "external" users,
> like app/ and examples/ files.
> We need some checkpatch new checks to be sure we won't get some
> driver-only headers included in these areas. That's something I'll work
> on in the non RFC series.
>
> "Internal" users are simply using the internal headers. That helps
> greatly reducing the size of the changes.
>
> Disclaimer: again, in this v2, this series is a bit rushed (I brute forced
> compilation tests in GHA so that it passes between patches, but there still
> may be something broken...).
> Not surprisingly, the ABI check in the CI is expected to fail.
>
>
> Comments welcome.
Looks good to me, lots of work but will the separation internal
and external API's will help in future.
^ permalink raw reply [relevance 0%]
* [RFC v2 v2 29/29] dev: hide device object
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 13/29] bus: hide bus object David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 27/29] dev: hide driver object David Marchand
@ 2022-07-09 8:26 3% ` David Marchand
2022-07-09 16:30 0% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 Stephen Hemminger
2022-07-11 8:38 0% ` Bruce Richardson
4 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-07-09 8:26 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Chenbo Xia
Make rte_device opaque for non internal users.
This will make extending this object possible without breaking the ABI.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
lib/eal/common/eal_private.h | 2 +-
lib/eal/include/dev_driver.h | 14 ++++++++++++++
lib/eal/include/rte_dev.h | 13 +------------
lib/vhost/vdpa.c | 1 +
4 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h
index 44d14241f0..3ca9ce2ffc 100644
--- a/lib/eal/common/eal_private.h
+++ b/lib/eal/common/eal_private.h
@@ -10,7 +10,7 @@
#include <stdio.h>
#include <sys/queue.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_lcore.h>
#include <rte_memory.h>
diff --git a/lib/eal/include/dev_driver.h b/lib/eal/include/dev_driver.h
index 015188abd5..01c3e30994 100644
--- a/lib/eal/include/dev_driver.h
+++ b/lib/eal/include/dev_driver.h
@@ -12,6 +12,8 @@ extern "C" {
#include <rte_common.h>
#include <rte_dev.h>
+struct rte_devargs;
+
/**
* A structure describing a device driver.
*/
@@ -21,6 +23,18 @@ struct rte_driver {
const char *alias; /**< Driver alias. */
};
+/**
+ * A structure describing a generic device.
+ */
+struct rte_device {
+ RTE_TAILQ_ENTRY(rte_device) next; /**< Next device */
+ const char *name; /**< Device name */
+ const struct rte_driver *driver; /**< Driver assigned after probing */
+ const struct rte_bus *bus; /**< Bus handle assigned on scan */
+ int numa_node; /**< NUMA node connection */
+ struct rte_devargs *devargs; /**< Arguments for latest probing */
+};
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/eal/include/rte_dev.h b/lib/eal/include/rte_dev.h
index a80447a645..3077cf3f0f 100644
--- a/lib/eal/include/rte_dev.h
+++ b/lib/eal/include/rte_dev.h
@@ -25,6 +25,7 @@ extern "C" {
struct rte_bus;
struct rte_driver;
+struct rte_device;
/**
* The device event type.
@@ -127,18 +128,6 @@ __rte_experimental
int
rte_dev_numa_node(const struct rte_device *dev);
-/**
- * A structure describing a generic device.
- */
-struct rte_device {
- RTE_TAILQ_ENTRY(rte_device) next; /**< Next device */
- const char *name; /**< Device name */
- const struct rte_driver *driver; /**< Driver assigned after probing */
- const struct rte_bus *bus; /**< Bus handle assigned on scan */
- int numa_node; /**< NUMA node connection */
- struct rte_devargs *devargs; /**< Arguments for latest probing */
-};
-
/**
* Query status of a device.
*
diff --git a/lib/vhost/vdpa.c b/lib/vhost/vdpa.c
index bdebcbe565..aaf3f267e9 100644
--- a/lib/vhost/vdpa.c
+++ b/lib/vhost/vdpa.c
@@ -10,6 +10,7 @@
#include <sys/queue.h>
+#include <dev_driver.h>
#include <rte_common.h>
#include <rte_class.h>
#include <rte_malloc.h>
--
2.36.1
^ permalink raw reply [relevance 3%]
* [RFC v2 v2 27/29] dev: hide driver object
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 13/29] bus: hide bus object David Marchand
@ 2022-07-09 8:26 1% ` David Marchand
2022-07-09 8:26 3% ` [RFC v2 v2 29/29] dev: hide device object David Marchand
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-07-09 8:26 UTC (permalink / raw)
To: dev
Cc: Nicolas Chautru, Parav Pandit, Xueming Li, Hemant Agrawal,
Sachin Saxena, Rosen Xu, Stephen Hemminger, Long Li, Fan Zhang,
Sunila Sahu, Ashish Gupta, Ajit Khaparde, Raveendra Padasalagi,
Vikas Gupta, Chandubabu Namburu, Ankur Dwivedi, Anoob Joseph,
Tejasree Kondoj, Gagandeep Singh, Bruce Richardson, Kevin Laatz,
Timothy McDaniel, Jerin Jacob, Elena Agostini, Ciara Loftus,
Qi Zhang, Shepard Siegel, Ed Czeck, John Miller, Steven Webster,
Matt Peters, Rasesh Mody, Shahed Shaikh, Somnath Kotur,
Rahul Lakkireddy, Simei Su, Wenjun Wu, Marcin Wojtas,
Michal Krawczyk, Shai Brandes, Evgeny Schemeilin, Igor Chauskin,
John Daley, Hyong Youb Kim, Gaetan Rivet, Xiao Wang,
Yuying Zhang, Beilei Xing, Jingjing Wu, Qiming Yang, Matan Azrad,
Viacheslav Ovsiienko, Chaoyong He, Niklas Soderlund,
Harman Kalra, Devendra Singh Rawat, Andrew Rybchenko,
Maciej Czekaj, Maxime Coquelin, Chenbo Xia, Jochen Behrens,
Jakub Palider, Tomasz Duszynski, Ori Kam, Akhil Goyal,
Chengwen Feng, Thomas Monjalon, Ferruh Yigit, Abhinandan Gujjar,
Jay Jayatheerthan, Olivier Matz, Reshma Pattan
Make rte_driver opaque for non internal users.
This will make extending this object possible without breaking the ABI.
Introduce a new driver header and move rte_driver definition.
Update drivers and library to use the internal header.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
drivers/baseband/acc100/rte_acc100_pmd.c | 2 +-
.../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 2 +-
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 2 +-
drivers/bus/auxiliary/auxiliary_params.c | 2 +-
drivers/bus/auxiliary/bus_auxiliary_driver.h | 2 +-
drivers/bus/dpaa/bus_dpaa_driver.h | 2 ++
drivers/bus/fslmc/bus_fslmc_driver.h | 2 +-
drivers/bus/fslmc/fslmc_vfio.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpci.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dprc.c | 2 +-
drivers/bus/ifpga/bus_ifpga_driver.h | 1 +
drivers/bus/pci/bus_pci_driver.h | 2 +-
drivers/bus/pci/pci_params.c | 2 +-
drivers/bus/vdev/bus_vdev_driver.h | 2 +-
drivers/bus/vdev/vdev.c | 2 +-
drivers/bus/vdev/vdev_params.c | 2 +-
drivers/bus/vmbus/bus_vmbus_driver.h | 2 +-
drivers/common/qat/dev/qat_dev_gen4.c | 2 +-
drivers/common/qat/qat_qp.c | 2 +-
drivers/compress/zlib/zlib_pmd_ops.c | 2 +-
drivers/crypto/bcmfs/bcmfs_qp.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_pmd.c | 2 +-
drivers/crypto/ccp/rte_ccp_pmd.c | 2 +-
drivers/crypto/cnxk/cn10k_cryptodev.c | 2 +-
drivers/crypto/cnxk/cn9k_cryptodev.c | 2 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 2 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 2 +-
drivers/dma/idxd/idxd_bus.c | 1 +
drivers/event/dlb2/dlb2.c | 2 +-
drivers/event/dlb2/pf/dlb2_pf.c | 2 +-
drivers/event/dpaa/dpaa_eventdev.c | 2 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 2 +-
drivers/event/dpaa2/dpaa2_hw_dpcon.c | 2 +-
drivers/event/octeontx/ssovf_evdev.c | 2 +-
drivers/event/skeleton/skeleton_eventdev.c | 2 +-
drivers/gpu/cuda/cuda.c | 2 +-
drivers/mempool/dpaa2/dpaa2_hw_mempool.c | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 2 +-
drivers/net/ark/ark_global.h | 2 +-
drivers/net/avp/avp_ethdev.c | 2 +-
drivers/net/axgbe/axgbe_common.h | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 2 +-
drivers/net/bnxt/bnxt_ethdev.c | 2 +-
drivers/net/bnxt/rte_pmd_bnxt.c | 2 +-
drivers/net/cxgbe/base/t4_hw.c | 2 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 2 +-
drivers/net/cxgbe/cxgbe_main.c | 2 +-
drivers/net/cxgbe/sge.c | 2 +-
drivers/net/dpaa2/base/dpaa2_hw_dpni.c | 2 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 2 +-
drivers/net/dpaa2/dpaa2_recycle.c | 2 +-
drivers/net/dpaa2/dpaa2_rxtx.c | 2 +-
drivers/net/dpaa2/dpaa2_sparser.c | 2 +-
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 2 +-
drivers/net/e1000/igb_flow.c | 2 +-
drivers/net/ena/ena_ethdev.h | 2 +-
drivers/net/enic/enic_ethdev.c | 2 +-
drivers/net/enic/enic_vf_representor.c | 2 +-
drivers/net/failsafe/failsafe_private.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev.c | 2 +-
drivers/net/iavf/iavf_ethdev.c | 2 +-
drivers/net/iavf/iavf_vchnl.c | 2 +-
drivers/net/ice/ice_dcf.c | 2 +-
drivers/net/ice/ice_dcf_ethdev.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 2 +-
drivers/net/ixgbe/ixgbe_flow.c | 2 +-
drivers/net/mlx4/mlx4.c | 2 +-
drivers/net/netvsc/hn_ethdev.c | 2 +-
drivers/net/netvsc/hn_nvs.c | 2 +-
drivers/net/netvsc/hn_rndis.c | 2 +-
drivers/net/netvsc/hn_rxtx.c | 2 +-
drivers/net/nfp/nfp_common.c | 2 +-
drivers/net/nfp/nfp_ethdev.c | 2 +-
drivers/net/octeontx/octeontx_ethdev.c | 2 +-
drivers/net/qede/qede_ethdev.h | 2 +-
drivers/net/sfc/sfc_ethdev.c | 2 +-
drivers/net/sfc/sfc_sw_stats.c | 2 +-
drivers/net/sfc/sfc_sw_stats.h | 2 +-
drivers/net/thunderx/nicvf_ethdev.c | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/virtio/virtio_pci_ethdev.c | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
drivers/raw/cnxk_bphy/cnxk_bphy.c | 2 +-
drivers/raw/skeleton/skeleton_rawdev.c | 2 +-
drivers/raw/skeleton/skeleton_rawdev_test.c | 2 +-
drivers/regex/mlx5/mlx5_regex_control.c | 2 +-
lib/compressdev/rte_compressdev.c | 2 +-
lib/compressdev/rte_compressdev_pmd.c | 2 +-
lib/compressdev/rte_compressdev_pmd.h | 1 +
lib/cryptodev/cryptodev_pmd.c | 2 +-
lib/cryptodev/cryptodev_pmd.h | 1 +
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/dmadev/rte_dmadev_pmd.h | 2 +-
lib/eal/common/eal_common_dev.c | 2 +-
lib/eal/include/dev_driver.h | 28 +++++++++++++++++++
lib/eal/include/meson.build | 1 +
lib/eal/include/rte_dev.h | 11 ++------
lib/ethdev/ethdev_driver.h | 1 +
lib/eventdev/eventdev_pmd.h | 2 +-
lib/eventdev/rte_event_crypto_adapter.c | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
lib/eventdev/rte_eventdev.c | 2 +-
lib/gpudev/gpudev_driver.h | 2 +-
lib/mempool/rte_mempool_ops.c | 2 +-
lib/pcapng/rte_pcapng.c | 2 +-
lib/rawdev/rte_rawdev.c | 2 +-
lib/rawdev/rte_rawdev_pmd.h | 2 +-
lib/security/rte_security.c | 2 +-
114 files changed, 143 insertions(+), 114 deletions(-)
create mode 100644 lib/eal/include/dev_driver.h
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c b/drivers/baseband/acc100/rte_acc100_pmd.c
index 801e8920df..e2d9409185 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -6,7 +6,7 @@
#include <rte_common.h>
#include <rte_log.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_mempool.h>
#include <rte_byteorder.h>
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index c1d877c87f..51dd090c1b 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -6,7 +6,7 @@
#include <rte_common.h>
#include <rte_log.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_mempool.h>
#include <rte_errno.h>
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index f16814e241..036579e3ec 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -6,7 +6,7 @@
#include <rte_common.h>
#include <rte_log.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_mempool.h>
#include <rte_errno.h>
diff --git a/drivers/bus/auxiliary/auxiliary_params.c b/drivers/bus/auxiliary/auxiliary_params.c
index a889e392c6..e4c7ee0c3b 100644
--- a/drivers/bus/auxiliary/auxiliary_params.c
+++ b/drivers/bus/auxiliary/auxiliary_params.c
@@ -5,7 +5,7 @@
#include <string.h>
#include <bus_driver.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_kvargs.h>
diff --git a/drivers/bus/auxiliary/bus_auxiliary_driver.h b/drivers/bus/auxiliary/bus_auxiliary_driver.h
index 44bacc3c0e..13c18418bd 100644
--- a/drivers/bus/auxiliary/bus_auxiliary_driver.h
+++ b/drivers/bus/auxiliary/bus_auxiliary_driver.h
@@ -22,10 +22,10 @@ extern "C" {
#include <stdint.h>
#include <inttypes.h>
+#include <dev_driver.h>
#include <rte_compat.h>
#include <rte_debug.h>
#include <rte_interrupts.h>
-#include <rte_dev.h>
#include <rte_kvargs.h>
#define RTE_BUS_AUXILIARY_NAME "auxiliary"
diff --git a/drivers/bus/dpaa/bus_dpaa_driver.h b/drivers/bus/dpaa/bus_dpaa_driver.h
index 4360295335..937a742525 100644
--- a/drivers/bus/dpaa/bus_dpaa_driver.h
+++ b/drivers/bus/dpaa/bus_dpaa_driver.h
@@ -6,9 +6,11 @@
#ifndef BUS_DPAA_DRIVER_H
#define BUS_DPAA_DRIVER_H
+#include <dev_driver.h>
#include <rte_compat.h>
#include <rte_mbuf_dyn.h>
#include <rte_mempool.h>
+
#include <dpaax_iova_table.h>
#include <dpaa_of.h>
diff --git a/drivers/bus/fslmc/bus_fslmc_driver.h b/drivers/bus/fslmc/bus_fslmc_driver.h
index 798ddebf3a..ac3d98dcc0 100644
--- a/drivers/bus/fslmc/bus_fslmc_driver.h
+++ b/drivers/bus/fslmc/bus_fslmc_driver.h
@@ -26,10 +26,10 @@ extern "C" {
#include <inttypes.h>
#include <linux/vfio.h>
+#include <dev_driver.h>
#include <rte_compat.h>
#include <rte_debug.h>
#include <rte_interrupts.h>
-#include <rte_dev.h>
#include <rte_tailq.h>
#include <rte_devargs.h>
#include <rte_mbuf.h>
diff --git a/drivers/bus/fslmc/fslmc_vfio.c b/drivers/bus/fslmc/fslmc_vfio.c
index 8604e43947..5966776a85 100644
--- a/drivers/bus/fslmc/fslmc_vfio.c
+++ b/drivers/bus/fslmc/fslmc_vfio.c
@@ -28,7 +28,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal_memconfig.h>
#include "private.h"
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
index cfe4280f87..d7f6e45b7d 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
@@ -18,7 +18,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <rte_mbuf_pool_ops.h>
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpci.c b/drivers/bus/fslmc/portal/dpaa2_hw_dpci.c
index b7d81b518c..07256ed7ec 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpci.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpci.c
@@ -17,7 +17,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <fslmc_logs.h>
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
index 071b0d297d..4aec7b2cd8 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
@@ -30,7 +30,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <fslmc_logs.h>
#include <bus_fslmc_driver.h>
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dprc.c b/drivers/bus/fslmc/portal/dpaa2_hw_dprc.c
index 223e34bcba..65e2d799c3 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dprc.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dprc.c
@@ -10,7 +10,7 @@
#include <errno.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "private.h"
#include <fslmc_logs.h>
diff --git a/drivers/bus/ifpga/bus_ifpga_driver.h b/drivers/bus/ifpga/bus_ifpga_driver.h
index 7b75c2ddbc..10bf2f92ce 100644
--- a/drivers/bus/ifpga/bus_ifpga_driver.h
+++ b/drivers/bus/ifpga/bus_ifpga_driver.h
@@ -15,6 +15,7 @@
extern "C" {
#endif /* __cplusplus */
+#include <dev_driver.h>
#include <rte_compat.h>
#include <rte_pci.h>
#include <rte_interrupts.h>
diff --git a/drivers/bus/pci/bus_pci_driver.h b/drivers/bus/pci/bus_pci_driver.h
index b5c7dee617..9c56307405 100644
--- a/drivers/bus/pci/bus_pci_driver.h
+++ b/drivers/bus/pci/bus_pci_driver.h
@@ -10,8 +10,8 @@
extern "C" {
#endif
+#include <dev_driver.h>
#include <rte_bus_pci.h>
-#include <rte_dev.h>
#include <rte_compat.h>
/** Pathname of PCI devices directory. */
diff --git a/drivers/bus/pci/pci_params.c b/drivers/bus/pci/pci_params.c
index 39d702a418..d24cc201b8 100644
--- a/drivers/bus/pci/pci_params.c
+++ b/drivers/bus/pci/pci_params.c
@@ -6,7 +6,7 @@
#include <bus_driver.h>
#include <rte_bus_pci.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_kvargs.h>
#include <rte_devargs.h>
diff --git a/drivers/bus/vdev/bus_vdev_driver.h b/drivers/bus/vdev/bus_vdev_driver.h
index 36748cdfae..d05a7f7115 100644
--- a/drivers/bus/vdev/bus_vdev_driver.h
+++ b/drivers/bus/vdev/bus_vdev_driver.h
@@ -9,9 +9,9 @@
extern "C" {
#endif
+#include <dev_driver.h>
#include <rte_bus_vdev.h>
#include <rte_compat.h>
-#include <rte_dev.h>
#include <rte_devargs.h>
struct rte_vdev_device {
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index 1b8410fe5b..7c8170e5a6 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -13,7 +13,7 @@
#include <bus_driver.h>
#include <bus_vdev_driver.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_common.h>
#include <rte_devargs.h>
#include <rte_memory.h>
diff --git a/drivers/bus/vdev/vdev_params.c b/drivers/bus/vdev/vdev_params.c
index 2c72614776..2d10a1e8ad 100644
--- a/drivers/bus/vdev/vdev_params.c
+++ b/drivers/bus/vdev/vdev_params.c
@@ -4,7 +4,7 @@
#include <string.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_kvargs.h>
#include <rte_errno.h>
diff --git a/drivers/bus/vmbus/bus_vmbus_driver.h b/drivers/bus/vmbus/bus_vmbus_driver.h
index 3424e791c9..e60290c835 100644
--- a/drivers/bus/vmbus/bus_vmbus_driver.h
+++ b/drivers/bus/vmbus/bus_vmbus_driver.h
@@ -10,9 +10,9 @@
extern "C" {
#endif
+#include <dev_driver.h>
#include <rte_bus_vmbus.h>
#include <rte_compat.h>
-#include <rte_dev.h>
struct vmbus_channel;
struct vmbus_mon_page;
diff --git a/drivers/common/qat/dev/qat_dev_gen4.c b/drivers/common/qat/dev/qat_dev_gen4.c
index 7ffde5f4c8..85d6ddfcf4 100644
--- a/drivers/common/qat/dev/qat_dev_gen4.c
+++ b/drivers/common/qat/dev/qat_dev_gen4.c
@@ -2,7 +2,7 @@
* Copyright(c) 2021 Intel Corporation
*/
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_pci.h>
#include "qat_device.h"
diff --git a/drivers/common/qat/qat_qp.c b/drivers/common/qat/qat_qp.c
index 4a1be35b47..e58e4ceec0 100644
--- a/drivers/common/qat/qat_qp.c
+++ b/drivers/common/qat/qat_qp.c
@@ -4,7 +4,7 @@
#include <rte_common.h>
#include <rte_cycles.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
#include <rte_pci.h>
diff --git a/drivers/compress/zlib/zlib_pmd_ops.c b/drivers/compress/zlib/zlib_pmd_ops.c
index 7d657d81bc..445a3baa67 100644
--- a/drivers/compress/zlib/zlib_pmd_ops.c
+++ b/drivers/compress/zlib/zlib_pmd_ops.c
@@ -4,7 +4,7 @@
#include <string.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_common.h>
#include <rte_malloc.h>
diff --git a/drivers/crypto/bcmfs/bcmfs_qp.c b/drivers/crypto/bcmfs/bcmfs_qp.c
index 61d457f4e0..d1ede5e990 100644
--- a/drivers/crypto/bcmfs/bcmfs_qp.c
+++ b/drivers/crypto/bcmfs/bcmfs_qp.c
@@ -8,7 +8,7 @@
#include <rte_atomic.h>
#include <rte_bitmap.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
#include <rte_prefetch.h>
diff --git a/drivers/crypto/bcmfs/bcmfs_sym_pmd.c b/drivers/crypto/bcmfs/bcmfs_sym_pmd.c
index bc7fb67218..78272d616c 100644
--- a/drivers/crypto/bcmfs/bcmfs_sym_pmd.c
+++ b/drivers/crypto/bcmfs/bcmfs_sym_pmd.c
@@ -4,7 +4,7 @@
*/
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_malloc.h>
#include <cryptodev_pmd.h>
diff --git a/drivers/crypto/ccp/rte_ccp_pmd.c b/drivers/crypto/ccp/rte_ccp_pmd.c
index 6c3e45e333..013f3be1e6 100644
--- a/drivers/crypto/ccp/rte_ccp_pmd.c
+++ b/drivers/crypto/ccp/rte_ccp_pmd.c
@@ -9,7 +9,7 @@
#include <rte_cryptodev.h>
#include <cryptodev_pmd.h>
#include <rte_pci.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include "ccp_crypto.h"
diff --git a/drivers/crypto/cnxk/cn10k_cryptodev.c b/drivers/crypto/cnxk/cn10k_cryptodev.c
index 3fd9f3c426..db11ac7444 100644
--- a/drivers/crypto/cnxk/cn10k_cryptodev.c
+++ b/drivers/crypto/cnxk/cn10k_cryptodev.c
@@ -7,7 +7,7 @@
#include <rte_crypto.h>
#include <rte_cryptodev.h>
#include <cryptodev_pmd.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_pci.h>
#include "cn10k_cryptodev.h"
diff --git a/drivers/crypto/cnxk/cn9k_cryptodev.c b/drivers/crypto/cnxk/cn9k_cryptodev.c
index bd425f95ff..4cfc1f2150 100644
--- a/drivers/crypto/cnxk/cn9k_cryptodev.c
+++ b/drivers/crypto/cnxk/cn9k_cryptodev.c
@@ -7,7 +7,7 @@
#include <rte_crypto.h>
#include <rte_cryptodev.h>
#include <cryptodev_pmd.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_pci.h>
#include "cn9k_cryptodev.h"
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index 0cce861899..3b13578de0 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -17,7 +17,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <cryptodev_pmd.h>
#include <rte_common.h>
#include <bus_fslmc_driver.h>
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c b/drivers/crypto/dpaa_sec/dpaa_sec.c
index 7e554cb2b1..c6bd785262 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -19,7 +19,7 @@
#include <rte_security_driver.h>
#endif
#include <rte_cycles.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_io.h>
#include <rte_ip.h>
#include <rte_kvargs.h>
diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c b/drivers/crypto/scheduler/scheduler_pmd_ops.c
index f3a1bd626c..971f82897c 100644
--- a/drivers/crypto/scheduler/scheduler_pmd_ops.c
+++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c
@@ -5,7 +5,7 @@
#include <rte_common.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_cryptodev.h>
#include <cryptodev_pmd.h>
#include <rte_reorder.h>
diff --git a/drivers/dma/idxd/idxd_bus.c b/drivers/dma/idxd/idxd_bus.c
index e30dcfc281..9b7b16c6e3 100644
--- a/drivers/dma/idxd/idxd_bus.c
+++ b/drivers/dma/idxd/idxd_bus.c
@@ -9,6 +9,7 @@
#include <libgen.h>
#include <bus_driver.h>
+#include <dev_driver.h>
#include <rte_devargs.h>
#include <rte_eal.h>
#include <rte_log.h>
diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index 26af75beb8..d7ac58bfde 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -17,7 +17,7 @@
#include <rte_config.h>
#include <rte_cycles.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_eventdev.h>
#include <eventdev_pmd.h>
diff --git a/drivers/event/dlb2/pf/dlb2_pf.c b/drivers/event/dlb2/pf/dlb2_pf.c
index 9f8c6cd8b8..71ac141b66 100644
--- a/drivers/event/dlb2/pf/dlb2_pf.c
+++ b/drivers/event/dlb2/pf/dlb2_pf.c
@@ -15,7 +15,7 @@
#include <rte_debug.h>
#include <rte_log.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_devargs.h>
#include <rte_mbuf.h>
#include <rte_ring.h>
diff --git a/drivers/event/dpaa/dpaa_eventdev.c b/drivers/event/dpaa/dpaa_eventdev.c
index aa403f9e06..8e470584ea 100644
--- a/drivers/event/dpaa/dpaa_eventdev.c
+++ b/drivers/event/dpaa/dpaa_eventdev.c
@@ -14,7 +14,7 @@
#include <rte_byteorder.h>
#include <rte_common.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_lcore.h>
#include <rte_log.h>
diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c b/drivers/event/dpaa2/dpaa2_eventdev.c
index 08df6e223a..1001297cda 100644
--- a/drivers/event/dpaa2/dpaa2_eventdev.c
+++ b/drivers/event/dpaa2/dpaa2_eventdev.c
@@ -14,7 +14,7 @@
#include <rte_byteorder.h>
#include <rte_common.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <bus_fslmc_driver.h>
#include <rte_lcore.h>
diff --git a/drivers/event/dpaa2/dpaa2_hw_dpcon.c b/drivers/event/dpaa2/dpaa2_hw_dpcon.c
index 3882a9cf1d..a68d3ac154 100644
--- a/drivers/event/dpaa2/dpaa2_hw_dpcon.c
+++ b/drivers/event/dpaa2/dpaa2_hw_dpcon.c
@@ -17,7 +17,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <bus_fslmc_driver.h>
diff --git a/drivers/event/octeontx/ssovf_evdev.c b/drivers/event/octeontx/ssovf_evdev.c
index fe157c59d5..99fa326ad5 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -7,7 +7,7 @@
#include <rte_common.h>
#include <cryptodev_pmd.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <ethdev_driver.h>
#include <rte_event_eth_rx_adapter.h>
diff --git a/drivers/event/skeleton/skeleton_eventdev.c b/drivers/event/skeleton/skeleton_eventdev.c
index 6bd8fec6d4..8513b9a013 100644
--- a/drivers/event/skeleton/skeleton_eventdev.c
+++ b/drivers/event/skeleton/skeleton_eventdev.c
@@ -12,7 +12,7 @@
#include <rte_byteorder.h>
#include <rte_common.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_log.h>
#include <rte_malloc.h>
diff --git a/drivers/gpu/cuda/cuda.c b/drivers/gpu/cuda/cuda.c
index 2be7b8d2df..a552aabeb8 100644
--- a/drivers/gpu/cuda/cuda.c
+++ b/drivers/gpu/cuda/cuda.c
@@ -8,7 +8,7 @@
#include <rte_pci.h>
#include <bus_pci_driver.h>
#include <rte_byteorder.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <gpudev_driver.h>
diff --git a/drivers/mempool/dpaa2/dpaa2_hw_mempool.c b/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
index 56c629c681..84371d5d1a 100644
--- a/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
+++ b/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
@@ -20,7 +20,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "rte_dpaa2_mempool.h"
#include "fslmc_vfio.h"
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
index fd7be47311..9957de2314 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -24,7 +24,7 @@
#include <rte_string_fns.h>
#include <rte_branch_prediction.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_ether.h>
#include <rte_lcore.h>
diff --git a/drivers/net/ark/ark_global.h b/drivers/net/ark/ark_global.h
index 748db590c1..71d0b53e03 100644
--- a/drivers/net/ark/ark_global.h
+++ b/drivers/net/ark/ark_global.h
@@ -15,7 +15,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_version.h>
#include "ark_pktdir.h"
diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
index 7c0cb666fb..b2a08f5635 100644
--- a/drivers/net/avp/avp_ethdev.c
+++ b/drivers/net/avp/avp_ethdev.c
@@ -22,7 +22,7 @@
#include <rte_cycles.h>
#include <rte_spinlock.h>
#include <rte_byteorder.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_memory.h>
#include <rte_eal.h>
#include <rte_io.h>
diff --git a/drivers/net/axgbe/axgbe_common.h b/drivers/net/axgbe/axgbe_common.h
index b9ebf64fb8..a5d11c5832 100644
--- a/drivers/net/axgbe/axgbe_common.h
+++ b/drivers/net/axgbe/axgbe_common.h
@@ -33,7 +33,7 @@
#include <rte_memzone.h>
#include <rte_ether.h>
#include <rte_ethdev.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <ethdev_pci.h>
#include <rte_common.h>
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index f36ad30e17..4448cf2de2 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -9,7 +9,7 @@
#include "bnx2x_rxtx.h"
#include <rte_string_fns.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_pci.h>
#include <rte_alarm.h>
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index e275d3a53f..1460dce2ab 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -6,7 +6,7 @@
#include <inttypes.h>
#include <stdbool.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
#include <rte_malloc.h>
diff --git a/drivers/net/bnxt/rte_pmd_bnxt.c b/drivers/net/bnxt/rte_pmd_bnxt.c
index 77ecbef04c..fd1506ddd4 100644
--- a/drivers/net/bnxt/rte_pmd_bnxt.c
+++ b/drivers/net/bnxt/rte_pmd_bnxt.c
@@ -7,7 +7,7 @@
#include <stdbool.h>
#include <unistd.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <rte_malloc.h>
#include <rte_cycles.h>
diff --git a/drivers/net/cxgbe/base/t4_hw.c b/drivers/net/cxgbe/base/t4_hw.c
index 384080e6d3..bed755f5d9 100644
--- a/drivers/net/cxgbe/base/t4_hw.c
+++ b/drivers/net/cxgbe/base/t4_hw.c
@@ -18,7 +18,7 @@
#include <ethdev_driver.h>
#include <rte_malloc.h>
#include <rte_random.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_byteorder.h>
#include "common.h"
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index fd71a50a58..45bbeaef0c 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -31,7 +31,7 @@
#include <ethdev_pci.h>
#include <rte_malloc.h>
#include <rte_random.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "cxgbe.h"
#include "cxgbe_pfvf.h"
diff --git a/drivers/net/cxgbe/cxgbe_main.c b/drivers/net/cxgbe/cxgbe_main.c
index 3c02c98b3d..f8dd833032 100644
--- a/drivers/net/cxgbe/cxgbe_main.c
+++ b/drivers/net/cxgbe/cxgbe_main.c
@@ -31,7 +31,7 @@
#include <ethdev_driver.h>
#include <ethdev_pci.h>
#include <rte_random.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_kvargs.h>
#include "base/common.h"
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 5d91355c9a..5b13cb5c94 100644
--- a/drivers/net/cxgbe/sge.c
+++ b/drivers/net/cxgbe/sge.c
@@ -30,7 +30,7 @@
#include <ethdev_driver.h>
#include <rte_malloc.h>
#include <rte_random.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "base/common.h"
#include "base/t4_regs.h"
diff --git a/drivers/net/dpaa2/base/dpaa2_hw_dpni.c b/drivers/net/dpaa2/base/dpaa2_hw_dpni.c
index 9509f6e8a3..4d33b51fea 100644
--- a/drivers/net/dpaa2/base/dpaa2_hw_dpni.c
+++ b/drivers/net/dpaa2/base/dpaa2_hw_dpni.c
@@ -15,7 +15,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <dpaa2_pmd_logs.h>
#include <dpaa2_hw_pvt.h>
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index f876f4790c..37a8b43114 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -15,7 +15,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <bus_fslmc_driver.h>
#include <rte_flow_driver.h>
#include "rte_dpaa2_mempool.h"
diff --git a/drivers/net/dpaa2/dpaa2_recycle.c b/drivers/net/dpaa2/dpaa2_recycle.c
index 932570c6e0..fbfdf360d1 100644
--- a/drivers/net/dpaa2/dpaa2_recycle.c
+++ b/drivers/net/dpaa2/dpaa2_recycle.c
@@ -14,7 +14,7 @@
#include <rte_string_fns.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <bus_fslmc_driver.h>
#include <rte_flow_driver.h>
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index 7b9c528d13..9436a95ac8 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -13,7 +13,7 @@
#include <rte_malloc.h>
#include <rte_memcpy.h>
#include <rte_string_fns.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_hexdump.h>
#include <bus_fslmc_driver.h>
diff --git a/drivers/net/dpaa2/dpaa2_sparser.c b/drivers/net/dpaa2/dpaa2_sparser.c
index ba0d500f74..63463c4fbf 100644
--- a/drivers/net/dpaa2/dpaa2_sparser.c
+++ b/drivers/net/dpaa2/dpaa2_sparser.c
@@ -7,7 +7,7 @@
#include <rte_malloc.h>
#include <rte_memcpy.h>
#include <rte_string_fns.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <fslmc_logs.h>
#include <fslmc_vfio.h>
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 409de50083..8ee9be12ad 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -20,7 +20,7 @@
#include <rte_memory.h>
#include <rte_eal.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "e1000_logs.h"
#include "base/e1000_api.h"
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 43979992d3..d6bcc5bf58 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -22,7 +22,7 @@
#include <rte_memory.h>
#include <rte_eal.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "e1000_logs.h"
#include "base/e1000_api.h"
diff --git a/drivers/net/e1000/igb_flow.c b/drivers/net/e1000/igb_flow.c
index e46697b6a1..b775310651 100644
--- a/drivers/net/e1000/igb_flow.c
+++ b/drivers/net/e1000/igb_flow.c
@@ -21,7 +21,7 @@
#include <rte_eal.h>
#include <rte_atomic.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_flow.h>
#include <rte_flow_driver.h>
diff --git a/drivers/net/ena/ena_ethdev.h b/drivers/net/ena/ena_ethdev.h
index 4709675af8..4d27fba585 100644
--- a/drivers/net/ena/ena_ethdev.h
+++ b/drivers/net/ena/ena_ethdev.h
@@ -14,7 +14,7 @@
#include <rte_pci.h>
#include <bus_pci_driver.h>
#include <rte_timer.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_net.h>
#include "ena_com.h"
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 998436e5e8..cdf0915591 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -6,7 +6,7 @@
#include <stdio.h>
#include <stdint.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_pci.h>
#include <bus_pci_driver.h>
#include <ethdev_driver.h>
diff --git a/drivers/net/enic/enic_vf_representor.c b/drivers/net/enic/enic_vf_representor.c
index 7312c411bd..46f85964e9 100644
--- a/drivers/net/enic/enic_vf_representor.c
+++ b/drivers/net/enic/enic_vf_representor.c
@@ -7,7 +7,7 @@
#include <bus_pci_driver.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
#include <rte_flow_driver.h>
diff --git a/drivers/net/failsafe/failsafe_private.h b/drivers/net/failsafe/failsafe_private.h
index a80f5e2caf..53a451c1b1 100644
--- a/drivers/net/failsafe/failsafe_private.h
+++ b/drivers/net/failsafe/failsafe_private.h
@@ -11,7 +11,7 @@
#include <pthread.h>
#include <rte_atomic.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <rte_devargs.h>
#include <rte_flow.h>
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 8bbd8b445d..7adb20bff9 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -7,7 +7,7 @@
#include <rte_malloc.h>
#include <rte_memzone.h>
#include <rte_string_fns.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_spinlock.h>
#include <rte_kvargs.h>
#include <rte_vect.h>
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 87c22b6b54..1775be63c6 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -23,7 +23,7 @@
#include <rte_malloc.h>
#include <rte_memcpy.h>
#include <rte_alarm.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_tailq.h>
#include <rte_hash_crc.h>
#include <rte_bitmap.h>
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 506fcff6e3..ef2ab06475 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -24,7 +24,7 @@
#include <ethdev_pci.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "iavf.h"
#include "iavf_rxtx.h"
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 21bd1e2193..15f695682d 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -19,7 +19,7 @@
#include <rte_ether.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "iavf.h"
#include "iavf_rxtx.h"
diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c
index 885d58c0f4..1c3d22ae0f 100644
--- a/drivers/net/ice/ice_dcf.c
+++ b/drivers/net/ice/ice_dcf.c
@@ -21,7 +21,7 @@
#include <ethdev_pci.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "ice_dcf.h"
#include "ice_rxtx.h"
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index 0da267db1f..dee712af98 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -18,7 +18,7 @@
#include <rte_kvargs.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <iavf_devids.h>
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 552e41692c..04c9ce78a2 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -30,7 +30,7 @@
#include <ethdev_pci.h>
#include <rte_malloc.h>
#include <rte_random.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_hash_crc.h>
#ifdef RTE_LIB_SECURITY
#include <rte_security_driver.h>
diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index 368342872a..67373a7b78 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -27,7 +27,7 @@
#include <ethdev_driver.h>
#include <rte_malloc.h>
#include <rte_random.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_hash_crc.h>
#include <rte_flow.h>
#include <rte_flow_driver.h>
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 910b76a92c..7e7e1824ef 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -31,7 +31,7 @@
#endif
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index ccc06bdda6..d0bbc0a4c0 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -30,7 +30,7 @@
#include <rte_errno.h>
#include <rte_memory.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <bus_driver.h>
#include <bus_vmbus_driver.h>
#include <rte_alarm.h>
diff --git a/drivers/net/netvsc/hn_nvs.c b/drivers/net/netvsc/hn_nvs.c
index 817fb06dfb..7db82af9f3 100644
--- a/drivers/net/netvsc/hn_nvs.c
+++ b/drivers/net/netvsc/hn_nvs.c
@@ -28,7 +28,7 @@
#include <rte_cycles.h>
#include <rte_memory.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <bus_vmbus_driver.h>
#include "hn_logs.h"
diff --git a/drivers/net/netvsc/hn_rndis.c b/drivers/net/netvsc/hn_rndis.c
index 20f75a17b0..e6f1f28768 100644
--- a/drivers/net/netvsc/hn_rndis.c
+++ b/drivers/net/netvsc/hn_rndis.c
@@ -26,7 +26,7 @@
#include <rte_cycles.h>
#include <rte_memory.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <bus_vmbus_driver.h>
#include "hn_logs.h"
diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index 61cf374224..bc6f60c64a 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -25,7 +25,7 @@
#include <rte_errno.h>
#include <rte_memory.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_net.h>
#include <bus_vmbus_driver.h>
#include <rte_spinlock.h>
diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
index 0e55f0c792..eaafe11fb9 100644
--- a/drivers/net/nfp/nfp_common.c
+++ b/drivers/net/nfp/nfp_common.c
@@ -19,7 +19,7 @@
#include <rte_debug.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_ether.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 5cdd34e588..47359501bc 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -16,7 +16,7 @@
#include <rte_common.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_ether.h>
#include <rte_malloc.h>
#include <rte_memzone.h>
diff --git a/drivers/net/octeontx/octeontx_ethdev.c b/drivers/net/octeontx/octeontx_ethdev.c
index 9ada22e2ff..0eee191566 100644
--- a/drivers/net/octeontx/octeontx_ethdev.c
+++ b/drivers/net/octeontx/octeontx_ethdev.c
@@ -15,7 +15,7 @@
#include <bus_vdev_driver.h>
#include <rte_cycles.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_devargs.h>
#include <rte_kvargs.h>
#include <rte_malloc.h>
diff --git a/drivers/net/qede/qede_ethdev.h b/drivers/net/qede/qede_ethdev.h
index a38b701183..b781bcdcfd 100644
--- a/drivers/net/qede/qede_ethdev.h
+++ b/drivers/net/qede/qede_ethdev.h
@@ -13,7 +13,7 @@
#include <rte_ether.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_ip.h>
/* ecore includes */
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index 506c62a726..2ec743ebce 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -7,7 +7,7 @@
* for Solarflare) and Solarflare Communications, Inc.
*/
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <ethdev_driver.h>
#include <ethdev_pci.h>
#include <rte_pci.h>
diff --git a/drivers/net/sfc/sfc_sw_stats.c b/drivers/net/sfc/sfc_sw_stats.c
index 81f5aa3cc4..3ae5023b6f 100644
--- a/drivers/net/sfc/sfc_sw_stats.c
+++ b/drivers/net/sfc/sfc_sw_stats.c
@@ -2,7 +2,7 @@
*
* Copyright(c) 2021 Xilinx, Inc.
*/
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_bitmap.h>
#include "sfc.h"
diff --git a/drivers/net/sfc/sfc_sw_stats.h b/drivers/net/sfc/sfc_sw_stats.h
index 1abded8018..d9738e5214 100644
--- a/drivers/net/sfc/sfc_sw_stats.h
+++ b/drivers/net/sfc/sfc_sw_stats.h
@@ -5,7 +5,7 @@
#ifndef _SFC_SW_STATS_H
#define _SFC_SW_STATS_H
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "sfc.h"
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 28183ec740..9f57cb1a20 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -20,7 +20,7 @@
#include <rte_common.h>
#include <rte_cycles.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_ether.h>
#include <ethdev_driver.h>
diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 5c7430718b..32b7296877 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -27,7 +27,7 @@
#include <rte_alarm.h>
#include <bus_vdev_driver.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_ethdev.h>
#include <rte_ether.h>
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index d180162abd..edf3becd32 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -24,7 +24,7 @@
#include <rte_memory.h>
#include <rte_eal_paging.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_cycles.h>
#include <rte_kvargs.h>
diff --git a/drivers/net/virtio/virtio_pci_ethdev.c b/drivers/net/virtio/virtio_pci_ethdev.c
index 2b9e35cef5..abc63b0935 100644
--- a/drivers/net/virtio/virtio_pci_ethdev.c
+++ b/drivers/net/virtio/virtio_pci_ethdev.c
@@ -16,7 +16,7 @@
#include <rte_memory.h>
#include <rte_eal.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_kvargs.h>
#include "virtio.h"
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 101b1cb500..fd946dec5c 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -30,7 +30,7 @@
#include <ethdev_pci.h>
#include <rte_string_fns.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "base/vmxnet3_defs.h"
diff --git a/drivers/raw/cnxk_bphy/cnxk_bphy.c b/drivers/raw/cnxk_bphy/cnxk_bphy.c
index db029cbf34..909fb8faab 100644
--- a/drivers/raw/cnxk_bphy/cnxk_bphy.c
+++ b/drivers/raw/cnxk_bphy/cnxk_bphy.c
@@ -3,7 +3,7 @@
*/
#include <bus_pci_driver.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_lcore.h>
#include <rte_pci.h>
diff --git a/drivers/raw/skeleton/skeleton_rawdev.c b/drivers/raw/skeleton/skeleton_rawdev.c
index 19b523a815..a06b724866 100644
--- a/drivers/raw/skeleton/skeleton_rawdev.c
+++ b/drivers/raw/skeleton/skeleton_rawdev.c
@@ -13,7 +13,7 @@
#include <rte_byteorder.h>
#include <rte_common.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_kvargs.h>
#include <rte_log.h>
diff --git a/drivers/raw/skeleton/skeleton_rawdev_test.c b/drivers/raw/skeleton/skeleton_rawdev_test.c
index fc257c5f44..8ef7a6b127 100644
--- a/drivers/raw/skeleton/skeleton_rawdev_test.c
+++ b/drivers/raw/skeleton/skeleton_rawdev_test.c
@@ -6,7 +6,7 @@
#include <rte_mbuf.h>
#include <rte_malloc.h>
#include <rte_memcpy.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_rawdev.h>
#include <bus_vdev_driver.h>
#include <rte_test.h>
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c b/drivers/regex/mlx5/mlx5_regex_control.c
index 6ab62a12fc..92cf5f495e 100644
--- a/drivers/regex/mlx5/mlx5_regex_control.c
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -11,7 +11,7 @@
#include <rte_regexdev.h>
#include <rte_regexdev_core.h>
#include <rte_regexdev_driver.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <mlx5_common.h>
#include <mlx5_glue.h>
diff --git a/lib/compressdev/rte_compressdev.c b/lib/compressdev/rte_compressdev.c
index 7f6dedbc52..639a0d66ca 100644
--- a/lib/compressdev/rte_compressdev.c
+++ b/lib/compressdev/rte_compressdev.c
@@ -9,7 +9,7 @@
#include <rte_common.h>
#include <rte_string_fns.h>
#include <rte_malloc.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include <rte_memzone.h>
diff --git a/lib/compressdev/rte_compressdev_pmd.c b/lib/compressdev/rte_compressdev_pmd.c
index 9bfae077db..41f1415bea 100644
--- a/lib/compressdev/rte_compressdev_pmd.c
+++ b/lib/compressdev/rte_compressdev_pmd.c
@@ -5,7 +5,7 @@
#include <rte_string_fns.h>
#include <rte_malloc.h>
#include <rte_kvargs.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_eal.h>
#include "rte_compressdev_internal.h"
diff --git a/lib/compressdev/rte_compressdev_pmd.h b/lib/compressdev/rte_compressdev_pmd.h
index 9fabc399c5..72e52f876f 100644
--- a/lib/compressdev/rte_compressdev_pmd.h
+++ b/lib/compressdev/rte_compressdev_pmd.h
@@ -19,6 +19,7 @@ extern "C" {
#include <string.h>
+#include <dev_driver.h>
#include "rte_compressdev.h"
#include "rte_compressdev_internal.h"
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 75d0075b86..f07b92dfd7 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -4,7 +4,7 @@
#include <sys/queue.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_malloc.h>
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 3dcc3cb7ed..96d7e225b0 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -19,6 +19,7 @@ extern "C" {
#include <string.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_log.h>
#include <rte_common.h>
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 42f3221052..1dad092317 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -13,7 +13,7 @@
#include <rte_log.h>
#include <rte_debug.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_memory.h>
#include <rte_memcpy.h>
#include <rte_memzone.h>
diff --git a/lib/dmadev/rte_dmadev_pmd.h b/lib/dmadev/rte_dmadev_pmd.h
index 82ab7a8cc7..acd7f71cd1 100644
--- a/lib/dmadev/rte_dmadev_pmd.h
+++ b/lib/dmadev/rte_dmadev_pmd.h
@@ -14,7 +14,7 @@
* by any application.
*/
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "rte_dmadev.h"
diff --git a/lib/eal/common/eal_common_dev.c b/lib/eal/common/eal_common_dev.c
index 16c5aef1d8..5b64b80cb9 100644
--- a/lib/eal/common/eal_common_dev.c
+++ b/lib/eal/common/eal_common_dev.c
@@ -8,8 +8,8 @@
#include <sys/queue.h>
#include <bus_driver.h>
+#include <dev_driver.h>
#include <rte_class.h>
-#include <rte_dev.h>
#include <rte_devargs.h>
#include <rte_errno.h>
#include <rte_log.h>
diff --git a/lib/eal/include/dev_driver.h b/lib/eal/include/dev_driver.h
new file mode 100644
index 0000000000..015188abd5
--- /dev/null
+++ b/lib/eal/include/dev_driver.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2022 Red Hat, Inc.
+ */
+
+#ifndef DEV_DRIVER_H
+#define DEV_DRIVER_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_common.h>
+#include <rte_dev.h>
+
+/**
+ * A structure describing a device driver.
+ */
+struct rte_driver {
+ RTE_TAILQ_ENTRY(rte_driver) next; /**< Next in list. */
+ const char *name; /**< Driver name. */
+ const char *alias; /**< Driver alias. */
+};
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* DEV_DRIVER_H */
diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
index 77d8621a51..cfcd40aaed 100644
--- a/lib/eal/include/meson.build
+++ b/lib/eal/include/meson.build
@@ -57,6 +57,7 @@ headers += files(
driver_sdk_headers = files(
'bus_driver.h',
+ 'dev_driver.h',
)
# special case install the generic headers, since they go in a subdir
diff --git a/lib/eal/include/rte_dev.h b/lib/eal/include/rte_dev.h
index 871a046ffe..875ecee371 100644
--- a/lib/eal/include/rte_dev.h
+++ b/lib/eal/include/rte_dev.h
@@ -23,6 +23,8 @@ extern "C" {
#include <rte_compat.h>
#include <rte_log.h>
+struct rte_driver;
+
/**
* The device event type.
*/
@@ -53,15 +55,6 @@ struct rte_mem_resource {
void *addr; /**< Virtual address, NULL when not mapped. */
};
-/**
- * A structure describing a device driver.
- */
-struct rte_driver {
- RTE_TAILQ_ENTRY(rte_driver) next; /**< Next in list. */
- const char *name; /**< Driver name. */
- const char *alias; /**< Driver alias. */
-};
-
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 5101868ea7..47a55a419e 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -19,6 +19,7 @@ extern "C" {
*
*/
+#include <dev_driver.h>
#include <rte_ethdev.h>
/**
diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index 69402668d8..def6cd0876 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -22,7 +22,7 @@ extern "C" {
#include <rte_common.h>
#include <rte_compat.h>
#include <rte_config.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_log.h>
#include <rte_malloc.h>
#include <rte_mbuf.h>
diff --git a/lib/eventdev/rte_event_crypto_adapter.c b/lib/eventdev/rte_event_crypto_adapter.c
index 7c695176f4..5bc10312fc 100644
--- a/lib/eventdev/rte_event_crypto_adapter.c
+++ b/lib/eventdev/rte_event_crypto_adapter.c
@@ -6,7 +6,7 @@
#include <string.h>
#include <stdbool.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_cryptodev.h>
#include <cryptodev_pmd.h>
diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c b/lib/eventdev/rte_event_eth_rx_adapter.c
index bf8741d2ea..4f4efdae9f 100644
--- a/lib/eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/eventdev/rte_event_eth_rx_adapter.c
@@ -9,7 +9,7 @@
#include <rte_cycles.h>
#include <rte_common.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <ethdev_driver.h>
#include <rte_log.h>
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 1dc4f966be..54abee2b3f 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -12,7 +12,7 @@
#include <rte_string_fns.h>
#include <rte_log.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_memzone.h>
#include <rte_eal.h>
#include <rte_common.h>
diff --git a/lib/gpudev/gpudev_driver.h b/lib/gpudev/gpudev_driver.h
index 0e55b00bfe..23972b3dbd 100644
--- a/lib/gpudev/gpudev_driver.h
+++ b/lib/gpudev/gpudev_driver.h
@@ -14,7 +14,7 @@
#include <stdint.h>
#include <sys/queue.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "rte_gpudev.h"
diff --git a/lib/mempool/rte_mempool_ops.c b/lib/mempool/rte_mempool_ops.c
index d60235a7e3..058ad147a5 100644
--- a/lib/mempool/rte_mempool_ops.c
+++ b/lib/mempool/rte_mempool_ops.c
@@ -10,7 +10,7 @@
#include <rte_string_fns.h>
#include <rte_mempool.h>
#include <rte_errno.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include "rte_mempool_trace.h"
diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c
index 72aabd4dd0..af2b814251 100644
--- a/lib/pcapng/rte_pcapng.c
+++ b/lib/pcapng/rte_pcapng.c
@@ -14,7 +14,7 @@
#include <bus_driver.h>
#include <rte_common.h>
#include <rte_cycles.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_errno.h>
#include <rte_ethdev.h>
#include <rte_ether.h>
diff --git a/lib/rawdev/rte_rawdev.c b/lib/rawdev/rte_rawdev.c
index 2f0a4f132e..bc51258143 100644
--- a/lib/rawdev/rte_rawdev.c
+++ b/lib/rawdev/rte_rawdev.c
@@ -12,7 +12,7 @@
#include <rte_string_fns.h>
#include <rte_log.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_common.h>
#include <rte_malloc.h>
#include <rte_telemetry.h>
diff --git a/lib/rawdev/rte_rawdev_pmd.h b/lib/rawdev/rte_rawdev_pmd.h
index 3b7be57d3e..a51944c8ff 100644
--- a/lib/rawdev/rte_rawdev_pmd.h
+++ b/lib/rawdev/rte_rawdev_pmd.h
@@ -19,7 +19,7 @@ extern "C" {
#include <string.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_malloc.h>
#include <rte_log.h>
#include <rte_common.h>
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index 046b6496d2..d036ed33f6 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -6,7 +6,7 @@
#include <rte_common.h>
#include <rte_cryptodev.h>
-#include <rte_dev.h>
+#include <dev_driver.h>
#include <rte_telemetry.h>
#include "rte_security.h"
#include "rte_security_driver.h"
--
2.36.1
^ permalink raw reply [relevance 1%]
* [RFC v2 v2 13/29] bus: hide bus object
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
@ 2022-07-09 8:26 1% ` David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 27/29] dev: hide driver object David Marchand
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-07-09 8:26 UTC (permalink / raw)
To: dev
Cc: Parav Pandit, Xueming Li, Hemant Agrawal, Sachin Saxena,
Rosen Xu, Anatoly Burakov, Stephen Hemminger, Long Li,
Matan Azrad, Viacheslav Ovsiienko, Bruce Richardson, Kevin Laatz,
Chas Williams, Min Hu (Connor),
Gaetan Rivet, Maxime Coquelin, Chenbo Xia, Ray Kinsella,
Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Reshma Pattan
Make rte_bus opaque for non internal users.
This will make extending this object possible without breaking the ABI.
Introduce a new driver header and move rte_bus definition and helpers.
Update drivers and library to use the internal header.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since RFC v1:
- update all existing users of the public header to use the internal one,
---
app/test/test_devargs.c | 2 +-
app/test/test_vdev.c | 2 +-
drivers/bus/auxiliary/auxiliary_common.c | 2 +-
drivers/bus/auxiliary/auxiliary_params.c | 2 +-
drivers/bus/auxiliary/private.h | 2 +-
drivers/bus/dpaa/dpaa_bus.c | 4 +-
drivers/bus/fslmc/fslmc_bus.c | 2 +-
drivers/bus/fslmc/private.h | 2 +-
drivers/bus/ifpga/ifpga_bus.c | 2 +-
drivers/bus/pci/linux/pci_vfio.c | 2 +-
drivers/bus/pci/pci_common.c | 2 +-
drivers/bus/pci/pci_params.c | 2 +-
drivers/bus/pci/private.h | 2 +-
drivers/bus/vdev/vdev.c | 2 +-
drivers/bus/vmbus/private.h | 2 +-
drivers/common/mlx5/mlx5_common_pci.c | 2 +-
drivers/dma/idxd/idxd_bus.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 2 +-
drivers/net/failsafe/failsafe.c | 2 +-
drivers/net/failsafe/failsafe_eal.c | 2 +-
drivers/net/mlx5/linux/mlx5_os.c | 2 +-
drivers/net/netvsc/hn_ethdev.c | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 2 +-
drivers/net/virtio/virtio_pci.c | 2 +-
drivers/raw/ioat/idxd_bus.c | 2 +-
lib/eal/common/eal_common_bus.c | 2 +-
lib/eal/common/eal_common_dev.c | 2 +-
lib/eal/common/eal_common_devargs.c | 2 +-
lib/eal/common/hotplug_mp.c | 2 +-
lib/eal/include/bus_driver.h | 296 +++++++++++++++++++++++
lib/eal/include/meson.build | 4 +
lib/eal/include/rte_bus.h | 275 +--------------------
lib/eal/linux/eal_dev.c | 2 +-
lib/eal/version.map | 4 +-
lib/ethdev/rte_ethdev.c | 2 +-
lib/pcapng/rte_pcapng.c | 2 +-
36 files changed, 338 insertions(+), 307 deletions(-)
create mode 100644 lib/eal/include/bus_driver.h
diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c
index ac5bc34c18..14a0b11fbe 100644
--- a/app/test/test_devargs.c
+++ b/app/test/test_devargs.c
@@ -6,10 +6,10 @@
#include <stdio.h>
#include <string.h>
+#include <bus_driver.h>
#include <rte_common.h>
#include <rte_devargs.h>
#include <rte_kvargs.h>
-#include <rte_bus.h>
#include <rte_class.h>
#include "test.h"
diff --git a/app/test/test_vdev.c b/app/test/test_vdev.c
index 5eeff3106d..9e39993e90 100644
--- a/app/test/test_vdev.c
+++ b/app/test/test_vdev.c
@@ -6,9 +6,9 @@
#include <stdio.h>
#include <string.h>
+#include <bus_driver.h>
#include <rte_common.h>
#include <rte_kvargs.h>
-#include <rte_bus.h>
#include <rte_bus_vdev.h>
#include "test.h"
diff --git a/drivers/bus/auxiliary/auxiliary_common.c b/drivers/bus/auxiliary/auxiliary_common.c
index 0b212f2d64..38d722e653 100644
--- a/drivers/bus/auxiliary/auxiliary_common.c
+++ b/drivers/bus/auxiliary/auxiliary_common.c
@@ -12,7 +12,7 @@
#include <rte_errno.h>
#include <rte_interrupts.h>
#include <rte_log.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_per_lcore.h>
#include <rte_memory.h>
#include <rte_eal.h>
diff --git a/drivers/bus/auxiliary/auxiliary_params.c b/drivers/bus/auxiliary/auxiliary_params.c
index 9017118b36..542083dc89 100644
--- a/drivers/bus/auxiliary/auxiliary_params.c
+++ b/drivers/bus/auxiliary/auxiliary_params.c
@@ -4,7 +4,7 @@
#include <string.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_dev.h>
#include <rte_errno.h>
#include <rte_kvargs.h>
diff --git a/drivers/bus/auxiliary/private.h b/drivers/bus/auxiliary/private.h
index d97e8c694e..1e0e584039 100644
--- a/drivers/bus/auxiliary/private.h
+++ b/drivers/bus/auxiliary/private.h
@@ -9,7 +9,7 @@
#include <stdio.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include "rte_bus_auxiliary.h"
diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index ad4ea156a6..ed3036a642 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -14,6 +14,8 @@
#include <sys/types.h>
#include <sys/eventfd.h>
+#include <bus_driver.h>
+#include <ethdev_driver.h>
#include <rte_byteorder.h>
#include <rte_common.h>
#include <rte_interrupts.h>
@@ -26,10 +28,8 @@
#include <rte_eal.h>
#include <rte_alarm.h>
#include <rte_ether.h>
-#include <ethdev_driver.h>
#include <rte_malloc.h>
#include <rte_ring.h>
-#include <rte_bus.h>
#include <rte_mbuf_pool_ops.h>
#include <rte_mbuf_dyn.h>
diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
index 8498f5321a..0b52c8e46c 100644
--- a/drivers/bus/fslmc/fslmc_bus.c
+++ b/drivers/bus/fslmc/fslmc_bus.c
@@ -9,7 +9,7 @@
#include <stdbool.h>
#include <rte_log.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_malloc.h>
#include <rte_devargs.h>
#include <rte_memcpy.h>
diff --git a/drivers/bus/fslmc/private.h b/drivers/bus/fslmc/private.h
index 80d4673ca8..f08dc7716b 100644
--- a/drivers/bus/fslmc/private.h
+++ b/drivers/bus/fslmc/private.h
@@ -5,7 +5,7 @@
#ifndef __PRIVATE_H__
#define __PRIVATE_H__
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_fslmc.h>
diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c
index 5353dbdb01..d962fb8362 100644
--- a/drivers/bus/ifpga/ifpga_bus.c
+++ b/drivers/bus/ifpga/ifpga_bus.c
@@ -13,8 +13,8 @@
#include <unistd.h>
#include <fcntl.h>
+#include <bus_driver.h>
#include <rte_errno.h>
-#include <rte_bus.h>
#include <rte_per_lcore.h>
#include <rte_memory.h>
#include <rte_memzone.h>
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index cd0d0b1670..fab3483d9f 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -18,7 +18,7 @@
#include <rte_malloc.h>
#include <rte_vfio.h>
#include <rte_eal.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_spinlock.h>
#include <rte_tailq.h>
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 0d61d49287..c26aacd364 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -13,7 +13,7 @@
#include <rte_errno.h>
#include <rte_interrupts.h>
#include <rte_log.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_pci.h>
#include <rte_bus_pci.h>
#include <rte_lcore.h>
diff --git a/drivers/bus/pci/pci_params.c b/drivers/bus/pci/pci_params.c
index 61a868707f..39d702a418 100644
--- a/drivers/bus/pci/pci_params.c
+++ b/drivers/bus/pci/pci_params.c
@@ -4,7 +4,7 @@
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_pci.h>
#include <rte_dev.h>
#include <rte_errno.h>
diff --git a/drivers/bus/pci/private.h b/drivers/bus/pci/private.h
index 6ccec15655..0cefed5edf 100644
--- a/drivers/bus/pci/private.h
+++ b/drivers/bus/pci/private.h
@@ -8,7 +8,7 @@
#include <stdbool.h>
#include <stdio.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_os_shim.h>
#include <rte_pci.h>
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index 804486d3ba..ee569fcdf2 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -10,9 +10,9 @@
#include <stdbool.h>
#include <sys/queue.h>
+#include <bus_driver.h>
#include <rte_eal.h>
#include <rte_dev.h>
-#include <rte_bus.h>
#include <rte_common.h>
#include <rte_devargs.h>
#include <rte_memory.h>
diff --git a/drivers/bus/vmbus/private.h b/drivers/bus/vmbus/private.h
index 597ba18df9..600530c4f6 100644
--- a/drivers/bus/vmbus/private.h
+++ b/drivers/bus/vmbus/private.h
@@ -9,7 +9,7 @@
#include <stdbool.h>
#include <sys/uio.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_log.h>
#include <rte_eal_paging.h>
#include <rte_vmbus_reg.h>
diff --git a/drivers/common/mlx5/mlx5_common_pci.c b/drivers/common/mlx5/mlx5_common_pci.c
index e708e23a7f..838b62b81c 100644
--- a/drivers/common/mlx5/mlx5_common_pci.c
+++ b/drivers/common/mlx5/mlx5_common_pci.c
@@ -9,7 +9,7 @@
#include <rte_errno.h>
#include <rte_class.h>
#include <rte_pci.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_pci.h>
#include "mlx5_common_log.h"
diff --git a/drivers/dma/idxd/idxd_bus.c b/drivers/dma/idxd/idxd_bus.c
index 13cb967f6d..e30dcfc281 100644
--- a/drivers/dma/idxd/idxd_bus.c
+++ b/drivers/dma/idxd/idxd_bus.c
@@ -8,7 +8,7 @@
#include <sys/mman.h>
#include <libgen.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_devargs.h>
#include <rte_eal.h>
#include <rte_log.h>
diff --git a/drivers/net/bonding/rte_eth_bond_args.c b/drivers/net/bonding/rte_eth_bond_args.c
index b90757756a..cc3805baba 100644
--- a/drivers/net/bonding/rte_eth_bond_args.c
+++ b/drivers/net/bonding/rte_eth_bond_args.c
@@ -2,9 +2,9 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
+#include <bus_driver.h>
#include <rte_devargs.h>
#include <rte_pci.h>
-#include <rte_bus.h>
#include <rte_bus_pci.h>
#include <rte_kvargs.h>
diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c
index 3eb7d32b76..7fe77cfe8e 100644
--- a/drivers/net/failsafe/failsafe.c
+++ b/drivers/net/failsafe/failsafe.c
@@ -11,7 +11,7 @@
#include <ethdev_vdev.h>
#include <rte_devargs.h>
#include <rte_kvargs.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_vdev.h>
#include "failsafe_private.h"
diff --git a/drivers/net/failsafe/failsafe_eal.c b/drivers/net/failsafe/failsafe_eal.c
index 130344dce2..d71b512f81 100644
--- a/drivers/net/failsafe/failsafe_eal.c
+++ b/drivers/net/failsafe/failsafe_eal.c
@@ -3,7 +3,7 @@
* Copyright 2017 Mellanox Technologies, Ltd
*/
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_string_fns.h>
#include <rte_malloc.h>
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 04b9614f5c..6899f430cb 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -19,7 +19,7 @@
#include <ethdev_driver.h>
#include <ethdev_pci.h>
#include <rte_pci.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_pci.h>
#include <rte_bus_auxiliary.h>
#include <rte_common.h>
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 308936ad9f..0aedecd358 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -31,7 +31,7 @@
#include <rte_memory.h>
#include <rte_eal.h>
#include <rte_dev.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_vmbus.h>
#include <rte_alarm.h>
diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 2587195168..9d65f75048 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -23,8 +23,8 @@
#include <sys/socket.h>
#include <unistd.h>
+#include <bus_driver.h>
#include <rte_alarm.h>
-#include <rte_bus.h>
#include <rte_bus_vdev.h>
#include <rte_common.h>
#include <rte_dev.h>
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 632451dcbe..9cf4d760b4 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -9,7 +9,7 @@
#endif
#include <rte_io.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include "virtio_pci.h"
#include "virtio_logs.h"
diff --git a/drivers/raw/ioat/idxd_bus.c b/drivers/raw/ioat/idxd_bus.c
index 539f51b1b1..f32d811055 100644
--- a/drivers/raw/ioat/idxd_bus.c
+++ b/drivers/raw/ioat/idxd_bus.c
@@ -10,7 +10,7 @@
#include <fcntl.h>
#include <sys/mman.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_log.h>
#include <rte_string_fns.h>
#include "ioat_private.h"
diff --git a/lib/eal/common/eal_common_bus.c b/lib/eal/common/eal_common_bus.c
index cbf382f967..be64d31b0f 100644
--- a/lib/eal/common/eal_common_bus.c
+++ b/lib/eal/common/eal_common_bus.c
@@ -6,7 +6,7 @@
#include <string.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_debug.h>
#include <rte_string_fns.h>
#include <rte_errno.h>
diff --git a/lib/eal/common/eal_common_dev.c b/lib/eal/common/eal_common_dev.c
index b6f0392f30..62a598957c 100644
--- a/lib/eal/common/eal_common_dev.c
+++ b/lib/eal/common/eal_common_dev.c
@@ -7,7 +7,7 @@
#include <string.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_class.h>
#include <rte_dev.h>
#include <rte_devargs.h>
diff --git a/lib/eal/common/eal_common_devargs.c b/lib/eal/common/eal_common_devargs.c
index d5833af373..03e6e59baf 100644
--- a/lib/eal/common/eal_common_devargs.c
+++ b/lib/eal/common/eal_common_devargs.c
@@ -10,7 +10,7 @@
#include <string.h>
#include <stdarg.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_class.h>
#include <rte_dev.h>
#include <rte_devargs.h>
diff --git a/lib/eal/common/hotplug_mp.c b/lib/eal/common/hotplug_mp.c
index 1614a57752..5202bd5658 100644
--- a/lib/eal/common/hotplug_mp.c
+++ b/lib/eal/common/hotplug_mp.c
@@ -3,7 +3,7 @@
*/
#include <string.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_eal.h>
#include <rte_errno.h>
#include <rte_alarm.h>
diff --git a/lib/eal/include/bus_driver.h b/lib/eal/include/bus_driver.h
new file mode 100644
index 0000000000..d2e615a736
--- /dev/null
+++ b/lib/eal/include/bus_driver.h
@@ -0,0 +1,296 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2022 Red Hat, Inc.
+ */
+
+#ifndef BUS_DRIVER_H
+#define BUS_DRIVER_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_bus.h>
+#include <rte_compat.h>
+#include <rte_dev.h>
+#include <rte_eal.h>
+#include <rte_tailq.h>
+
+struct rte_devargs;
+struct rte_device;
+
+/** Double linked list of buses */
+RTE_TAILQ_HEAD(rte_bus_list, rte_bus);
+
+/**
+ * Bus specific scan for devices attached on the bus.
+ * For each bus object, the scan would be responsible for finding devices and
+ * adding them to its private device list.
+ *
+ * A bus should mandatorily implement this method.
+ *
+ * @return
+ * 0 for successful scan
+ * <0 for unsuccessful scan with error value
+ */
+typedef int (*rte_bus_scan_t)(void);
+
+/**
+ * Implementation specific probe function which is responsible for linking
+ * devices on that bus with applicable drivers.
+ *
+ * This is called while iterating over each registered bus.
+ *
+ * @return
+ * 0 for successful probe
+ * !0 for any error while probing
+ */
+typedef int (*rte_bus_probe_t)(void);
+
+/**
+ * Device iterator to find a device on a bus.
+ *
+ * This function returns an rte_device if one of those held by the bus
+ * matches the data passed as parameter.
+ *
+ * If the comparison function returns zero this function should stop iterating
+ * over any more devices. To continue a search the device of a previous search
+ * can be passed via the start parameter.
+ *
+ * @param cmp
+ * Comparison function.
+ *
+ * @param data
+ * Data to compare each device against.
+ *
+ * @param start
+ * starting point for the iteration
+ *
+ * @return
+ * The first device matching the data, NULL if none exists.
+ */
+typedef struct rte_device *
+(*rte_bus_find_device_t)(const struct rte_device *start, rte_dev_cmp_t cmp,
+ const void *data);
+
+/**
+ * Implementation specific probe function which is responsible for linking
+ * devices on that bus with applicable drivers.
+ *
+ * @param dev
+ * Device pointer that was returned by a previous call to find_device.
+ *
+ * @return
+ * 0 on success.
+ * !0 on error.
+ */
+typedef int (*rte_bus_plug_t)(struct rte_device *dev);
+
+/**
+ * Implementation specific remove function which is responsible for unlinking
+ * devices on that bus from assigned driver.
+ *
+ * @param dev
+ * Device pointer that was returned by a previous call to find_device.
+ *
+ * @return
+ * 0 on success.
+ * !0 on error.
+ */
+typedef int (*rte_bus_unplug_t)(struct rte_device *dev);
+
+/**
+ * Bus specific parsing function.
+ * Validates the syntax used in the textual representation of a device,
+ * If the syntax is valid and ``addr`` is not NULL, writes the bus-specific
+ * device representation to ``addr``.
+ *
+ * @param[in] name
+ * device textual description
+ *
+ * @param[out] addr
+ * device information location address, into which parsed info
+ * should be written. If NULL, nothing should be written, which
+ * is not an error.
+ *
+ * @return
+ * 0 if parsing was successful.
+ * !0 for any error.
+ */
+typedef int (*rte_bus_parse_t)(const char *name, void *addr);
+
+/**
+ * Parse bus part of the device arguments.
+ *
+ * The field name of the struct rte_devargs will be set.
+ *
+ * @param da
+ * Pointer to the devargs to parse.
+ *
+ * @return
+ * 0 on successful parsing, otherwise rte_errno is set.
+ * -EINVAL: on parsing error.
+ * -ENODEV: if no key matching a device argument is specified.
+ * -E2BIG: device name is too long.
+ */
+typedef int (*rte_bus_devargs_parse_t)(struct rte_devargs *da);
+
+/**
+ * Device level DMA map function.
+ * After a successful call, the memory segment will be mapped to the
+ * given device.
+ *
+ * @param dev
+ * Device pointer.
+ * @param addr
+ * Virtual address to map.
+ * @param iova
+ * IOVA address to map.
+ * @param len
+ * Length of the memory segment being mapped.
+ *
+ * @return
+ * 0 if mapping was successful.
+ * Negative value and rte_errno is set otherwise.
+ */
+typedef int (*rte_dev_dma_map_t)(struct rte_device *dev, void *addr,
+ uint64_t iova, size_t len);
+
+/**
+ * Device level DMA unmap function.
+ * After a successful call, the memory segment will no longer be
+ * accessible by the given device.
+ *
+ * @param dev
+ * Device pointer.
+ * @param addr
+ * Virtual address to unmap.
+ * @param iova
+ * IOVA address to unmap.
+ * @param len
+ * Length of the memory segment being mapped.
+ *
+ * @return
+ * 0 if un-mapping was successful.
+ * Negative value and rte_errno is set otherwise.
+ */
+typedef int (*rte_dev_dma_unmap_t)(struct rte_device *dev, void *addr,
+ uint64_t iova, size_t len);
+
+/**
+ * Implement a specific hot-unplug handler, which is responsible for
+ * handle the failure when device be hot-unplugged. When the event of
+ * hot-unplug be detected, it could call this function to handle
+ * the hot-unplug failure and avoid app crash.
+ * @param dev
+ * Pointer of the device structure.
+ *
+ * @return
+ * 0 on success.
+ * !0 on error.
+ */
+typedef int (*rte_bus_hot_unplug_handler_t)(struct rte_device *dev);
+
+/**
+ * Implement a specific sigbus handler, which is responsible for handling
+ * the sigbus error which is either original memory error, or specific memory
+ * error that caused of device be hot-unplugged. When sigbus error be captured,
+ * it could call this function to handle sigbus error.
+ * @param failure_addr
+ * Pointer of the fault address of the sigbus error.
+ *
+ * @return
+ * 0 for success handle the sigbus for hot-unplug.
+ * 1 for not process it, because it is a generic sigbus error.
+ * -1 for failed to handle the sigbus for hot-unplug.
+ */
+typedef int (*rte_bus_sigbus_handler_t)(const void *failure_addr);
+
+/**
+ * Bus scan policies
+ */
+enum rte_bus_scan_mode {
+ RTE_BUS_SCAN_UNDEFINED,
+ RTE_BUS_SCAN_ALLOWLIST,
+ RTE_BUS_SCAN_BLOCKLIST,
+};
+
+/**
+ * A structure used to configure bus operations.
+ */
+struct rte_bus_conf {
+ enum rte_bus_scan_mode scan_mode; /**< Scan policy. */
+};
+
+
+/**
+ * Get common iommu class of the all the devices on the bus. The bus may
+ * check that those devices are attached to iommu driver.
+ * If no devices are attached to the bus. The bus may return with don't care
+ * (_DC) value.
+ * Otherwise, The bus will return appropriate _pa or _va iova mode.
+ *
+ * @return
+ * enum rte_iova_mode value.
+ */
+typedef enum rte_iova_mode (*rte_bus_get_iommu_class_t)(void);
+
+/**
+ * A structure describing a generic bus.
+ */
+struct rte_bus {
+ RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
+ const char *name; /**< Name of the bus */
+ rte_bus_scan_t scan; /**< Scan for devices attached to bus */
+ rte_bus_probe_t probe; /**< Probe devices on bus */
+ rte_bus_find_device_t find_device; /**< Find a device on the bus */
+ rte_bus_plug_t plug; /**< Probe single device for drivers */
+ rte_bus_unplug_t unplug; /**< Remove single device from driver */
+ rte_bus_parse_t parse; /**< Parse a device name */
+ rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
+ rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
+ rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
+ struct rte_bus_conf conf; /**< Bus configuration */
+ rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
+ rte_dev_iterate_t dev_iterate; /**< Device iterator. */
+ rte_bus_hot_unplug_handler_t hot_unplug_handler;
+ /**< handle hot-unplug failure on the bus */
+ rte_bus_sigbus_handler_t sigbus_handler;
+ /**< handle sigbus error on the bus */
+};
+
+/**
+ * Register a Bus handler.
+ *
+ * @param bus
+ * A pointer to a rte_bus structure describing the bus
+ * to be registered.
+ */
+__rte_internal
+void rte_bus_register(struct rte_bus *bus);
+
+/**
+ * Helper for Bus registration.
+ * The constructor has higher priority than PMD constructors.
+ */
+#define RTE_REGISTER_BUS(nm, bus) \
+RTE_INIT_PRIO(businitfn_ ##nm, BUS) \
+{\
+ (bus).name = RTE_STR(nm);\
+ rte_bus_register(&bus); \
+}
+
+/**
+ * Unregister a Bus handler.
+ *
+ * @param bus
+ * A pointer to a rte_bus structure describing the bus
+ * to be unregistered.
+ */
+__rte_internal
+void rte_bus_unregister(struct rte_bus *bus);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* BUS_DRIVER_H */
diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
index fd6e844224..77d8621a51 100644
--- a/lib/eal/include/meson.build
+++ b/lib/eal/include/meson.build
@@ -55,6 +55,10 @@ headers += files(
'rte_vfio.h',
)
+driver_sdk_headers = files(
+ 'bus_driver.h',
+)
+
# special case install the generic headers, since they go in a subdir
generic_headers = files(
'generic/rte_atomic.h',
diff --git a/lib/eal/include/rte_bus.h b/lib/eal/include/rte_bus.h
index 2775e1ac66..902a6c7c59 100644
--- a/lib/eal/include/rte_bus.h
+++ b/lib/eal/include/rte_bus.h
@@ -20,251 +20,11 @@ extern "C" {
#include <stdio.h>
-#include <rte_dev.h>
+#include <rte_compat.h>
#include <rte_eal.h>
-#include <rte_log.h>
-/** Double linked list of buses */
-RTE_TAILQ_HEAD(rte_bus_list, rte_bus);
-
-/**
- * Bus specific scan for devices attached on the bus.
- * For each bus object, the scan would be responsible for finding devices and
- * adding them to its private device list.
- *
- * A bus should mandatorily implement this method.
- *
- * @return
- * 0 for successful scan
- * <0 for unsuccessful scan with error value
- */
-typedef int (*rte_bus_scan_t)(void);
-
-/**
- * Implementation specific probe function which is responsible for linking
- * devices on that bus with applicable drivers.
- *
- * This is called while iterating over each registered bus.
- *
- * @return
- * 0 for successful probe
- * !0 for any error while probing
- */
-typedef int (*rte_bus_probe_t)(void);
-
-/**
- * Device iterator to find a device on a bus.
- *
- * This function returns an rte_device if one of those held by the bus
- * matches the data passed as parameter.
- *
- * If the comparison function returns zero this function should stop iterating
- * over any more devices. To continue a search the device of a previous search
- * can be passed via the start parameter.
- *
- * @param cmp
- * Comparison function.
- *
- * @param data
- * Data to compare each device against.
- *
- * @param start
- * starting point for the iteration
- *
- * @return
- * The first device matching the data, NULL if none exists.
- */
-typedef struct rte_device *
-(*rte_bus_find_device_t)(const struct rte_device *start, rte_dev_cmp_t cmp,
- const void *data);
-
-/**
- * Implementation specific probe function which is responsible for linking
- * devices on that bus with applicable drivers.
- *
- * @param dev
- * Device pointer that was returned by a previous call to find_device.
- *
- * @return
- * 0 on success.
- * !0 on error.
- */
-typedef int (*rte_bus_plug_t)(struct rte_device *dev);
-
-/**
- * Implementation specific remove function which is responsible for unlinking
- * devices on that bus from assigned driver.
- *
- * @param dev
- * Device pointer that was returned by a previous call to find_device.
- *
- * @return
- * 0 on success.
- * !0 on error.
- */
-typedef int (*rte_bus_unplug_t)(struct rte_device *dev);
-
-/**
- * Bus specific parsing function.
- * Validates the syntax used in the textual representation of a device,
- * If the syntax is valid and ``addr`` is not NULL, writes the bus-specific
- * device representation to ``addr``.
- *
- * @param[in] name
- * device textual description
- *
- * @param[out] addr
- * device information location address, into which parsed info
- * should be written. If NULL, nothing should be written, which
- * is not an error.
- *
- * @return
- * 0 if parsing was successful.
- * !0 for any error.
- */
-typedef int (*rte_bus_parse_t)(const char *name, void *addr);
-
-/**
- * Parse bus part of the device arguments.
- *
- * The field name of the struct rte_devargs will be set.
- *
- * @param da
- * Pointer to the devargs to parse.
- *
- * @return
- * 0 on successful parsing, otherwise rte_errno is set.
- * -EINVAL: on parsing error.
- * -ENODEV: if no key matching a device argument is specified.
- * -E2BIG: device name is too long.
- */
-typedef int (*rte_bus_devargs_parse_t)(struct rte_devargs *da);
-
-/**
- * Device level DMA map function.
- * After a successful call, the memory segment will be mapped to the
- * given device.
- *
- * @param dev
- * Device pointer.
- * @param addr
- * Virtual address to map.
- * @param iova
- * IOVA address to map.
- * @param len
- * Length of the memory segment being mapped.
- *
- * @return
- * 0 if mapping was successful.
- * Negative value and rte_errno is set otherwise.
- */
-typedef int (*rte_dev_dma_map_t)(struct rte_device *dev, void *addr,
- uint64_t iova, size_t len);
-
-/**
- * Device level DMA unmap function.
- * After a successful call, the memory segment will no longer be
- * accessible by the given device.
- *
- * @param dev
- * Device pointer.
- * @param addr
- * Virtual address to unmap.
- * @param iova
- * IOVA address to unmap.
- * @param len
- * Length of the memory segment being mapped.
- *
- * @return
- * 0 if un-mapping was successful.
- * Negative value and rte_errno is set otherwise.
- */
-typedef int (*rte_dev_dma_unmap_t)(struct rte_device *dev, void *addr,
- uint64_t iova, size_t len);
-
-/**
- * Implement a specific hot-unplug handler, which is responsible for
- * handle the failure when device be hot-unplugged. When the event of
- * hot-unplug be detected, it could call this function to handle
- * the hot-unplug failure and avoid app crash.
- * @param dev
- * Pointer of the device structure.
- *
- * @return
- * 0 on success.
- * !0 on error.
- */
-typedef int (*rte_bus_hot_unplug_handler_t)(struct rte_device *dev);
-
-/**
- * Implement a specific sigbus handler, which is responsible for handling
- * the sigbus error which is either original memory error, or specific memory
- * error that caused of device be hot-unplugged. When sigbus error be captured,
- * it could call this function to handle sigbus error.
- * @param failure_addr
- * Pointer of the fault address of the sigbus error.
- *
- * @return
- * 0 for success handle the sigbus for hot-unplug.
- * 1 for not process it, because it is a generic sigbus error.
- * -1 for failed to handle the sigbus for hot-unplug.
- */
-typedef int (*rte_bus_sigbus_handler_t)(const void *failure_addr);
-
-/**
- * Bus scan policies
- */
-enum rte_bus_scan_mode {
- RTE_BUS_SCAN_UNDEFINED,
- RTE_BUS_SCAN_ALLOWLIST,
- RTE_BUS_SCAN_BLOCKLIST,
-};
-
-/**
- * A structure used to configure bus operations.
- */
-struct rte_bus_conf {
- enum rte_bus_scan_mode scan_mode; /**< Scan policy. */
-};
-
-
-/**
- * Get common iommu class of the all the devices on the bus. The bus may
- * check that those devices are attached to iommu driver.
- * If no devices are attached to the bus. The bus may return with don't care
- * (_DC) value.
- * Otherwise, The bus will return appropriate _pa or _va iova mode.
- *
- * @return
- * enum rte_iova_mode value.
- */
-typedef enum rte_iova_mode (*rte_bus_get_iommu_class_t)(void);
-
-
-/**
- * A structure describing a generic bus.
- */
-struct rte_bus {
- RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
- const char *name; /**< Name of the bus */
- rte_bus_scan_t scan; /**< Scan for devices attached to bus */
- rte_bus_probe_t probe; /**< Probe devices on bus */
- rte_bus_find_device_t find_device; /**< Find a device on the bus */
- rte_bus_plug_t plug; /**< Probe single device for drivers */
- rte_bus_unplug_t unplug; /**< Remove single device from driver */
- rte_bus_parse_t parse; /**< Parse a device name */
- rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
- rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
- rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
- struct rte_bus_conf conf; /**< Bus configuration */
- rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
- rte_dev_iterate_t dev_iterate; /**< Device iterator. */
- rte_bus_hot_unplug_handler_t hot_unplug_handler;
- /**< handle hot-unplug failure on the bus */
- rte_bus_sigbus_handler_t sigbus_handler;
- /**< handle sigbus error on the bus */
-
-};
+struct rte_bus;
+struct rte_device;
/**
* @warning
@@ -278,24 +38,6 @@ struct rte_bus {
__rte_experimental
const char *rte_bus_name(const struct rte_bus *bus);
-/**
- * Register a Bus handler.
- *
- * @param bus
- * A pointer to a rte_bus structure describing the bus
- * to be registered.
- */
-void rte_bus_register(struct rte_bus *bus);
-
-/**
- * Unregister a Bus handler.
- *
- * @param bus
- * A pointer to a rte_bus structure describing the bus
- * to be unregistered.
- */
-void rte_bus_unregister(struct rte_bus *bus);
-
/**
* Scan all the buses.
*
@@ -385,17 +127,6 @@ struct rte_bus *rte_bus_find_by_name(const char *busname);
*/
enum rte_iova_mode rte_bus_get_iommu_class(void);
-/**
- * Helper for Bus registration.
- * The constructor has higher priority than PMD constructors.
- */
-#define RTE_REGISTER_BUS(nm, bus) \
-RTE_INIT_PRIO(businitfn_ ##nm, BUS) \
-{\
- (bus).name = RTE_STR(nm);\
- rte_bus_register(&bus); \
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/eal/linux/eal_dev.c b/lib/eal/linux/eal_dev.c
index 02ae1cde29..b5eab93fbf 100644
--- a/lib/eal/linux/eal_dev.c
+++ b/lib/eal/linux/eal_dev.c
@@ -8,12 +8,12 @@
#include <sys/socket.h>
#include <linux/netlink.h>
+#include <bus_driver.h>
#include <rte_string_fns.h>
#include <rte_log.h>
#include <rte_dev.h>
#include <rte_interrupts.h>
#include <rte_alarm.h>
-#include <rte_bus.h>
#include <rte_spinlock.h>
#include <rte_errno.h>
diff --git a/lib/eal/version.map b/lib/eal/version.map
index 6f713c987d..48c8a2f511 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -13,9 +13,7 @@ DPDK_22 {
rte_bus_find_by_name;
rte_bus_get_iommu_class;
rte_bus_probe;
- rte_bus_register;
rte_bus_scan;
- rte_bus_unregister;
rte_calloc;
rte_calloc_socket;
rte_cpu_get_flag_enabled;
@@ -432,6 +430,8 @@ EXPERIMENTAL {
INTERNAL {
global:
+ rte_bus_register;
+ rte_bus_unregister;
rte_eal_get_baseaddr;
rte_firmware_read;
rte_intr_allow_others;
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index ebbe8cca3d..9eba97f2d2 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -11,7 +11,7 @@
#include <string.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_log.h>
#include <rte_interrupts.h>
#include <rte_memcpy.h>
diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c
index 5b079cd14a..72aabd4dd0 100644
--- a/lib/pcapng/rte_pcapng.c
+++ b/lib/pcapng/rte_pcapng.c
@@ -11,7 +11,7 @@
#include <time.h>
#include <unistd.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_common.h>
#include <rte_cycles.h>
#include <rte_dev.h>
--
2.36.1
^ permalink raw reply [relevance 1%]
* [RFC v2 v2 00/29] Bus and device cleanup for 22.11
2022-06-28 14:46 2% [RFC PATCH 00/11] Bus cleanup for 22.11 David Marchand
2022-06-28 14:46 1% ` [RFC PATCH 11/11] bus: hide bus object David Marchand
@ 2022-07-09 8:26 1% ` David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 13/29] bus: hide bus object David Marchand
` (4 more replies)
1 sibling, 5 replies; 200+ results
From: David Marchand @ 2022-07-09 8:26 UTC (permalink / raw)
To: dev
This is a PoC for hiding the rte_bus, rte_driver and rte_device objects.
And mark associated driver only API as internal.
A good amount of the patches are preparation work on rte_bus.h,
rte_dev.h, rte_devargs.h and rte_eal.h headers, removing dependencies
between them. This is something I had in store for some time, maybe I
should have dropped it from the PoC, but I think those cleanups are
worth it in any case.
Then PCI bus specific handling are moved from unit tests and examples,
though there is still a special case left in testpmd that may require a
new API, to be discussed.
After this series, driver-only API headers for registering to buses are
not exported anymore, unless the enable_driver_sdk meson option is
selected.
New accessors for rte_bus, rte_driver and rte_device have been added,
marked with an experimental tag though we may declare them as stable
right away so that users can switch to them directly. That's also
something to agree on.
I simplified my series and switched to only update "external" users,
like app/ and examples/ files.
We need some checkpatch new checks to be sure we won't get some
driver-only headers included in these areas. That's something I'll work
on in the non RFC series.
"Internal" users are simply using the internal headers. That helps
greatly reducing the size of the changes.
Disclaimer: again, in this v2, this series is a bit rushed (I brute forced
compilation tests in GHA so that it passes between patches, but there still
may be something broken...).
Not surprisingly, the ABI check in the CI is expected to fail.
Comments welcome.
Changes since RFC v1:
- added two more cleanups (new patch 3 and 4) for unit test and examples
relying on PCI specific info,
- went on with masking rte_driver and rte_device too,
--
David Marchand
David Marchand (29):
common/mlx5: rework check on driver registration
raw/ifpga: remove PCI bus accessor
kni: stop populating PCI info in examples
examples/ethtool: prefer device name
dev: hide debug messages in device iterator
dev: move unrelated macros from header
devargs: remove dependency on bus header
bus: remove unneeded inclusion of bus header
bus: move IOVA definition from header
drivers/bus: remove back reference to bus objects
drivers/bus: hide specific structures
bus: introduce accessors
bus: hide bus object
bbdev: mark driver header
ethdev: mark some headers as driver only
rawdev: mark driver header
drivers: export drivers headers
bus/auxiliary: make driver-only headers private
bus/dpaa: make driver-only headers private
bus/fslmc: make driver-only headers private
bus/ifpga: cleanup exported symbols
bus/ifpga: make driver-only headers private
bus/pci: make driver-only headers private
bus/vdev: make driver-only headers private
bus/vmbus: make driver-only headers private
dev: introduce driver name
dev: hide driver object
dev: introduce device accessors
dev: hide device object
app/proc-info/main.c | 6 +-
app/test-compress-perf/comp_perf_options.h | 2 +
app/test-pmd/config.c | 12 +-
app/test-pmd/testpmd.c | 4 +-
app/test-pmd/testpmd.h | 7 +-
app/test/test_devargs.c | 6 +-
app/test/test_kni.c | 30 --
app/test/test_vdev.c | 3 +-
app/test/virtual_pmd.c | 2 +-
drivers/baseband/acc100/rte_acc100_pmd.c | 4 +-
.../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 4 +-
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 4 +-
drivers/baseband/la12xx/bbdev_la12xx.c | 2 +-
drivers/baseband/null/bbdev_null.c | 2 +-
.../baseband/turbo_sw/bbdev_turbo_software.c | 2 +-
drivers/bus/auxiliary/auxiliary_common.c | 5 +-
drivers/bus/auxiliary/auxiliary_params.c | 5 +-
...bus_auxiliary.h => bus_auxiliary_driver.h} | 20 +-
drivers/bus/auxiliary/linux/auxiliary.c | 2 -
drivers/bus/auxiliary/meson.build | 4 +-
drivers/bus/auxiliary/private.h | 30 +-
drivers/bus/auxiliary/version.map | 3 +-
drivers/bus/dpaa/base/qbman/qman.c | 2 +-
.../{rte_dpaa_bus.h => bus_dpaa_driver.h} | 25 +-
drivers/bus/dpaa/dpaa_bus.c | 24 +-
.../fslmc/{rte_fslmc.h => bus_fslmc_driver.h} | 30 +-
drivers/bus/fslmc/fslmc_bus.c | 14 +-
drivers/bus/fslmc/fslmc_vfio.c | 5 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c | 4 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpci.c | 4 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
drivers/bus/fslmc/portal/dpaa2_hw_dprc.c | 4 +-
drivers/bus/fslmc/private.h | 27 ++
.../{rte_bus_ifpga.h => bus_ifpga_driver.h} | 19 +-
drivers/bus/ifpga/ifpga_bus.c | 23 +-
drivers/bus/ifpga/ifpga_common.c | 88 ------
drivers/bus/ifpga/ifpga_common.h | 54 +++-
drivers/bus/ifpga/meson.build | 4 +-
drivers/bus/ifpga/version.map | 4 +-
drivers/bus/pci/bsd/pci.c | 3 -
drivers/bus/pci/bus_pci_driver.h | 200 ++++++++++++
drivers/bus/pci/linux/pci.c | 3 -
drivers/bus/pci/linux/pci_vfio.c | 2 +-
drivers/bus/pci/meson.build | 1 +
drivers/bus/pci/pci_common.c | 4 +-
drivers/bus/pci/pci_params.c | 4 +-
drivers/bus/pci/private.h | 19 +-
drivers/bus/pci/rte_bus_pci.h | 201 +-----------
drivers/bus/pci/version.map | 11 +-
drivers/bus/pci/windows/pci.c | 1 +
drivers/bus/pci/windows/pci_netuio.c | 1 +
drivers/bus/vdev/bus_vdev_driver.h | 151 +++++++++
drivers/bus/vdev/meson.build | 1 +
drivers/bus/vdev/rte_bus_vdev.h | 134 --------
drivers/bus/vdev/vdev.c | 12 +-
drivers/bus/vdev/vdev_params.c | 3 +-
drivers/bus/vdev/version.map | 9 +-
drivers/bus/vmbus/bus_vmbus_driver.h | 106 +++++++
drivers/bus/vmbus/linux/vmbus_uio.c | 1 -
drivers/bus/vmbus/meson.build | 1 +
drivers/bus/vmbus/private.h | 20 +-
drivers/bus/vmbus/rte_bus_vmbus.h | 104 ------
drivers/bus/vmbus/version.map | 9 +-
drivers/bus/vmbus/vmbus_bufring.c | 1 -
drivers/bus/vmbus/vmbus_channel.c | 1 -
drivers/bus/vmbus/vmbus_common.c | 3 -
drivers/bus/vmbus/vmbus_common_uio.c | 1 -
drivers/common/cnxk/roc_platform.h | 2 +-
.../common/mlx5/linux/mlx5_common_auxiliary.c | 12 +-
drivers/common/mlx5/linux/mlx5_common_os.c | 4 +-
drivers/common/mlx5/linux/mlx5_common_os.h | 2 +-
drivers/common/mlx5/mlx5_common.h | 2 +-
drivers/common/mlx5/mlx5_common_pci.c | 3 +-
drivers/common/mlx5/mlx5_common_private.h | 2 +-
drivers/common/mlx5/windows/mlx5_common_os.c | 2 +-
drivers/common/qat/dev/qat_dev_gen4.c | 2 +-
drivers/common/qat/qat_device.c | 1 +
drivers/common/qat/qat_device.h | 2 +-
drivers/common/qat/qat_qp.c | 4 +-
drivers/common/sfc_efx/sfc_efx.h | 2 +-
drivers/compress/isal/isal_compress_pmd.c | 2 +-
drivers/compress/mlx5/mlx5_compress.c | 2 +-
drivers/compress/octeontx/otx_zip.h | 2 +-
drivers/compress/qat/qat_comp.c | 2 +-
drivers/compress/qat/qat_comp_pmd.c | 1 +
drivers/compress/zlib/zlib_pmd.c | 2 +-
drivers/compress/zlib/zlib_pmd_ops.c | 1 +
drivers/crypto/armv8/rte_armv8_pmd.c | 2 +-
drivers/crypto/bcmfs/bcmfs_device.h | 2 +-
drivers/crypto/bcmfs/bcmfs_qp.c | 2 +-
drivers/crypto/bcmfs/bcmfs_sym_pmd.c | 2 +-
drivers/crypto/caam_jr/caam_jr.c | 2 +-
drivers/crypto/ccp/ccp_dev.h | 2 +-
drivers/crypto/ccp/ccp_pci.h | 2 +-
drivers/crypto/ccp/rte_ccp_pmd.c | 6 +-
drivers/crypto/cnxk/cn10k_cryptodev.c | 4 +-
drivers/crypto/cnxk/cn9k_cryptodev.c | 4 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 4 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_raw_dp.c | 2 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 4 +-
drivers/crypto/dpaa_sec/dpaa_sec_raw_dp.c | 2 +-
drivers/crypto/ipsec_mb/ipsec_mb_private.c | 2 +-
drivers/crypto/ipsec_mb/ipsec_mb_private.h | 2 +-
drivers/crypto/ipsec_mb/pmd_kasumi.c | 2 +-
drivers/crypto/mlx5/mlx5_crypto.c | 2 +-
drivers/crypto/mvsam/rte_mrvl_pmd.c | 2 +-
drivers/crypto/nitrox/nitrox_device.h | 2 +-
drivers/crypto/null/null_crypto_pmd.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev.c | 2 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 2 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 2 +-
drivers/crypto/qat/qat_sym.c | 2 +-
.../scheduler/rte_cryptodev_scheduler.c | 1 +
drivers/crypto/scheduler/scheduler_pmd.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 2 +-
drivers/crypto/virtio/virtio_cryptodev.c | 2 +-
drivers/crypto/virtio/virtio_pci.c | 1 -
drivers/crypto/virtio/virtio_pci.h | 2 +-
drivers/dma/cnxk/cnxk_dmadev.c | 3 +-
drivers/dma/dpaa/dpaa_qdma.c | 2 +-
drivers/dma/dpaa2/dpaa2_qdma.c | 2 +-
drivers/dma/hisilicon/hisi_dmadev.c | 2 +-
drivers/dma/idxd/idxd_bus.c | 3 +-
drivers/dma/idxd/idxd_pci.c | 2 +-
drivers/dma/ioat/ioat_dmadev.c | 2 +-
drivers/dma/skeleton/skeleton_dmadev.c | 2 +-
drivers/event/dlb2/dlb2.c | 2 +-
drivers/event/dlb2/pf/dlb2_main.h | 2 +-
drivers/event/dlb2/pf/dlb2_pf.c | 4 +-
drivers/event/dpaa/dpaa_eventdev.c | 4 +-
drivers/event/dpaa2/dpaa2_eventdev.c | 6 +-
drivers/event/dpaa2/dpaa2_eventdev_selftest.c | 4 +-
drivers/event/dpaa2/dpaa2_hw_dpcon.c | 4 +-
drivers/event/octeontx/ssovf_evdev.c | 4 +-
drivers/event/octeontx/ssovf_evdev_selftest.c | 2 +-
drivers/event/octeontx/ssovf_probe.c | 2 +-
drivers/event/octeontx/timvf_probe.c | 2 +-
drivers/event/opdl/opdl_evdev.c | 2 +-
drivers/event/opdl/opdl_evdev_init.c | 2 +-
drivers/event/opdl/opdl_test.c | 2 +-
drivers/event/skeleton/skeleton_eventdev.c | 4 +-
drivers/event/sw/sw_evdev.c | 2 +-
drivers/event/sw/sw_evdev_selftest.c | 2 +-
drivers/gpu/cuda/cuda.c | 4 +-
drivers/mempool/cnxk/cnxk_mempool.c | 2 +-
drivers/mempool/dpaa/dpaa_mempool.h | 2 +-
drivers/mempool/dpaa2/dpaa2_hw_mempool.c | 2 +-
drivers/mempool/octeontx/octeontx_fpavf.c | 2 +-
drivers/meson.build | 4 +
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 4 +-
drivers/net/ark/ark_ethdev.c | 2 +-
drivers/net/ark/ark_global.h | 2 +-
drivers/net/avp/avp_ethdev.c | 4 +-
drivers/net/axgbe/axgbe_common.h | 2 +-
drivers/net/bnx2x/bnx2x.h | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 2 +-
drivers/net/bnxt/bnxt.h | 2 +-
drivers/net/bnxt/bnxt_ethdev.c | 2 +-
drivers/net/bnxt/rte_pmd_bnxt.c | 2 +-
drivers/net/bonding/rte_eth_bond_api.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 3 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 2 +-
drivers/net/cxgbe/base/adapter.h | 2 +-
drivers/net/cxgbe/base/t4_hw.c | 2 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 4 +-
drivers/net/cxgbe/cxgbe_main.c | 2 +-
drivers/net/cxgbe/sge.c | 2 +-
drivers/net/dpaa/dpaa_ethdev.c | 2 +-
drivers/net/dpaa/dpaa_rxtx.c | 2 +-
drivers/net/dpaa2/base/dpaa2_hw_dpni.c | 2 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 4 +-
drivers/net/dpaa2/dpaa2_ethdev.h | 2 +-
drivers/net/dpaa2/dpaa2_mux.c | 2 +-
drivers/net/dpaa2/dpaa2_ptp.c | 2 +-
drivers/net/dpaa2/dpaa2_recycle.c | 4 +-
drivers/net/dpaa2/dpaa2_rxtx.c | 4 +-
drivers/net/dpaa2/dpaa2_sparser.c | 2 +-
drivers/net/e1000/em_ethdev.c | 4 +-
drivers/net/e1000/em_rxtx.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 4 +-
drivers/net/e1000/igb_flow.c | 2 +-
drivers/net/e1000/igb_pf.c | 2 +-
drivers/net/ena/ena_ethdev.h | 4 +-
drivers/net/enic/base/vnic_dev.h | 2 +-
drivers/net/enic/enic_ethdev.c | 4 +-
drivers/net/enic/enic_main.c | 2 +-
drivers/net/enic/enic_vf_representor.c | 4 +-
drivers/net/failsafe/failsafe.c | 3 +-
drivers/net/failsafe/failsafe_eal.c | 1 +
drivers/net/failsafe/failsafe_private.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 2 +-
drivers/net/hinic/base/hinic_pmd_hwdev.c | 2 +-
drivers/net/hinic/base/hinic_pmd_hwif.c | 2 +-
drivers/net/hinic/base/hinic_pmd_nicio.c | 2 +-
drivers/net/hinic/hinic_pmd_ethdev.c | 2 +-
drivers/net/hns3/hns3_common.c | 2 +-
drivers/net/hns3/hns3_ethdev.c | 2 +-
drivers/net/hns3/hns3_rxtx.c | 2 +-
drivers/net/i40e/i40e_ethdev.c | 4 +-
drivers/net/i40e/i40e_vf_representor.c | 2 +-
drivers/net/iavf/iavf_ethdev.c | 2 +-
drivers/net/iavf/iavf_vchnl.c | 2 +-
drivers/net/ice/ice_dcf.c | 2 +-
drivers/net/ice/ice_dcf_ethdev.c | 2 +-
drivers/net/igc/igc_ethdev.c | 2 +-
drivers/net/ionic/ionic.h | 2 +-
drivers/net/ionic/ionic_ethdev.c | 2 +-
drivers/net/ipn3ke/ipn3ke_ethdev.c | 4 +-
drivers/net/ipn3ke/ipn3ke_ethdev.h | 4 +-
drivers/net/ipn3ke/ipn3ke_flow.c | 2 +-
drivers/net/ipn3ke/ipn3ke_representor.c | 4 +-
drivers/net/ipn3ke/ipn3ke_tm.c | 4 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +-
drivers/net/ixgbe/ixgbe_ethdev.h | 2 +-
drivers/net/ixgbe/ixgbe_flow.c | 2 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 1 +
drivers/net/kni/rte_eth_kni.c | 2 +-
drivers/net/liquidio/lio_ethdev.c | 1 +
drivers/net/memif/memif_socket.c | 2 +-
drivers/net/memif/rte_eth_memif.c | 2 +-
drivers/net/mlx4/mlx4.c | 2 +-
drivers/net/mlx4/mlx4_ethdev.c | 2 +-
drivers/net/mlx5/linux/mlx5_ethdev_os.c | 2 +-
drivers/net/mlx5/linux/mlx5_os.c | 5 +-
drivers/net/mlx5/mlx5.c | 2 +-
drivers/net/mlx5/mlx5_ethdev.c | 2 +-
drivers/net/mlx5/mlx5_flow_dv.c | 2 +-
drivers/net/mlx5/mlx5_txq.c | 2 +-
drivers/net/mvneta/mvneta_ethdev.c | 2 +-
drivers/net/mvpp2/mrvl_ethdev.c | 2 +-
drivers/net/netvsc/hn_ethdev.c | 5 +-
drivers/net/netvsc/hn_nvs.c | 4 +-
drivers/net/netvsc/hn_rndis.c | 4 +-
drivers/net/netvsc/hn_rxtx.c | 4 +-
drivers/net/netvsc/hn_vf.c | 4 +-
drivers/net/nfp/nfp_common.c | 2 +-
drivers/net/nfp/nfp_ethdev.c | 2 +-
drivers/net/ngbe/base/ngbe_osdep.h | 2 +-
drivers/net/ngbe/ngbe_pf.c | 2 +-
drivers/net/null/rte_eth_null.c | 2 +-
drivers/net/octeontx/base/octeontx_pkivf.c | 2 +-
drivers/net/octeontx/base/octeontx_pkovf.c | 2 +-
drivers/net/octeontx/octeontx_ethdev.c | 4 +-
drivers/net/pcap/pcap_ethdev.c | 2 +-
drivers/net/pfe/pfe_ethdev.c | 2 +-
drivers/net/qede/base/bcm_osal.h | 2 +-
drivers/net/qede/qede_ethdev.h | 2 +-
drivers/net/ring/rte_eth_ring.c | 2 +-
drivers/net/sfc/sfc.h | 2 +-
drivers/net/sfc/sfc_ethdev.c | 4 +-
drivers/net/sfc/sfc_sriov.c | 2 +-
drivers/net/sfc/sfc_sw_stats.c | 2 +-
drivers/net/sfc/sfc_sw_stats.h | 2 +-
drivers/net/softnic/rte_eth_softnic.c | 2 +-
drivers/net/tap/rte_eth_tap.c | 2 +-
drivers/net/thunderx/nicvf_ethdev.c | 4 +-
drivers/net/txgbe/txgbe_ethdev.h | 2 +-
drivers/net/txgbe/txgbe_flow.c | 2 +-
drivers/net/txgbe/txgbe_pf.c | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 6 +-
drivers/net/vhost/rte_eth_vhost.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/virtio/virtio_pci.c | 2 +-
drivers/net/virtio/virtio_pci.h | 2 +-
drivers/net/virtio/virtio_pci_ethdev.c | 4 +-
drivers/net/virtio/virtio_user_ethdev.c | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 4 +-
drivers/raw/cnxk_bphy/cnxk_bphy.c | 4 +-
drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 2 +-
drivers/raw/cnxk_bphy/cnxk_bphy_irq.c | 2 +-
drivers/raw/cnxk_gpio/cnxk_gpio.c | 2 +-
drivers/raw/dpaa2_cmdif/dpaa2_cmdif.c | 2 +-
drivers/raw/ifpga/afu_pmd_core.h | 2 +-
drivers/raw/ifpga/afu_pmd_he_hssi.c | 4 +-
drivers/raw/ifpga/afu_pmd_he_lpbk.c | 4 +-
drivers/raw/ifpga/afu_pmd_he_mem.c | 4 +-
drivers/raw/ifpga/afu_pmd_n3000.c | 4 +-
drivers/raw/ifpga/ifpga_rawdev.c | 15 +-
drivers/raw/ifpga/ifpga_rawdev.h | 1 -
drivers/raw/ifpga/rte_pmd_ifpga.c | 8 +-
drivers/raw/ifpga/rte_pmd_ifpga.h | 10 -
drivers/raw/ifpga/version.map | 1 -
drivers/raw/ioat/idxd_bus.c | 2 +-
drivers/raw/ioat/idxd_pci.c | 2 +-
drivers/raw/ioat/ioat_rawdev.c | 2 +-
drivers/raw/ntb/ntb.c | 2 +-
drivers/raw/ntb/ntb_hw_intel.c | 2 +-
drivers/raw/skeleton/skeleton_rawdev.c | 4 +-
drivers/raw/skeleton/skeleton_rawdev_test.c | 4 +-
drivers/regex/mlx5/mlx5_regex.c | 2 +-
drivers/regex/mlx5/mlx5_regex_control.c | 2 +-
drivers/regex/mlx5/mlx5_regex_fastpath.c | 2 +-
drivers/vdpa/ifc/base/ifcvf_osdep.h | 2 +-
drivers/vdpa/ifc/ifcvf_vdpa.c | 2 +-
drivers/vdpa/mlx5/mlx5_vdpa.c | 2 +-
drivers/vdpa/sfc/sfc_vdpa.h | 2 +-
examples/ethtool/lib/rte_ethtool.c | 17 +-
examples/ip_pipeline/kni.c | 10 -
examples/l3fwd/l3fwd_em.c | 4 +-
examples/l3fwd/l3fwd_fib.c | 8 +-
examples/l3fwd/l3fwd_lpm.c | 4 +-
examples/multi_process/hotplug_mp/commands.c | 6 +-
examples/vdpa/main.c | 16 +-
lib/bbdev/meson.build | 5 +-
lib/compressdev/rte_compressdev.c | 2 +
lib/compressdev/rte_compressdev_pmd.c | 1 +
lib/compressdev/rte_compressdev_pmd.h | 1 +
lib/cryptodev/cryptodev_pmd.c | 2 +
lib/cryptodev/cryptodev_pmd.h | 1 +
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/dmadev/rte_dmadev.c | 1 +
lib/dmadev/rte_dmadev_pmd.h | 2 +-
lib/eal/common/eal_common_bus.c | 28 +-
lib/eal/common/eal_common_dev.c | 41 ++-
lib/eal/common/eal_common_devargs.c | 2 +-
lib/eal/common/eal_private.h | 2 +-
lib/eal/common/eal_thread.h | 1 +
lib/eal/common/hotplug_mp.c | 1 +
lib/eal/include/bus_driver.h | 296 ++++++++++++++++++
lib/eal/include/dev_driver.h | 42 +++
lib/eal/include/meson.build | 5 +
lib/eal/include/rte_bus.h | 293 +----------------
lib/eal/include/rte_common.h | 11 +
lib/eal/include/rte_dev.h | 89 ++++--
lib/eal/include/rte_devargs.h | 4 +-
lib/eal/include/rte_eal.h | 15 +-
lib/eal/include/rte_lcore.h | 2 +
lib/eal/linux/eal_dev.c | 2 +-
lib/eal/version.map | 12 +-
lib/eal/windows/eal.c | 1 +
lib/ethdev/ethdev_driver.c | 1 +
lib/ethdev/ethdev_driver.h | 1 +
lib/ethdev/ethdev_pci.h | 5 +-
lib/ethdev/ethdev_vdev.h | 2 +-
lib/ethdev/meson.build | 6 +-
lib/ethdev/rte_ethdev.c | 1 +
lib/ethdev/rte_ethdev.h | 2 +-
lib/eventdev/eventdev_pmd.h | 2 +-
lib/eventdev/eventdev_pmd_pci.h | 2 +-
lib/eventdev/eventdev_pmd_vdev.h | 2 +-
lib/eventdev/rte_event_crypto_adapter.c | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
lib/eventdev/rte_eventdev.c | 2 +-
lib/gpudev/gpudev_driver.h | 2 +-
lib/mempool/rte_mempool_ops.c | 3 +-
lib/pcapng/rte_pcapng.c | 3 +-
lib/rawdev/meson.build | 3 +-
lib/rawdev/rte_rawdev.c | 2 +-
lib/rawdev/rte_rawdev_pmd.h | 2 +-
lib/regexdev/rte_regexdev.c | 1 +
lib/security/rte_security.c | 3 +-
lib/vhost/vdpa.c | 2 +
353 files changed, 1605 insertions(+), 1480 deletions(-)
rename drivers/bus/auxiliary/{rte_bus_auxiliary.h => bus_auxiliary_driver.h} (91%)
rename drivers/bus/dpaa/{rte_dpaa_bus.h => bus_dpaa_driver.h} (92%)
rename drivers/bus/fslmc/{rte_fslmc.h => bus_fslmc_driver.h} (88%)
create mode 100644 drivers/bus/fslmc/private.h
rename drivers/bus/ifpga/{rte_bus_ifpga.h => bus_ifpga_driver.h} (91%)
delete mode 100644 drivers/bus/ifpga/ifpga_common.c
create mode 100644 drivers/bus/pci/bus_pci_driver.h
create mode 100644 drivers/bus/vdev/bus_vdev_driver.h
create mode 100644 drivers/bus/vmbus/bus_vmbus_driver.h
create mode 100644 lib/eal/include/bus_driver.h
create mode 100644 lib/eal/include/dev_driver.h
--
2.36.1
^ permalink raw reply [relevance 1%]
* [PATCH v10] sched: enable CMAN at runtime
[not found] <20220708131431.148279-1-marcinx.danilewicz>
@ 2022-07-08 14:22 1% ` Marcin Danilewicz
0 siblings, 0 replies; 200+ results
From: Marcin Danilewicz @ 2022-07-08 14:22 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
v6 commit message fixed
v7 changes from comments
v8 with changes from comments
v9 changes from comments
tmgr.c
cman_params set to null
qos_sched/cfg_file.c
removed redundant cman_params to NULL assignement
subport_params[].cman_params assigned
only when CMAN enabled
v10 removed ip_pipelin app build error from change
in tmgr.c
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 75 +-----------
examples/qos_sched/cfg_file.c | 49 +-------
examples/qos_sched/cfg_file.h | 5 -
examples/qos_sched/init.c | 76 +-----------
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 135 +--------------------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 298 insertions(+), 391 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3e4bed81e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-#define WRED_SUPPORTED 1
-#else
#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..2432b56aee 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,77 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
-static struct rte_sched_cman_params cman_params = {
- .red_params = {
- /* Traffic Class 0 Colors Green / Yellow / Red */
- [0][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 1 - Colors Green / Yellow / Red */
- [1][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 2 - Colors Green / Yellow / Red */
- [2][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 3 - Colors Green / Yellow / Red */
- [3][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 4 - Colors Green / Yellow / Red */
- [4][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 5 - Colors Green / Yellow / Red */
- [5][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 6 - Colors Green / Yellow / Red */
- [6][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 7 - Colors Green / Yellow / Red */
- [7][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 8 - Colors Green / Yellow / Red */
- [8][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 9 - Colors Green / Yellow / Red */
- [9][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 10 - Colors Green / Yellow / Red */
- [10][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 11 - Colors Green / Yellow / Red */
- [11][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 12 - Colors Green / Yellow / Red */
- [12][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- },
-};
-#endif /* RTE_SCHED_CMAN */
-
static uint32_t n_pipe_profiles;
static const struct rte_sched_subport_params subport_params_default = {
@@ -96,9 +25,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
- .cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
+ .cman_params = NULL,
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..deaa28d391 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -23,6 +23,8 @@
uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
uint32_t n_active_queues;
+struct rte_sched_cman_params cman_params;
+
int
cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port_params)
{
@@ -229,40 +231,6 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
- struct rte_sched_cman_params cman_p)
-{
- int j, k;
- subport_p->cman_params->cman_mode = cman_p.cman_mode;
-
- for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
- if (subport_p->cman_params->cman_mode ==
- RTE_SCHED_CMAN_RED) {
- for (k = 0; k < RTE_COLORS; k++) {
- subport_p->cman_params->red_params[j][k].min_th =
- cman_p.red_params[j][k].min_th;
- subport_p->cman_params->red_params[j][k].max_th =
- cman_p.red_params[j][k].max_th;
- subport_p->cman_params->red_params[j][k].maxp_inv =
- cman_p.red_params[j][k].maxp_inv;
- subport_p->cman_params->red_params[j][k].wq_log2 =
- cman_p.red_params[j][k].wq_log2;
- }
- } else {
- subport_p->cman_params->pie_params[j].qdelay_ref =
- cman_p.pie_params[j].qdelay_ref;
- subport_p->cman_params->pie_params[j].dp_update_interval =
- cman_p.pie_params[j].dp_update_interval;
- subport_p->cman_params->pie_params[j].max_burst =
- cman_p.pie_params[j].max_burst;
- subport_p->cman_params->pie_params[j].tailq_th =
- cman_p.pie_params[j].tailq_th;
- }
- }
-}
-#endif
-
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
{
@@ -276,12 +244,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
- struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
- .red_params = { },
- };
-
if (rte_cfgfile_has_section(cfg, "red")) {
cman_params.cman_mode = RTE_SCHED_CMAN_RED;
@@ -387,7 +349,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +426,9 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
- set_subport_cman_params(subport_params+i, cman_params);
-#endif
+ if (cman_params.cman_mode == RTE_SCHED_CMAN_PIE ||
+ cman_params.cman_mode == RTE_SCHED_CMAN_RED)
+ subport_params[i].cman_params = &cman_params;
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..0dc458aa71 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,11 +12,6 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
-void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
- struct rte_sched_cman_params cman_p);
-#endif
-
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
int cfg_load_subport_profile(struct rte_cfgfile *cfg,
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..e8b819ffb9 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,78 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
-struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
- .red_params = {
- /* Traffic Class 0 Colors Green / Yellow / Red */
- [0][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 1 - Colors Green / Yellow / Red */
- [1][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 2 - Colors Green / Yellow / Red */
- [2][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 3 - Colors Green / Yellow / Red */
- [3][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 4 - Colors Green / Yellow / Red */
- [4][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 5 - Colors Green / Yellow / Red */
- [5][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 6 - Colors Green / Yellow / Red */
- [6][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 7 - Colors Green / Yellow / Red */
- [7][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 8 - Colors Green / Yellow / Red */
- [8][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 9 - Colors Green / Yellow / Red */
- [9][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 10 - Colors Green / Yellow / Red */
- [10][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 11 - Colors Green / Yellow / Red */
- [11][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 12 - Colors Green / Yellow / Red */
- [12][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- },
-};
-#endif /* RTE_SCHED_CMAN */
-
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
.n_pipes_per_subport_enabled = 4096,
@@ -281,9 +209,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
- .cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
+ .cman_params = NULL,
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..c9ec187c93 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -73,137 +73,4 @@ tc period = 40 ; Milliseconds
tc 12 oversubscription weight = 1
-tc 12 wrr weights = 1 1 1 1
-
-; RED params per traffic class and color (Green / Yellow / Red)
-;[red]
-;tc 0 wred min = 48 40 32
-;tc 0 wred max = 64 64 64
-;tc 0 wred inv prob = 10 10 10
-;tc 0 wred weight = 9 9 9
-
-;tc 1 wred min = 48 40 32
-;tc 1 wred max = 64 64 64
-;tc 1 wred inv prob = 10 10 10
-;tc 1 wred weight = 9 9 9
-
-;tc 2 wred min = 48 40 32
-;tc 2 wred max = 64 64 64
-;tc 2 wred inv prob = 10 10 10
-;tc 2 wred weight = 9 9 9
-
-;tc 3 wred min = 48 40 32
-;tc 3 wred max = 64 64 64
-;tc 3 wred inv prob = 10 10 10
-;tc 3 wred weight = 9 9 9
-
-;tc 4 wred min = 48 40 32
-;tc 4 wred max = 64 64 64
-;tc 4 wred inv prob = 10 10 10
-;tc 4 wred weight = 9 9 9
-
-;tc 5 wred min = 48 40 32
-;tc 5 wred max = 64 64 64
-;tc 5 wred inv prob = 10 10 10
-;tc 5 wred weight = 9 9 9
-
-;tc 6 wred min = 48 40 32
-;tc 6 wred max = 64 64 64
-;tc 6 wred inv prob = 10 10 10
-;tc 6 wred weight = 9 9 9
-
-;tc 7 wred min = 48 40 32
-;tc 7 wred max = 64 64 64
-;tc 7 wred inv prob = 10 10 10
-;tc 7 wred weight = 9 9 9
-
-;tc 8 wred min = 48 40 32
-;tc 8 wred max = 64 64 64
-;tc 8 wred inv prob = 10 10 10
-;tc 8 wred weight = 9 9 9
-
-;tc 9 wred min = 48 40 32
-;tc 9 wred max = 64 64 64
-;tc 9 wred inv prob = 10 10 10
-;tc 9 wred weight = 9 9 9
-
-;tc 10 wred min = 48 40 32
-;tc 10 wred max = 64 64 64
-;tc 10 wred inv prob = 10 10 10
-;tc 10 wred weight = 9 9 9
-
-;tc 11 wred min = 48 40 32
-;tc 11 wred max = 64 64 64
-;tc 11 wred inv prob = 10 10 10
-;tc 11 wred weight = 9 9 9
-
-;tc 12 wred min = 48 40 32
-;tc 12 wred max = 64 64 64
-;tc 12 wred inv prob = 10 10 10
-;tc 12 wred weight = 9 9 9
-
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+tc 12 wrr weights = 1 1 1 1
\ No newline at end of file
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* [PATCH v9] sched: enable CMAN at runtime
2022-07-05 17:05 1% ` [PATCH v8] " Marcin Danilewicz
2022-07-05 18:00 0% ` Ajmera, Megha
2022-07-06 8:53 0% ` Singh, Jasvinder
@ 2022-07-08 13:14 1% ` Marcin Danilewicz
2 siblings, 0 replies; 200+ results
From: Marcin Danilewicz @ 2022-07-08 13:14 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
v6 commit message fixed
v7 changes from comments
v8 with changes from comments
v9 changes from comments
tmgr.c
cman_params set to null
qos_sched/cfg_file.c
removed redundant cman_params to NULL assignement
subport_params[].cman_params assigned
only when CMAN enabled
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 6 +-
examples/qos_sched/cfg_file.c | 49 +-------
examples/qos_sched/cfg_file.h | 5 -
examples/qos_sched/init.c | 76 +-----------
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 135 +--------------------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 298 insertions(+), 322 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3e4bed81e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-#define WRED_SUPPORTED 1
-#else
#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..18bee1e0fc 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
- .cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
+ .cman_params = NULL,
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..deaa28d391 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -23,6 +23,8 @@
uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
uint32_t n_active_queues;
+struct rte_sched_cman_params cman_params;
+
int
cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port_params)
{
@@ -229,40 +231,6 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
- struct rte_sched_cman_params cman_p)
-{
- int j, k;
- subport_p->cman_params->cman_mode = cman_p.cman_mode;
-
- for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
- if (subport_p->cman_params->cman_mode ==
- RTE_SCHED_CMAN_RED) {
- for (k = 0; k < RTE_COLORS; k++) {
- subport_p->cman_params->red_params[j][k].min_th =
- cman_p.red_params[j][k].min_th;
- subport_p->cman_params->red_params[j][k].max_th =
- cman_p.red_params[j][k].max_th;
- subport_p->cman_params->red_params[j][k].maxp_inv =
- cman_p.red_params[j][k].maxp_inv;
- subport_p->cman_params->red_params[j][k].wq_log2 =
- cman_p.red_params[j][k].wq_log2;
- }
- } else {
- subport_p->cman_params->pie_params[j].qdelay_ref =
- cman_p.pie_params[j].qdelay_ref;
- subport_p->cman_params->pie_params[j].dp_update_interval =
- cman_p.pie_params[j].dp_update_interval;
- subport_p->cman_params->pie_params[j].max_burst =
- cman_p.pie_params[j].max_burst;
- subport_p->cman_params->pie_params[j].tailq_th =
- cman_p.pie_params[j].tailq_th;
- }
- }
-}
-#endif
-
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
{
@@ -276,12 +244,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
- struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
- .red_params = { },
- };
-
if (rte_cfgfile_has_section(cfg, "red")) {
cman_params.cman_mode = RTE_SCHED_CMAN_RED;
@@ -387,7 +349,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +426,9 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
- set_subport_cman_params(subport_params+i, cman_params);
-#endif
+ if (cman_params.cman_mode == RTE_SCHED_CMAN_PIE ||
+ cman_params.cman_mode == RTE_SCHED_CMAN_RED)
+ subport_params[i].cman_params = &cman_params;
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..0dc458aa71 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,11 +12,6 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
-void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
- struct rte_sched_cman_params cman_p);
-#endif
-
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
int cfg_load_subport_profile(struct rte_cfgfile *cfg,
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..e8b819ffb9 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,78 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
-struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
- .red_params = {
- /* Traffic Class 0 Colors Green / Yellow / Red */
- [0][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 1 - Colors Green / Yellow / Red */
- [1][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 2 - Colors Green / Yellow / Red */
- [2][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 3 - Colors Green / Yellow / Red */
- [3][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 4 - Colors Green / Yellow / Red */
- [4][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 5 - Colors Green / Yellow / Red */
- [5][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 6 - Colors Green / Yellow / Red */
- [6][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 7 - Colors Green / Yellow / Red */
- [7][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 8 - Colors Green / Yellow / Red */
- [8][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 9 - Colors Green / Yellow / Red */
- [9][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 10 - Colors Green / Yellow / Red */
- [10][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 11 - Colors Green / Yellow / Red */
- [11][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 12 - Colors Green / Yellow / Red */
- [12][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- },
-};
-#endif /* RTE_SCHED_CMAN */
-
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
.n_pipes_per_subport_enabled = 4096,
@@ -281,9 +209,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
- .cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
+ .cman_params = NULL,
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..c9ec187c93 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -73,137 +73,4 @@ tc period = 40 ; Milliseconds
tc 12 oversubscription weight = 1
-tc 12 wrr weights = 1 1 1 1
-
-; RED params per traffic class and color (Green / Yellow / Red)
-;[red]
-;tc 0 wred min = 48 40 32
-;tc 0 wred max = 64 64 64
-;tc 0 wred inv prob = 10 10 10
-;tc 0 wred weight = 9 9 9
-
-;tc 1 wred min = 48 40 32
-;tc 1 wred max = 64 64 64
-;tc 1 wred inv prob = 10 10 10
-;tc 1 wred weight = 9 9 9
-
-;tc 2 wred min = 48 40 32
-;tc 2 wred max = 64 64 64
-;tc 2 wred inv prob = 10 10 10
-;tc 2 wred weight = 9 9 9
-
-;tc 3 wred min = 48 40 32
-;tc 3 wred max = 64 64 64
-;tc 3 wred inv prob = 10 10 10
-;tc 3 wred weight = 9 9 9
-
-;tc 4 wred min = 48 40 32
-;tc 4 wred max = 64 64 64
-;tc 4 wred inv prob = 10 10 10
-;tc 4 wred weight = 9 9 9
-
-;tc 5 wred min = 48 40 32
-;tc 5 wred max = 64 64 64
-;tc 5 wred inv prob = 10 10 10
-;tc 5 wred weight = 9 9 9
-
-;tc 6 wred min = 48 40 32
-;tc 6 wred max = 64 64 64
-;tc 6 wred inv prob = 10 10 10
-;tc 6 wred weight = 9 9 9
-
-;tc 7 wred min = 48 40 32
-;tc 7 wred max = 64 64 64
-;tc 7 wred inv prob = 10 10 10
-;tc 7 wred weight = 9 9 9
-
-;tc 8 wred min = 48 40 32
-;tc 8 wred max = 64 64 64
-;tc 8 wred inv prob = 10 10 10
-;tc 8 wred weight = 9 9 9
-
-;tc 9 wred min = 48 40 32
-;tc 9 wred max = 64 64 64
-;tc 9 wred inv prob = 10 10 10
-;tc 9 wred weight = 9 9 9
-
-;tc 10 wred min = 48 40 32
-;tc 10 wred max = 64 64 64
-;tc 10 wred inv prob = 10 10 10
-;tc 10 wred weight = 9 9 9
-
-;tc 11 wred min = 48 40 32
-;tc 11 wred max = 64 64 64
-;tc 11 wred inv prob = 10 10 10
-;tc 11 wred weight = 9 9 9
-
-;tc 12 wred min = 48 40 32
-;tc 12 wred max = 64 64 64
-;tc 12 wred inv prob = 10 10 10
-;tc 12 wred weight = 9 9 9
-
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+tc 12 wrr weights = 1 1 1 1
\ No newline at end of file
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* RE: [PATCH v4 2/7] bbdev: add device status info
2022-07-07 13:37 0% ` Tom Rix
@ 2022-07-07 17:15 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-07-07 17:15 UTC (permalink / raw)
To: Tom Rix, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
Hi Tom,
> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Sent: Thursday, July 7, 2022 6:37 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; gakhil@marvell.com; hemant.agrawal@nxp.com
> Cc: maxime.coquelin@redhat.com; mdr@ashroe.eu; Richardson, Bruce
> <bruce.richardson@intel.com>; david.marchand@redhat.com;
> stephen@networkplumber.org
> Subject: Re: [PATCH v4 2/7] bbdev: add device status info
>
>
> On 7/6/22 2:16 PM, Chautru, Nicolas wrote:
> >> -----Original Message-----
> >> From: Tom Rix <trix@redhat.com>
> >> Subject: Re: [PATCH v4 2/7] bbdev: add device status info
> >>
> >>
> >> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> >>> Added device status information, so that the PMD can expose
> >>> information related to the underlying accelerator device status.
> >>> Minor order change in structure to fit into padding hole.
> >>>
> >>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> >>> ---
> >>> drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
> >>> drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
> >>> drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
> >>> drivers/baseband/la12xx/bbdev_la12xx.c | 1 +
> >>> drivers/baseband/null/bbdev_null.c | 1 +
> >>> drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
> >>> lib/bbdev/rte_bbdev.c | 24 +++++++++++++++
> >>> lib/bbdev/rte_bbdev.h | 35 ++++++++++++++++++++--
> >>> lib/bbdev/version.map | 6 ++++
> >>> 9 files changed, 69 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> >>> b/drivers/baseband/acc100/rte_acc100_pmd.c
> >>> index de7e4bc..17ba798 100644
> >>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> >>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> >>> @@ -1060,6 +1060,7 @@
> >>>
> >>> /* Read and save the populated config from ACC100 registers */
> >>> fetch_acc100_config(dev);
> >>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >>>
> >>> /* This isn't ideal because it reports the maximum number of
> >>> queues
> >> but
> >>> * does not provide info on how many can be uplink/downlink or
> >>> different diff --git
> >>> a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> >>> b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> >>> index 82ae6ba..57b12af 100644
> >>> --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> >>> +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> >>> @@ -369,6 +369,7 @@
> >>> dev_info->capabilities = bbdev_capabilities;
> >>> dev_info->cpu_flag_reqs = NULL;
> >>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> >>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >>>
> >>> /* Calculates number of queues assigned to device */
> >>> dev_info->max_num_queues = 0;
> >>> diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> >>> b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> >>> index 21d3529..2a330c4 100644
> >>> --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> >>> +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> >>> @@ -645,6 +645,7 @@ struct __rte_cache_aligned fpga_queue {
> >>> dev_info->capabilities = bbdev_capabilities;
> >>> dev_info->cpu_flag_reqs = NULL;
> >>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> >>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >>>
> >>> /* Calculates number of queues assigned to device */
> >>> dev_info->max_num_queues = 0;
> >>> diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
> >>> b/drivers/baseband/la12xx/bbdev_la12xx.c
> >>> index 4d1bd16..c1f88c6 100644
> >>> --- a/drivers/baseband/la12xx/bbdev_la12xx.c
> >>> +++ b/drivers/baseband/la12xx/bbdev_la12xx.c
> >>> @@ -100,6 +100,7 @@ struct bbdev_la12xx_params {
> >>> dev_info->capabilities = bbdev_capabilities;
> >>> dev_info->cpu_flag_reqs = NULL;
> >>> dev_info->min_alignment = 64;
> >>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >>>
> >>> rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
> >>> }
> >>> diff --git a/drivers/baseband/null/bbdev_null.c
> >>> b/drivers/baseband/null/bbdev_null.c
> >>> index 248e129..94a1976 100644
> >>> --- a/drivers/baseband/null/bbdev_null.c
> >>> +++ b/drivers/baseband/null/bbdev_null.c
> >>> @@ -82,6 +82,7 @@ struct bbdev_queue {
> >>> * here for code completeness.
> >>> */
> >>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> >>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >>>
> >>> rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
> >>> }
> >>> diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> >>> b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> >>> index af7bc41..dbc5524 100644
> >>> --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> >>> +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> >>> @@ -254,6 +254,7 @@ struct turbo_sw_queue {
> >>> dev_info->min_alignment = 64;
> >>> dev_info->harq_buffer_size = 0;
> >>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> >>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >>>
> >>> rte_bbdev_log_debug("got device info from %u\n", dev->data-
> >>> dev_id);
> >>> }
> >>> diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
> >>> 22bd894..555bda9 100644
> >>> --- a/lib/bbdev/rte_bbdev.c
> >>> +++ b/lib/bbdev/rte_bbdev.c
> >>> @@ -25,6 +25,8 @@
> >>>
> >>> /* Number of supported operation types */
> >>> #define BBDEV_OP_TYPE_COUNT 5
> >>> +/* Number of supported device status */ #define
> >>> +BBDEV_DEV_STATUS_COUNT 9
> >>>
> >>> /* BBDev library logging ID */
> >>> RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE); @@ -1132,3
> >> +1134,25
> >>> @@ struct rte_mempool *
> >>> rte_bbdev_log(ERR, "Invalid operation type");
> >>> return NULL;
> >>> }
> >>> +
> >>> +const char *
> >>> +rte_bbdev_device_status_str(enum rte_bbdev_device_status status) {
> >>> + static const char * const dev_sta_string[] = {
> >>> + "RTE_BBDEV_DEV_NOSTATUS",
> >>> + "RTE_BBDEV_DEV_NOT_SUPPORTED",
> >>> + "RTE_BBDEV_DEV_RESET",
> >>> + "RTE_BBDEV_DEV_CONFIGURED",
> >>> + "RTE_BBDEV_DEV_ACTIVE",
> >>> + "RTE_BBDEV_DEV_FATAL_ERR",
> >>> + "RTE_BBDEV_DEV_RESTART_REQ",
> >>> + "RTE_BBDEV_DEV_RECONFIG_REQ",
> >>> + "RTE_BBDEV_DEV_CORRECT_ERR",
> >>> + };
> >>> +
> >>> + if (status < BBDEV_DEV_STATUS_COUNT)
> >>> + return dev_sta_string[status];
> >>> +
> >>> + rte_bbdev_log(ERR, "Invalid device status");
> >>> + return NULL;
> >>> +}
> >>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> >>> b88c881..9b1ffa4 100644
> >>> --- a/lib/bbdev/rte_bbdev.h
> >>> +++ b/lib/bbdev/rte_bbdev.h
> >>> @@ -223,6 +223,21 @@ struct rte_bbdev_queue_conf {
> >>> int
> >>> rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id);
> >>>
> >>> +/**
> >>> + * Flags indicate the status of the device */ enum
> >>> +rte_bbdev_device_status {
> >>> + RTE_BBDEV_DEV_NOSTATUS, /**< Nothing being reported */
> >>> + RTE_BBDEV_DEV_NOT_SUPPORTED, /**< Device status is not
> >> supported on the PMD */
> >> If this was 0, you may not need to explicitly set.
> > This helps to have the lack of status being equivalent to a cleared register.
>
> NOSTATUS is fine, just change
>
> NOT_SUPPORTED = 0,
Let me rephrase. Currently RTE_BBDEV_DEV_NOSTATUS is zero explicitly which can be valuable to match a clear register.
RTE_BBDEV_DEV_NOT_SUPPORTED would not be zero.
Are you suggesting I should put explictly a RTE_BBDEV_DEV_NOSTATUS = 0? Isn't it implicit for any compiler that the first enum starts from zero?
>
> Tom
>
> >
> >>> + RTE_BBDEV_DEV_RESET, /**< Device in reset and un-configured
> >> state */
> >>> + RTE_BBDEV_DEV_CONFIGURED, /**< Device is configured and
> >> ready to use */
> >>> + RTE_BBDEV_DEV_ACTIVE, /**< Device is configured and VF is
> >> being used */
> >>> + RTE_BBDEV_DEV_FATAL_ERR, /**< Device has hit a fatal
> >> uncorrectable error */
> >>> + RTE_BBDEV_DEV_RESTART_REQ, /**< Device requires application to
> >> restart */
> >>> + RTE_BBDEV_DEV_RECONFIG_REQ, /**< Device requires application
> >> to reconfigure queues */
> >>> + RTE_BBDEV_DEV_CORRECT_ERR, /**< Warning of a correctable
> >> error event happened */
> >> Last patch was padded, do something consistent here.
> > We only pad if we have to. Here there is no array whose size would be
> dimensioned by the size of that enum.
> >
> >>> +};
> >>> +
> >>> /** Device statistics. */
> >>> struct rte_bbdev_stats {
> >>> uint64_t enqueued_count; /**< Count of all operations enqueued
> >>> */ @@ -285,12 +300,14 @@ struct rte_bbdev_driver_info {
> >>> /** Set if device supports per-queue interrupts */
> >>> bool queue_intr_supported;
> >>> /** Minimum alignment of buffers, in bytes */
> >>> - uint16_t min_alignment;
> >>> - /** HARQ memory available in kB */
> >>> + /** Device Status */
> >>> + enum rte_bbdev_device_status device_status;
> >> New elements should be added to the end to improve backward
> compatibility.
> > Same comment in different patch. I would like to know if there is a real
> recommendation from DPDK on this. I have heard opposite view as well.
> > In that very case we are breaking the ABI in that new serie for 22.11 (sizes
> and offsets are changing).
> >
> >> Tom
> >>
> >>> uint32_t harq_buffer_size;
> >>> /** Byte endianness (RTE_BIG_ENDIAN/RTE_LITTLE_ENDIAN)
> >> supported
> >>> * for input/output data
> >>> */
> >>> + uint16_t min_alignment;
> >>> + /** HARQ memory available in kB */
> >>> uint8_t data_endianness;
> >>> /** Default queue configuration used if none is supplied */
> >>> struct rte_bbdev_queue_conf default_queue_conf; @@ -827,6
> >> +844,20
> >>> @@ typedef void (*rte_bbdev_cb_fn)(uint16_t dev_id,
> >>> rte_bbdev_queue_intr_ctl(uint16_t dev_id, uint16_t queue_id, int
> >>> epfd, int
> >> op,
> >>> void *data);
> >>>
> >>> +/**
> >>> + * Converts device status from enum to string
> >>> + *
> >>> + * @param status
> >>> + * Device status as enum
> >>> + *
> >>> + * @returns
> >>> + * Operation type as string or NULL if op_type is invalid
> >>> + *
> >>> + */
> >>> +__rte_experimental
> >>> +const char*
> >>> +rte_bbdev_device_status_str(enum rte_bbdev_device_status status);
> >>> +
> >>> #ifdef __cplusplus
> >>> }
> >>> #endif
> >>> diff --git a/lib/bbdev/version.map b/lib/bbdev/version.map index
> >>> cce3f3c..9ac3643 100644
> >>> --- a/lib/bbdev/version.map
> >>> +++ b/lib/bbdev/version.map
> >>> @@ -39,3 +39,9 @@ DPDK_22 {
> >>>
> >>> local: *;
> >>> };
> >>> +
> >>> +EXPERIMENTAL {
> >>> + global:
> >>> +
> >>> + rte_bbdev_device_status_str;
> >>> +};
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4 3/7] bbdev: add device info on queue topology
2022-07-07 13:34 0% ` Tom Rix
@ 2022-07-07 17:13 3% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-07-07 17:13 UTC (permalink / raw)
To: Tom Rix, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
Hi Tom,
> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Sent: Thursday, July 7, 2022 6:34 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; gakhil@marvell.com; hemant.agrawal@nxp.com
> Cc: maxime.coquelin@redhat.com; mdr@ashroe.eu; Richardson, Bruce
> <bruce.richardson@intel.com>; david.marchand@redhat.com;
> stephen@networkplumber.org
> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
>
>
> On 7/6/22 2:12 PM, Chautru, Nicolas wrote:
> > Hi Tom,
> >
> >> -----Original Message-----
> >> From: Tom Rix <trix@redhat.com>
> >> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
> >>
> >>
> >> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> >>> Adding more options in the API to expose the number of queues
> >>> exposed and related priority.
> >>>
> >>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> >>> ---
> >>> lib/bbdev/rte_bbdev.h | 4 ++++
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> >>> 9b1ffa4..ac941d6 100644
> >>> --- a/lib/bbdev/rte_bbdev.h
> >>> +++ b/lib/bbdev/rte_bbdev.h
> >>> @@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
> >>>
> >>> /** Maximum number of queues supported by the device */
> >>> unsigned int max_num_queues;
> >>> + /** Maximum number of queues supported per operation type */
> >>> + unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> >>> + /** Priority level supported per operation type */
> >>> + unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> >> It is better to add new elements to the end of a structure for better
> >> backward compatibility
> > All that serie is not ABI compatible (sizes change etc...). I don’t believe there
> is such a recommendation, is there?
>
> Depends on what users expect, a dynamically linked old application would at
> best core here. If the elements were added to the end, yes the size would
> change but the old dynamically linked application would not use
> them. Dynamically linking is nice because problems in the library can be fixed
> and shipped without forcing the user recompile. Though the user may not
> realize it, this change forces them to recompile.
>
> Tom
Thanks Tom. In that very context, the change are big enough not to have any form of compatibility. This a new ABI version, and user knows they will have to recompile.
Still it would be great to capture a recommendation in DPDK coding guideline in case there is such a BKM, I have heard multiple arguments for different preference, if we want to harmonize such things let's capture in coding guide lines, it would not hurt. Maybe one for Thomas?
>
> >
> >> Tom
> >>
> >>> /** Queue size limit (queue size must also be power of 2) */
> >>> uint32_t queue_size_lim;
> >>> /** Set if device off-loads operation to hardware */
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 2/7] bbdev: add device status info
2022-07-06 21:16 3% ` Chautru, Nicolas
@ 2022-07-07 13:37 0% ` Tom Rix
2022-07-07 17:15 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Tom Rix @ 2022-07-07 13:37 UTC (permalink / raw)
To: Chautru, Nicolas, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
On 7/6/22 2:16 PM, Chautru, Nicolas wrote:
>> -----Original Message-----
>> From: Tom Rix <trix@redhat.com>
>> Subject: Re: [PATCH v4 2/7] bbdev: add device status info
>>
>>
>> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
>>> Added device status information, so that the PMD can expose
>>> information related to the underlying accelerator device status.
>>> Minor order change in structure to fit into padding hole.
>>>
>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>>> ---
>>> drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
>>> drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
>>> drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
>>> drivers/baseband/la12xx/bbdev_la12xx.c | 1 +
>>> drivers/baseband/null/bbdev_null.c | 1 +
>>> drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
>>> lib/bbdev/rte_bbdev.c | 24 +++++++++++++++
>>> lib/bbdev/rte_bbdev.h | 35 ++++++++++++++++++++--
>>> lib/bbdev/version.map | 6 ++++
>>> 9 files changed, 69 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> index de7e4bc..17ba798 100644
>>> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
>>> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
>>> @@ -1060,6 +1060,7 @@
>>>
>>> /* Read and save the populated config from ACC100 registers */
>>> fetch_acc100_config(dev);
>>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
>>>
>>> /* This isn't ideal because it reports the maximum number of queues
>> but
>>> * does not provide info on how many can be uplink/downlink or
>>> different diff --git
>>> a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>>> b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>>> index 82ae6ba..57b12af 100644
>>> --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>>> +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
>>> @@ -369,6 +369,7 @@
>>> dev_info->capabilities = bbdev_capabilities;
>>> dev_info->cpu_flag_reqs = NULL;
>>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
>>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
>>>
>>> /* Calculates number of queues assigned to device */
>>> dev_info->max_num_queues = 0;
>>> diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
>>> b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
>>> index 21d3529..2a330c4 100644
>>> --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
>>> +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
>>> @@ -645,6 +645,7 @@ struct __rte_cache_aligned fpga_queue {
>>> dev_info->capabilities = bbdev_capabilities;
>>> dev_info->cpu_flag_reqs = NULL;
>>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
>>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
>>>
>>> /* Calculates number of queues assigned to device */
>>> dev_info->max_num_queues = 0;
>>> diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
>>> b/drivers/baseband/la12xx/bbdev_la12xx.c
>>> index 4d1bd16..c1f88c6 100644
>>> --- a/drivers/baseband/la12xx/bbdev_la12xx.c
>>> +++ b/drivers/baseband/la12xx/bbdev_la12xx.c
>>> @@ -100,6 +100,7 @@ struct bbdev_la12xx_params {
>>> dev_info->capabilities = bbdev_capabilities;
>>> dev_info->cpu_flag_reqs = NULL;
>>> dev_info->min_alignment = 64;
>>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
>>>
>>> rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
>>> }
>>> diff --git a/drivers/baseband/null/bbdev_null.c
>>> b/drivers/baseband/null/bbdev_null.c
>>> index 248e129..94a1976 100644
>>> --- a/drivers/baseband/null/bbdev_null.c
>>> +++ b/drivers/baseband/null/bbdev_null.c
>>> @@ -82,6 +82,7 @@ struct bbdev_queue {
>>> * here for code completeness.
>>> */
>>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
>>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
>>>
>>> rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
>>> }
>>> diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
>>> b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
>>> index af7bc41..dbc5524 100644
>>> --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
>>> +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
>>> @@ -254,6 +254,7 @@ struct turbo_sw_queue {
>>> dev_info->min_alignment = 64;
>>> dev_info->harq_buffer_size = 0;
>>> dev_info->data_endianness = RTE_LITTLE_ENDIAN;
>>> + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
>>>
>>> rte_bbdev_log_debug("got device info from %u\n", dev->data-
>>> dev_id);
>>> }
>>> diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
>>> 22bd894..555bda9 100644
>>> --- a/lib/bbdev/rte_bbdev.c
>>> +++ b/lib/bbdev/rte_bbdev.c
>>> @@ -25,6 +25,8 @@
>>>
>>> /* Number of supported operation types */
>>> #define BBDEV_OP_TYPE_COUNT 5
>>> +/* Number of supported device status */ #define
>>> +BBDEV_DEV_STATUS_COUNT 9
>>>
>>> /* BBDev library logging ID */
>>> RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE); @@ -1132,3
>> +1134,25
>>> @@ struct rte_mempool *
>>> rte_bbdev_log(ERR, "Invalid operation type");
>>> return NULL;
>>> }
>>> +
>>> +const char *
>>> +rte_bbdev_device_status_str(enum rte_bbdev_device_status status) {
>>> + static const char * const dev_sta_string[] = {
>>> + "RTE_BBDEV_DEV_NOSTATUS",
>>> + "RTE_BBDEV_DEV_NOT_SUPPORTED",
>>> + "RTE_BBDEV_DEV_RESET",
>>> + "RTE_BBDEV_DEV_CONFIGURED",
>>> + "RTE_BBDEV_DEV_ACTIVE",
>>> + "RTE_BBDEV_DEV_FATAL_ERR",
>>> + "RTE_BBDEV_DEV_RESTART_REQ",
>>> + "RTE_BBDEV_DEV_RECONFIG_REQ",
>>> + "RTE_BBDEV_DEV_CORRECT_ERR",
>>> + };
>>> +
>>> + if (status < BBDEV_DEV_STATUS_COUNT)
>>> + return dev_sta_string[status];
>>> +
>>> + rte_bbdev_log(ERR, "Invalid device status");
>>> + return NULL;
>>> +}
>>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
>>> b88c881..9b1ffa4 100644
>>> --- a/lib/bbdev/rte_bbdev.h
>>> +++ b/lib/bbdev/rte_bbdev.h
>>> @@ -223,6 +223,21 @@ struct rte_bbdev_queue_conf {
>>> int
>>> rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id);
>>>
>>> +/**
>>> + * Flags indicate the status of the device */ enum
>>> +rte_bbdev_device_status {
>>> + RTE_BBDEV_DEV_NOSTATUS, /**< Nothing being reported */
>>> + RTE_BBDEV_DEV_NOT_SUPPORTED, /**< Device status is not
>> supported on the PMD */
>> If this was 0, you may not need to explicitly set.
> This helps to have the lack of status being equivalent to a cleared register.
NOSTATUS is fine, just change
NOT_SUPPORTED = 0,
Tom
>
>>> + RTE_BBDEV_DEV_RESET, /**< Device in reset and un-configured
>> state */
>>> + RTE_BBDEV_DEV_CONFIGURED, /**< Device is configured and
>> ready to use */
>>> + RTE_BBDEV_DEV_ACTIVE, /**< Device is configured and VF is
>> being used */
>>> + RTE_BBDEV_DEV_FATAL_ERR, /**< Device has hit a fatal
>> uncorrectable error */
>>> + RTE_BBDEV_DEV_RESTART_REQ, /**< Device requires application to
>> restart */
>>> + RTE_BBDEV_DEV_RECONFIG_REQ, /**< Device requires application
>> to reconfigure queues */
>>> + RTE_BBDEV_DEV_CORRECT_ERR, /**< Warning of a correctable
>> error event happened */
>> Last patch was padded, do something consistent here.
> We only pad if we have to. Here there is no array whose size would be dimensioned by the size of that enum.
>
>>> +};
>>> +
>>> /** Device statistics. */
>>> struct rte_bbdev_stats {
>>> uint64_t enqueued_count; /**< Count of all operations enqueued */
>>> @@ -285,12 +300,14 @@ struct rte_bbdev_driver_info {
>>> /** Set if device supports per-queue interrupts */
>>> bool queue_intr_supported;
>>> /** Minimum alignment of buffers, in bytes */
>>> - uint16_t min_alignment;
>>> - /** HARQ memory available in kB */
>>> + /** Device Status */
>>> + enum rte_bbdev_device_status device_status;
>> New elements should be added to the end to improve backward compatibility.
> Same comment in different patch. I would like to know if there is a real recommendation from DPDK on this. I have heard opposite view as well.
> In that very case we are breaking the ABI in that new serie for 22.11 (sizes and offsets are changing).
>
>> Tom
>>
>>> uint32_t harq_buffer_size;
>>> /** Byte endianness (RTE_BIG_ENDIAN/RTE_LITTLE_ENDIAN)
>> supported
>>> * for input/output data
>>> */
>>> + uint16_t min_alignment;
>>> + /** HARQ memory available in kB */
>>> uint8_t data_endianness;
>>> /** Default queue configuration used if none is supplied */
>>> struct rte_bbdev_queue_conf default_queue_conf; @@ -827,6
>> +844,20
>>> @@ typedef void (*rte_bbdev_cb_fn)(uint16_t dev_id,
>>> rte_bbdev_queue_intr_ctl(uint16_t dev_id, uint16_t queue_id, int epfd, int
>> op,
>>> void *data);
>>>
>>> +/**
>>> + * Converts device status from enum to string
>>> + *
>>> + * @param status
>>> + * Device status as enum
>>> + *
>>> + * @returns
>>> + * Operation type as string or NULL if op_type is invalid
>>> + *
>>> + */
>>> +__rte_experimental
>>> +const char*
>>> +rte_bbdev_device_status_str(enum rte_bbdev_device_status status);
>>> +
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>> diff --git a/lib/bbdev/version.map b/lib/bbdev/version.map index
>>> cce3f3c..9ac3643 100644
>>> --- a/lib/bbdev/version.map
>>> +++ b/lib/bbdev/version.map
>>> @@ -39,3 +39,9 @@ DPDK_22 {
>>>
>>> local: *;
>>> };
>>> +
>>> +EXPERIMENTAL {
>>> + global:
>>> +
>>> + rte_bbdev_device_status_str;
>>> +};
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 3/7] bbdev: add device info on queue topology
2022-07-06 21:12 3% ` Chautru, Nicolas
@ 2022-07-07 13:34 0% ` Tom Rix
2022-07-07 17:13 3% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Tom Rix @ 2022-07-07 13:34 UTC (permalink / raw)
To: Chautru, Nicolas, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
On 7/6/22 2:12 PM, Chautru, Nicolas wrote:
> Hi Tom,
>
>> -----Original Message-----
>> From: Tom Rix <trix@redhat.com>
>> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
>>
>>
>> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
>>> Adding more options in the API to expose the number of queues exposed
>>> and related priority.
>>>
>>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>>> ---
>>> lib/bbdev/rte_bbdev.h | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
>>> 9b1ffa4..ac941d6 100644
>>> --- a/lib/bbdev/rte_bbdev.h
>>> +++ b/lib/bbdev/rte_bbdev.h
>>> @@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
>>>
>>> /** Maximum number of queues supported by the device */
>>> unsigned int max_num_queues;
>>> + /** Maximum number of queues supported per operation type */
>>> + unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
>>> + /** Priority level supported per operation type */
>>> + unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
>> It is better to add new elements to the end of a structure for better backward
>> compatibility
> All that serie is not ABI compatible (sizes change etc...). I don’t believe there is such a recommendation, is there?
Depends on what users expect, a dynamically linked old application would
at best core here. If the elements were added to the end, yes the size
would change but the old dynamically linked application would not use
them. Dynamically linking is nice because problems in the library can
be fixed and shipped without forcing the user recompile. Though the
user may not realize it, this change forces them to recompile.
Tom
>
>> Tom
>>
>>> /** Queue size limit (queue size must also be power of 2) */
>>> uint32_t queue_size_lim;
>>> /** Set if device off-loads operation to hardware */
^ permalink raw reply [relevance 0%]
* RE: [PATCH v8] sched: enable CMAN at runtime
2022-07-06 8:53 0% ` Singh, Jasvinder
@ 2022-07-07 13:07 0% ` Danilewicz, MarcinX
0 siblings, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-07-07 13:07 UTC (permalink / raw)
To: Singh, Jasvinder, dev, Dumitrescu, Cristian; +Cc: Ajmera, Megha
<snip>
> > Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> > ---
> > Log: v2 change in rte_sched.h to avoid ABI breakage.
> > v3 changes from comments
> > v4 rebase to 22.07-rc1
> > v5 rebase to main latest
> > v6 commit message fixed
> > v7 changes from comments
> > v8 with changes from comments
>
>
> You need to explicitly mention the changes done in each version to help
> reviewer easily locate the changes.
Yes, yes. I am going to provide more detailed changes and explaining history on what changes was made. This split development over time is the best example to show that need.
<snip>
>>@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params
> > subport_params_default = {
> > .pipe_profiles = pipe_profile,
> > .n_pipe_profiles = 0, /* filled at run time */
> > .n_max_pipe_profiles = RTE_DIM(pipe_profile), -#ifdef
> RTE_SCHED_CMAN
> > .cman_params = &cman_params,
> > -#endif /* RTE_SCHED_CMAN */
> > };
>
>
> Similar to what is discussed for qos_sched sample app, set cman_params to
> NULL and remove default parameters for "static struct
> rte_sched_cman_params cman_params" above.
Sure, that will be done.
> > -#ifdef RTE_SCHED_CMAN
> > - struct rte_sched_cman_params cman_params = {
> > - .cman_mode = RTE_SCHED_CMAN_RED,
> > - .red_params = { },
> > - };
> > + subport_params->cman_params = NULL;
>
> No need to set subport_params->cman_params again to null as it is already
> set to NULL in init.c.
Sure, app_load_cfg_profile -> cfg_load_subport is also not called several times, just once
<snip>
> > }
> > -#ifdef RTE_SCHED_CMAN
> > - set_subport_cman_params(subport_params+i,
> > cman_params);
> > -#endif
> > + subport_params[i].cman_params = &cman_params;
>
> Since cman_params_is global variable, memory is allocated regardless of
> whether cman mechanism is enabled or disabled. So subport_params-
> >cman_params will never point to NULL even when red/pie is disabled.
> Define local flag "cman_enabled" and set his flag if red or pie is enabled and
> check this flag to set subport_params[i].cman_params to cman_params.
Ah .. nice spot. But, cant we do that with additional check, using what we have?
For an instance:
If (cman_params.cman_mode == RTE_SCHED_CMAN_PIE || cman_params.cman_mode == RTE_SCHED_CMAN_RED) {
Then set subport_params[i].cman_params to cman_params.
}
BR,
/Marcin
^ permalink raw reply [relevance 0%]
* [PATCH v5 1/7] bbdev: allow operation type enum for growth
2022-07-06 23:28 4% ` [PATCH v5 0/7] bbdev changes for 22.11 Nicolas Chautru
@ 2022-07-06 23:28 3% ` Nicolas Chautru
0 siblings, 0 replies; 200+ results
From: Nicolas Chautru @ 2022-07-06 23:28 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Updating the enum for rte_bbdev_op_type
to allow to keep ABI compatible for enum insertion
while adding padded maximum value for array need.
Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
RTE_BBDEV_OP_TYPE_PADDED_MAX.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 ++--
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 8 +++++---
lib/bbdev/rte_bbdev_op.h | 2 +-
5 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index ac06d73..1063f6e 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
rte_mempool_free(mp);
TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
- RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
+ RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) == NULL,
"Failed test for rte_bbdev_op_pool_create: "
"returned value is not NULL for invalid type");
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index fad3b1e..1abda2d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device *ad,
/* Find capabilities */
const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
- for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
+ do {
if (cap->type == test_vector.op_type) {
capabilities = cap;
break;
}
cap++;
- }
+ } while (cap->type != RTE_BBDEV_OP_NONE);
TEST_ASSERT_NOT_NULL(capabilities,
"Couldn't find capabilities");
diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fc7e8b8..ef0ba76 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
void *sigret;
struct app_config_params app_params = def_app_config;
struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
- struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
+ struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
struct stats_lcore_params stats_lcore;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index aaee7b7..4da8047 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -23,6 +23,8 @@
#define DEV_NAME "BBDEV"
+/* Number of supported operation types */
+#define BBDEV_OP_TYPE_COUNT 5
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -890,10 +892,10 @@ struct rte_mempool *
return NULL;
}
- if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
+ if (type >= BBDEV_OP_TYPE_COUNT) {
rte_bbdev_log(ERR,
"Invalid op type (%u), should be less than %u",
- type, RTE_BBDEV_OP_TYPE_COUNT);
+ type, BBDEV_OP_TYPE_COUNT);
return NULL;
}
@@ -1125,7 +1127,7 @@ struct rte_mempool *
"RTE_BBDEV_OP_LDPC_ENC",
};
- if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
+ if (op_type < BBDEV_OP_TYPE_COUNT)
return op_types[op_type];
rte_bbdev_log(ERR, "Invalid operation type");
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 6d56133..cd82418 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
- RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
+ RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number including padding */
};
/** Bit indexes of possible errors reported through status field */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v5 0/7] bbdev changes for 22.11
2022-06-28 1:35 4% ` [PATCH v3 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-07-06 0:23 4% ` [PATCH v4 0/7] bbdev changes for 22.11 Nicolas Chautru
@ 2022-07-06 23:28 4% ` Nicolas Chautru
2022-07-06 23:28 3% ` [PATCH v5 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-07-06 23:28 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
v5: update base on review from Tom Rix. Number of typos reported and resolved,
removed the commit related to rw_lock for now, added a commit for
code clean up from review, resolved one rebase issue between 2 commits, used size of array for some bound check implementation. Thanks.
v4: update to the last 2 commits to include function to print the queue status and a fix to the rte_lock within the wrong structure
v3: update to device status info to also use padded size for the related array.
Adding also 2 additionals commits to allow the API struc to expose more information related to queues corner cases/warning as well as an optional rw lock.
Hemant, Maxime, this is planned for DPDK 21.11 but would like review/ack early is possible to get this applied earlier and due to time off this summer.
Thanks
Nic
--
Hi,
Agregating together in a single serie a number of bbdev api changes previously submitted over the last few months and all targeted for 22.11 (4 different series detailed below). Related deprecation notice being pushed in 22.07 in parallel.
* bbdev: add device status info
* bbdev: add new operation for FFT processing
* bbdev: add device info on queue topology
* bbdev: allow operation type enum for growth
v2: Update to the RTE_BBDEV_COUNT removal based on feedback from Thomas/Stephen : rejecting out of range op type and adjusting the new name for the padded maximum value used for fixed size arrays.
---
Previous cover letters agregated below:
* bbdev: add device status info
https://patches.dpdk.org/project/dpdk/list/?series=23367
The updated structure will allow PMDs to expose through info_get what be may the status of the underlying accelerator, notably in case an HW error event having happened.
* bbdev: add new operation for FFT processing
https://patches.dpdk.org/project/dpdk/list/?series=22111
This contribution adds a new operation type to the existing ones already supported by the bbdev PMDs.
This set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental).
I plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test.
* bbdev: add device info on queue topology
https://patches.dpdk.org/project/dpdk/list/?series=22076
Addressing an historical concern that the device info struct only imperfectly captured what queues are available on the device (number of operation and priority). This ended up being an iterative process for application to find each queue could be configured.
ie. the gap was captured as technical debt previously in comments
/* This isn't ideal because it reports the maximum number of queues but
* does not provide info on how many can be uplink/downlink or different
* priorities
*/
This is now being exposed explictly based on the what the device actually supports using the existing info_get api
* bbdev: allow operation type enum for growth
https://patches.dpdk.org/project/dpdk/list/?series=23509
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Nicolas Chautru (7):
bbdev: allow operation type enum for growth
bbdev: add device status info
bbdev: add device info on queue topology
drivers/baseband: update PMDs to expose queue per operation
bbdev: add new operation for FFT processing
bbdev: add queue related warning and status information
bbdev: remove unnecessary if-check
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 6 +-
doc/guides/prog_guide/bbdev.rst | 130 +++++++++++++++++
drivers/baseband/acc100/rte_acc100_pmd.c | 30 ++--
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 9 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 9 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 10 +-
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 12 ++
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 57 +++++++-
lib/bbdev/rte_bbdev.h | 149 +++++++++++++++++++-
lib/bbdev/rte_bbdev_op.h | 156 ++++++++++++++++++++-
lib/bbdev/version.map | 11 ++
14 files changed, 555 insertions(+), 29 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* RE: [PATCH v4 1/7] bbdev: allow operation type enum for growth
2022-07-06 12:50 0% ` Tom Rix
@ 2022-07-06 21:20 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-07-06 21:20 UTC (permalink / raw)
To: Tom Rix, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
Hi Tom,
> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Subject: Re: [PATCH v4 1/7] bbdev: allow operation type enum for growth
>
>
> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> > Updating the enum for rte_bbdev_op_type to allow to keep ABI
> > compatible for enum insertion while adding padded maximum value for
> > array need.
> > Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
> > RTE_BBDEV_OP_TYPE_PADDED_MAX.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> > app/test-bbdev/test_bbdev.c | 2 +-
> > app/test-bbdev/test_bbdev_perf.c | 4 ++--
> > examples/bbdev_app/main.c | 2 +-
> > lib/bbdev/rte_bbdev.c | 9 +++++----
> > lib/bbdev/rte_bbdev_op.h | 2 +-
> > 5 files changed, 10 insertions(+), 9 deletions(-)
> >
> > diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
> > index ac06d73..1063f6e 100644
> > --- a/app/test-bbdev/test_bbdev.c
> > +++ b/app/test-bbdev/test_bbdev.c
> > @@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
> > rte_mempool_free(mp);
> >
> > TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
> > - RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) ==
> NULL,
> > + RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size,
> 0)) == NULL,
> > "Failed test for rte_bbdev_op_pool_create: "
> > "returned value is not NULL for invalid type");
> >
> > diff --git a/app/test-bbdev/test_bbdev_perf.c
> > b/app/test-bbdev/test_bbdev_perf.c
> > index fad3b1e..1abda2d 100644
> > --- a/app/test-bbdev/test_bbdev_perf.c
> > +++ b/app/test-bbdev/test_bbdev_perf.c
> > @@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct
> > active_device *ad,
> >
> > /* Find capabilities */
> > const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
> > - for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
> > + do {
> > if (cap->type == test_vector.op_type) {
> > capabilities = cap;
> > break;
> > }
> > cap++;
> > - }
> > + } while (cap->type != RTE_BBDEV_OP_NONE);
> > TEST_ASSERT_NOT_NULL(capabilities,
> > "Couldn't find capabilities");
> >
> > diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
> > index fc7e8b8..ef0ba76 100644
> > --- a/examples/bbdev_app/main.c
> > +++ b/examples/bbdev_app/main.c
> > @@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
> > void *sigret;
> > struct app_config_params app_params = def_app_config;
> > struct rte_mempool *ethdev_mbuf_mempool,
> *bbdev_mbuf_mempool;
> > - struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
> > + struct rte_mempool
> *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> > struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
> > struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
> > struct stats_lcore_params stats_lcore; diff --git
> > a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index aaee7b7..22bd894
> > 100644
> > --- a/lib/bbdev/rte_bbdev.c
> > +++ b/lib/bbdev/rte_bbdev.c
> > @@ -23,6 +23,8 @@
> >
> > #define DEV_NAME "BBDEV"
> >
> > +/* Number of supported operation types */ #define
> BBDEV_OP_TYPE_COUNT
> > +5
> >
> > /* BBDev library logging ID */
> > RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE); @@ -890,10
> +892,10
> > @@ struct rte_mempool *
> > return NULL;
> > }
> >
> > - if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
> > + if (type >= BBDEV_OP_TYPE_COUNT) {
> > rte_bbdev_log(ERR,
> > "Invalid op type (%u), should be less than %u",
> > - type, RTE_BBDEV_OP_TYPE_COUNT);
> > + type, BBDEV_OP_TYPE_COUNT);
> > return NULL;
> > }
> >
> > @@ -1122,10 +1124,9 @@ struct rte_mempool *
> > "RTE_BBDEV_OP_TURBO_DEC",
> > "RTE_BBDEV_OP_TURBO_ENC",
> > "RTE_BBDEV_OP_LDPC_DEC",
> > - "RTE_BBDEV_OP_LDPC_ENC",
> > };
> >
> > - if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
> > + if (op_type < BBDEV_OP_TYPE_COUNT)
> > return op_types[op_type];
> >
> > rte_bbdev_log(ERR, "Invalid operation type"); diff --git
> > a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h index
> > 6d56133..cd82418 100644
> > --- a/lib/bbdev/rte_bbdev_op.h
> > +++ b/lib/bbdev/rte_bbdev_op.h
> > @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
> > RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
> > RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
> > RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
> > - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
>
> Why not keep this enum so you don't have to make the
> BBDEV_OP_TYPE_COUNT #define ?
We are announcing that we are deprecating that enum. We want to make sure this is not being used by application, only the PADDED one should be used moving forward
But I think I will use your suggestion in other commit not to use #define for this and instead just check for array size.
Thanks
Nic
>
> Tom
>
> > + RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type
> number
> > +including padding */
> > };
> >
> > /** Bit indexes of possible errors reported through status field */
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4 2/7] bbdev: add device status info
@ 2022-07-06 21:16 3% ` Chautru, Nicolas
2022-07-07 13:37 0% ` Tom Rix
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2022-07-06 21:16 UTC (permalink / raw)
To: Tom Rix, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Subject: Re: [PATCH v4 2/7] bbdev: add device status info
>
>
> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> > Added device status information, so that the PMD can expose
> > information related to the underlying accelerator device status.
> > Minor order change in structure to fit into padding hole.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> > drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
> > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
> > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
> > drivers/baseband/la12xx/bbdev_la12xx.c | 1 +
> > drivers/baseband/null/bbdev_null.c | 1 +
> > drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
> > lib/bbdev/rte_bbdev.c | 24 +++++++++++++++
> > lib/bbdev/rte_bbdev.h | 35 ++++++++++++++++++++--
> > lib/bbdev/version.map | 6 ++++
> > 9 files changed, 69 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > index de7e4bc..17ba798 100644
> > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > @@ -1060,6 +1060,7 @@
> >
> > /* Read and save the populated config from ACC100 registers */
> > fetch_acc100_config(dev);
> > + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >
> > /* This isn't ideal because it reports the maximum number of queues
> but
> > * does not provide info on how many can be uplink/downlink or
> > different diff --git
> > a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > index 82ae6ba..57b12af 100644
> > --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > @@ -369,6 +369,7 @@
> > dev_info->capabilities = bbdev_capabilities;
> > dev_info->cpu_flag_reqs = NULL;
> > dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> > + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >
> > /* Calculates number of queues assigned to device */
> > dev_info->max_num_queues = 0;
> > diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > index 21d3529..2a330c4 100644
> > --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > @@ -645,6 +645,7 @@ struct __rte_cache_aligned fpga_queue {
> > dev_info->capabilities = bbdev_capabilities;
> > dev_info->cpu_flag_reqs = NULL;
> > dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> > + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >
> > /* Calculates number of queues assigned to device */
> > dev_info->max_num_queues = 0;
> > diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c
> > b/drivers/baseband/la12xx/bbdev_la12xx.c
> > index 4d1bd16..c1f88c6 100644
> > --- a/drivers/baseband/la12xx/bbdev_la12xx.c
> > +++ b/drivers/baseband/la12xx/bbdev_la12xx.c
> > @@ -100,6 +100,7 @@ struct bbdev_la12xx_params {
> > dev_info->capabilities = bbdev_capabilities;
> > dev_info->cpu_flag_reqs = NULL;
> > dev_info->min_alignment = 64;
> > + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >
> > rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
> > }
> > diff --git a/drivers/baseband/null/bbdev_null.c
> > b/drivers/baseband/null/bbdev_null.c
> > index 248e129..94a1976 100644
> > --- a/drivers/baseband/null/bbdev_null.c
> > +++ b/drivers/baseband/null/bbdev_null.c
> > @@ -82,6 +82,7 @@ struct bbdev_queue {
> > * here for code completeness.
> > */
> > dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> > + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >
> > rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
> > }
> > diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > index af7bc41..dbc5524 100644
> > --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > @@ -254,6 +254,7 @@ struct turbo_sw_queue {
> > dev_info->min_alignment = 64;
> > dev_info->harq_buffer_size = 0;
> > dev_info->data_endianness = RTE_LITTLE_ENDIAN;
> > + dev_info->device_status = RTE_BBDEV_DEV_NOT_SUPPORTED;
> >
> > rte_bbdev_log_debug("got device info from %u\n", dev->data-
> >dev_id);
> > }
> > diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
> > 22bd894..555bda9 100644
> > --- a/lib/bbdev/rte_bbdev.c
> > +++ b/lib/bbdev/rte_bbdev.c
> > @@ -25,6 +25,8 @@
> >
> > /* Number of supported operation types */
> > #define BBDEV_OP_TYPE_COUNT 5
> > +/* Number of supported device status */ #define
> > +BBDEV_DEV_STATUS_COUNT 9
> >
> > /* BBDev library logging ID */
> > RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE); @@ -1132,3
> +1134,25
> > @@ struct rte_mempool *
> > rte_bbdev_log(ERR, "Invalid operation type");
> > return NULL;
> > }
> > +
> > +const char *
> > +rte_bbdev_device_status_str(enum rte_bbdev_device_status status) {
> > + static const char * const dev_sta_string[] = {
> > + "RTE_BBDEV_DEV_NOSTATUS",
> > + "RTE_BBDEV_DEV_NOT_SUPPORTED",
> > + "RTE_BBDEV_DEV_RESET",
> > + "RTE_BBDEV_DEV_CONFIGURED",
> > + "RTE_BBDEV_DEV_ACTIVE",
> > + "RTE_BBDEV_DEV_FATAL_ERR",
> > + "RTE_BBDEV_DEV_RESTART_REQ",
> > + "RTE_BBDEV_DEV_RECONFIG_REQ",
> > + "RTE_BBDEV_DEV_CORRECT_ERR",
> > + };
> > +
> > + if (status < BBDEV_DEV_STATUS_COUNT)
> > + return dev_sta_string[status];
> > +
> > + rte_bbdev_log(ERR, "Invalid device status");
> > + return NULL;
> > +}
> > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> > b88c881..9b1ffa4 100644
> > --- a/lib/bbdev/rte_bbdev.h
> > +++ b/lib/bbdev/rte_bbdev.h
> > @@ -223,6 +223,21 @@ struct rte_bbdev_queue_conf {
> > int
> > rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id);
> >
> > +/**
> > + * Flags indicate the status of the device */ enum
> > +rte_bbdev_device_status {
> > + RTE_BBDEV_DEV_NOSTATUS, /**< Nothing being reported */
> > + RTE_BBDEV_DEV_NOT_SUPPORTED, /**< Device status is not
> supported on the PMD */
> If this was 0, you may not need to explicitly set.
This helps to have the lack of status being equivalent to a cleared register.
> > + RTE_BBDEV_DEV_RESET, /**< Device in reset and un-configured
> state */
> > + RTE_BBDEV_DEV_CONFIGURED, /**< Device is configured and
> ready to use */
> > + RTE_BBDEV_DEV_ACTIVE, /**< Device is configured and VF is
> being used */
> > + RTE_BBDEV_DEV_FATAL_ERR, /**< Device has hit a fatal
> uncorrectable error */
> > + RTE_BBDEV_DEV_RESTART_REQ, /**< Device requires application to
> restart */
> > + RTE_BBDEV_DEV_RECONFIG_REQ, /**< Device requires application
> to reconfigure queues */
> > + RTE_BBDEV_DEV_CORRECT_ERR, /**< Warning of a correctable
> error event happened */
> Last patch was padded, do something consistent here.
We only pad if we have to. Here there is no array whose size would be dimensioned by the size of that enum.
> > +};
> > +
> > /** Device statistics. */
> > struct rte_bbdev_stats {
> > uint64_t enqueued_count; /**< Count of all operations enqueued */
> > @@ -285,12 +300,14 @@ struct rte_bbdev_driver_info {
> > /** Set if device supports per-queue interrupts */
> > bool queue_intr_supported;
> > /** Minimum alignment of buffers, in bytes */
> > - uint16_t min_alignment;
> > - /** HARQ memory available in kB */
> > + /** Device Status */
> > + enum rte_bbdev_device_status device_status;
>
> New elements should be added to the end to improve backward compatibility.
Same comment in different patch. I would like to know if there is a real recommendation from DPDK on this. I have heard opposite view as well.
In that very case we are breaking the ABI in that new serie for 22.11 (sizes and offsets are changing).
>
> Tom
>
> > uint32_t harq_buffer_size;
> > /** Byte endianness (RTE_BIG_ENDIAN/RTE_LITTLE_ENDIAN)
> supported
> > * for input/output data
> > */
> > + uint16_t min_alignment;
> > + /** HARQ memory available in kB */
> > uint8_t data_endianness;
> > /** Default queue configuration used if none is supplied */
> > struct rte_bbdev_queue_conf default_queue_conf; @@ -827,6
> +844,20
> > @@ typedef void (*rte_bbdev_cb_fn)(uint16_t dev_id,
> > rte_bbdev_queue_intr_ctl(uint16_t dev_id, uint16_t queue_id, int epfd, int
> op,
> > void *data);
> >
> > +/**
> > + * Converts device status from enum to string
> > + *
> > + * @param status
> > + * Device status as enum
> > + *
> > + * @returns
> > + * Operation type as string or NULL if op_type is invalid
> > + *
> > + */
> > +__rte_experimental
> > +const char*
> > +rte_bbdev_device_status_str(enum rte_bbdev_device_status status);
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/bbdev/version.map b/lib/bbdev/version.map index
> > cce3f3c..9ac3643 100644
> > --- a/lib/bbdev/version.map
> > +++ b/lib/bbdev/version.map
> > @@ -39,3 +39,9 @@ DPDK_22 {
> >
> > local: *;
> > };
> > +
> > +EXPERIMENTAL {
> > + global:
> > +
> > + rte_bbdev_device_status_str;
> > +};
^ permalink raw reply [relevance 3%]
* RE: [PATCH v4 3/7] bbdev: add device info on queue topology
@ 2022-07-06 21:12 3% ` Chautru, Nicolas
2022-07-07 13:34 0% ` Tom Rix
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2022-07-06 21:12 UTC (permalink / raw)
To: Tom Rix, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, Richardson, Bruce, david.marchand, stephen
Hi Tom,
> -----Original Message-----
> From: Tom Rix <trix@redhat.com>
> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology
>
>
> On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> > Adding more options in the API to expose the number of queues exposed
> > and related priority.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> > lib/bbdev/rte_bbdev.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> > 9b1ffa4..ac941d6 100644
> > --- a/lib/bbdev/rte_bbdev.h
> > +++ b/lib/bbdev/rte_bbdev.h
> > @@ -289,6 +289,10 @@ struct rte_bbdev_driver_info {
> >
> > /** Maximum number of queues supported by the device */
> > unsigned int max_num_queues;
> > + /** Maximum number of queues supported per operation type */
> > + unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> > + /** Priority level supported per operation type */
> > + unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX];
>
> It is better to add new elements to the end of a structure for better backward
> compatibility
All that serie is not ABI compatible (sizes change etc...). I don’t believe there is such a recommendation, is there?
>
> Tom
>
> > /** Queue size limit (queue size must also be power of 2) */
> > uint32_t queue_size_lim;
> > /** Set if device off-loads operation to hardware */
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 1/7] bbdev: allow operation type enum for growth
2022-07-06 0:23 3% ` [PATCH v4 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
@ 2022-07-06 12:50 0% ` Tom Rix
2022-07-06 21:20 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Tom Rix @ 2022-07-06 12:50 UTC (permalink / raw)
To: Nicolas Chautru, dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, mdr, bruce.richardson, david.marchand, stephen
On 7/5/22 5:23 PM, Nicolas Chautru wrote:
> Updating the enum for rte_bbdev_op_type
> to allow to keep ABI compatible for enum insertion
> while adding padded maximum value for array need.
> Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
> RTE_BBDEV_OP_TYPE_PADDED_MAX.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> app/test-bbdev/test_bbdev.c | 2 +-
> app/test-bbdev/test_bbdev_perf.c | 4 ++--
> examples/bbdev_app/main.c | 2 +-
> lib/bbdev/rte_bbdev.c | 9 +++++----
> lib/bbdev/rte_bbdev_op.h | 2 +-
> 5 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
> index ac06d73..1063f6e 100644
> --- a/app/test-bbdev/test_bbdev.c
> +++ b/app/test-bbdev/test_bbdev.c
> @@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
> rte_mempool_free(mp);
>
> TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
> - RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
> + RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) == NULL,
> "Failed test for rte_bbdev_op_pool_create: "
> "returned value is not NULL for invalid type");
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
> index fad3b1e..1abda2d 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device *ad,
>
> /* Find capabilities */
> const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
> - for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
> + do {
> if (cap->type == test_vector.op_type) {
> capabilities = cap;
> break;
> }
> cap++;
> - }
> + } while (cap->type != RTE_BBDEV_OP_NONE);
> TEST_ASSERT_NOT_NULL(capabilities,
> "Couldn't find capabilities");
>
> diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
> index fc7e8b8..ef0ba76 100644
> --- a/examples/bbdev_app/main.c
> +++ b/examples/bbdev_app/main.c
> @@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
> void *sigret;
> struct app_config_params app_params = def_app_config;
> struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
> - struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
> + struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
> struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
> struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
> struct stats_lcore_params stats_lcore;
> diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
> index aaee7b7..22bd894 100644
> --- a/lib/bbdev/rte_bbdev.c
> +++ b/lib/bbdev/rte_bbdev.c
> @@ -23,6 +23,8 @@
>
> #define DEV_NAME "BBDEV"
>
> +/* Number of supported operation types */
> +#define BBDEV_OP_TYPE_COUNT 5
>
> /* BBDev library logging ID */
> RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
> @@ -890,10 +892,10 @@ struct rte_mempool *
> return NULL;
> }
>
> - if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
> + if (type >= BBDEV_OP_TYPE_COUNT) {
> rte_bbdev_log(ERR,
> "Invalid op type (%u), should be less than %u",
> - type, RTE_BBDEV_OP_TYPE_COUNT);
> + type, BBDEV_OP_TYPE_COUNT);
> return NULL;
> }
>
> @@ -1122,10 +1124,9 @@ struct rte_mempool *
> "RTE_BBDEV_OP_TURBO_DEC",
> "RTE_BBDEV_OP_TURBO_ENC",
> "RTE_BBDEV_OP_LDPC_DEC",
> - "RTE_BBDEV_OP_LDPC_ENC",
> };
>
> - if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
> + if (op_type < BBDEV_OP_TYPE_COUNT)
> return op_types[op_type];
>
> rte_bbdev_log(ERR, "Invalid operation type");
> diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
> index 6d56133..cd82418 100644
> --- a/lib/bbdev/rte_bbdev_op.h
> +++ b/lib/bbdev/rte_bbdev_op.h
> @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
> RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
> RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
> RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
> - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
Why not keep this enum so you don't have to make the BBDEV_OP_TYPE_COUNT
#define ?
Tom
> + RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number including padding */
> };
>
> /** Bit indexes of possible errors reported through status field */
^ permalink raw reply [relevance 0%]
* RE: [PATCH v8] sched: enable CMAN at runtime
2022-07-05 17:05 1% ` [PATCH v8] " Marcin Danilewicz
2022-07-05 18:00 0% ` Ajmera, Megha
@ 2022-07-06 8:53 0% ` Singh, Jasvinder
2022-07-07 13:07 0% ` Danilewicz, MarcinX
2022-07-08 13:14 1% ` [PATCH v9] " Marcin Danilewicz
2 siblings, 1 reply; 200+ results
From: Singh, Jasvinder @ 2022-07-06 8:53 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Dumitrescu, Cristian; +Cc: Ajmera, Megha
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Tuesday, July 5, 2022 6:06 PM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v8] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init from profile configuration
> file.
>
> By default CMAN code is enable but not in use, when there is no RED or PIE
> profile configured.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> Log: v2 change in rte_sched.h to avoid ABI breakage.
> v3 changes from comments
> v4 rebase to 22.07-rc1
> v5 rebase to main latest
> v6 commit message fixed
> v7 changes from comments
> v8 with changes from comments
You need to explicitly mention the changes done in each version to help reviewer easily locate the changes.
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 47 +-------
> examples/qos_sched/cfg_file.h | 5 -
> examples/qos_sched/init.c | 76 +-----------
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 135 +--------------------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 47 +-------
> 11 files changed, 296 insertions(+), 320 deletions(-) create mode 100644
> examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
> diff --git a/config/rte_config.h b/config/rte_config.h index
> 46549cb062..ae56a86394 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -88,9 +88,6 @@
> /* rte_power defines */
> #define RTE_MAX_LCORE_FREQS 64
>
> -/* rte_sched defines */
> -// RTE_SCHED_CMAN is not set
> -
> /* rte_graph defines */
> #define RTE_GRAPH_BURST_SIZE 256
> #define RTE_LIBRTE_GRAPH_STATS 1
> diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c
> b/drivers/net/softnic/rte_eth_softnic_tm.c
> index 6a7766ba1c..3e4bed81e9 100644
> --- a/drivers/net/softnic/rte_eth_softnic_tm.c
> +++ b/drivers/net/softnic/rte_eth_softnic_tm.c
> @@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
> return 0;
> }
>
> -#ifdef RTE_SCHED_CMAN
> -#define WRED_SUPPORTED 1
> -#else
> #define WRED_SUPPORTED 0
> -#endif
>
> #define STATS_MASK_DEFAULT \
> (RTE_TM_STATS_N_PKTS | \
> @@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev,
> uint32_t tc_id)
> return NULL;
> }
>
> -#ifdef RTE_SCHED_CMAN
> -
> static void
> wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id) { @@ -
> 2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t
> subport_id)
> }
> }
>
> -#else
> -
> -#define wred_profiles_set(dev, subport_id)
> -
> -#endif
> -
> static struct tm_shared_shaper *
> tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node
> *tc_node) { diff --git a/examples/ip_pipeline/tmgr.c
> b/examples/ip_pipeline/tmgr.c index b138e885cf..e68e9961be 100644
> --- a/examples/ip_pipeline/tmgr.c
> +++ b/examples/ip_pipeline/tmgr.c
> @@ -17,7 +17,6 @@ static uint32_t n_subport_profiles; static struct
> rte_sched_pipe_params
> pipe_profile[TMGR_PIPE_PROFILE_MAX];
>
> -#ifdef RTE_SCHED_CMAN
> static struct rte_sched_cman_params cman_params = {
> .red_params = {
> /* Traffic Class 0 Colors Green / Yellow / Red */ @@ -86,7
> +85,6 @@ static struct rte_sched_cman_params cman_params = {
> [12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10,
> .wq_log2 = 9},
> },
> };
> -#endif /* RTE_SCHED_CMAN */
>
> static uint32_t n_pipe_profiles;
>
> @@ -96,9 +94,7 @@ static const struct rte_sched_subport_params
> subport_params_default = {
> .pipe_profiles = pipe_profile,
> .n_pipe_profiles = 0, /* filled at run time */
> .n_max_pipe_profiles = RTE_DIM(pipe_profile), -#ifdef
> RTE_SCHED_CMAN
> .cman_params = &cman_params,
> -#endif /* RTE_SCHED_CMAN */
> };
Similar to what is discussed for qos_sched sample app, set cman_params to NULL and remove default parameters for "static struct rte_sched_cman_params cman_params" above.
> static struct tmgr_port_list tmgr_port_list; diff --git
> a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c index
> 450482f07d..7f4114bd56 100644
> --- a/examples/qos_sched/cfg_file.c
> +++ b/examples/qos_sched/cfg_file.c
> @@ -23,6 +23,8 @@
> uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
> uint32_t n_active_queues;
>
> +struct rte_sched_cman_params cman_params;
> +
> int
> cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params
> *port_params) { @@ -229,40 +231,6 @@ cfg_load_subport_profile(struct
> rte_cfgfile *cfg,
> return 0;
> }
>
> -#ifdef RTE_SCHED_CMAN
> -void set_subport_cman_params(struct rte_sched_subport_params
> *subport_p,
> - struct rte_sched_cman_params
> cman_p)
> -{
> - int j, k;
> - subport_p->cman_params->cman_mode = cman_p.cman_mode;
> -
> - for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
> - if (subport_p->cman_params->cman_mode ==
> - RTE_SCHED_CMAN_RED) {
> - for (k = 0; k < RTE_COLORS; k++) {
> - subport_p->cman_params-
> >red_params[j][k].min_th =
> - cman_p.red_params[j][k].min_th;
> - subport_p->cman_params-
> >red_params[j][k].max_th =
> - cman_p.red_params[j][k].max_th;
> - subport_p->cman_params-
> >red_params[j][k].maxp_inv =
> - cman_p.red_params[j][k].maxp_inv;
> - subport_p->cman_params-
> >red_params[j][k].wq_log2 =
> - cman_p.red_params[j][k].wq_log2;
> - }
> - } else {
> - subport_p->cman_params-
> >pie_params[j].qdelay_ref =
> - cman_p.pie_params[j].qdelay_ref;
> - subport_p->cman_params-
> >pie_params[j].dp_update_interval =
> - cman_p.pie_params[j].dp_update_interval;
> - subport_p->cman_params-
> >pie_params[j].max_burst =
> - cman_p.pie_params[j].max_burst;
> - subport_p->cman_params->pie_params[j].tailq_th =
> - cman_p.pie_params[j].tailq_th;
> - }
> - }
> -}
> -#endif
> -
> int
> cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params
> *subport_params) { @@ -276,11 +244,7 @@ cfg_load_subport(struct
> rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
> memset(active_queues, 0, sizeof(active_queues));
> n_active_queues = 0;
>
> -#ifdef RTE_SCHED_CMAN
> - struct rte_sched_cman_params cman_params = {
> - .cman_mode = RTE_SCHED_CMAN_RED,
> - .red_params = { },
> - };
> + subport_params->cman_params = NULL;
No need to set subport_params->cman_params again to null as it is already set to NULL in init.c.
> if (rte_cfgfile_has_section(cfg, "red")) {
> cman_params.cman_mode = RTE_SCHED_CMAN_RED; @@ -
> 387,7 +351,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct
> rte_sched_subport_params *subpo
>
> }
> }
> -#endif /* RTE_SCHED_CMAN */
>
> for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
> char sec_name[CFG_NAME_LEN];
> @@ -465,9 +428,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct
> rte_sched_subport_params *subpo
> }
> }
> }
> -#ifdef RTE_SCHED_CMAN
> - set_subport_cman_params(subport_params+i,
> cman_params);
> -#endif
> + subport_params[i].cman_params = &cman_params;
Since cman_params_is global variable, memory is allocated regardless of whether cman mechanism is enabled or disabled. So subport_params->cman_params will never point to NULL even when red/pie is disabled. Define local flag "cman_enabled" and set his flag if red or pie is enabled and check this flag to set subport_params[i].cman_params to cman_params.
^ permalink raw reply [relevance 0%]
* [PATCH v4 1/7] bbdev: allow operation type enum for growth
2022-07-06 0:23 4% ` [PATCH v4 0/7] bbdev changes for 22.11 Nicolas Chautru
@ 2022-07-06 0:23 3% ` Nicolas Chautru
2022-07-06 12:50 0% ` Tom Rix
2 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-07-06 0:23 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Updating the enum for rte_bbdev_op_type
to allow to keep ABI compatible for enum insertion
while adding padded maximum value for array need.
Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
RTE_BBDEV_OP_TYPE_PADDED_MAX.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 ++--
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 9 +++++----
lib/bbdev/rte_bbdev_op.h | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index ac06d73..1063f6e 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
rte_mempool_free(mp);
TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
- RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
+ RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) == NULL,
"Failed test for rte_bbdev_op_pool_create: "
"returned value is not NULL for invalid type");
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index fad3b1e..1abda2d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device *ad,
/* Find capabilities */
const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
- for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
+ do {
if (cap->type == test_vector.op_type) {
capabilities = cap;
break;
}
cap++;
- }
+ } while (cap->type != RTE_BBDEV_OP_NONE);
TEST_ASSERT_NOT_NULL(capabilities,
"Couldn't find capabilities");
diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fc7e8b8..ef0ba76 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
void *sigret;
struct app_config_params app_params = def_app_config;
struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
- struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
+ struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
struct stats_lcore_params stats_lcore;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index aaee7b7..22bd894 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -23,6 +23,8 @@
#define DEV_NAME "BBDEV"
+/* Number of supported operation types */
+#define BBDEV_OP_TYPE_COUNT 5
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -890,10 +892,10 @@ struct rte_mempool *
return NULL;
}
- if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
+ if (type >= BBDEV_OP_TYPE_COUNT) {
rte_bbdev_log(ERR,
"Invalid op type (%u), should be less than %u",
- type, RTE_BBDEV_OP_TYPE_COUNT);
+ type, BBDEV_OP_TYPE_COUNT);
return NULL;
}
@@ -1122,10 +1124,9 @@ struct rte_mempool *
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
"RTE_BBDEV_OP_LDPC_DEC",
- "RTE_BBDEV_OP_LDPC_ENC",
};
- if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
+ if (op_type < BBDEV_OP_TYPE_COUNT)
return op_types[op_type];
rte_bbdev_log(ERR, "Invalid operation type");
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 6d56133..cd82418 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
- RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
+ RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number including padding */
};
/** Bit indexes of possible errors reported through status field */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v4 0/7] bbdev changes for 22.11
2022-06-28 1:35 4% ` [PATCH v3 0/7] bbdev changes for 22.11 Nicolas Chautru
@ 2022-07-06 0:23 4% ` Nicolas Chautru
2022-07-06 0:23 3% ` [PATCH v4 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
` (2 more replies)
2022-07-06 23:28 4% ` [PATCH v5 0/7] bbdev changes for 22.11 Nicolas Chautru
2 siblings, 3 replies; 200+ results
From: Nicolas Chautru @ 2022-07-06 0:23 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
v4: update to the last 2 commits to include function to print the queue status and a fix to the rte_lock within the wrong structure
v3: update to device status info to also use padded size for the related array.
Adding also 2 additionals commits to allow the API struc to expose more information related to queues corner cases/warning as well as an optional rw lock.
Hemant, Maxime, this is planned for DPDK 21.11 but would like review/ack early is possible to get this applied earlier and due to time off this summer.
Thanks
Nic
--
Hi,
Agregating together in a single serie a number of bbdev api changes previously submitted over the last few months and all targeted for 22.11 (4 different series detailed below). Related deprecation notice being pushed in 22.07 in parallel.
* bbdev: add device status info
* bbdev: add new operation for FFT processing
* bbdev: add device info on queue topology
* bbdev: allow operation type enum for growth
v2: Update to the RTE_BBDEV_COUNT removal based on feedback from Thomas/Stephen : rejecting out of range op type and adjusting the new name for the padded maximum value used for fixed size arrays.
---
Previous cover letters agregated below:
* bbdev: add device status info
https://patches.dpdk.org/project/dpdk/list/?series=23367
The updated structure will allow PMDs to expose through info_get what be may the status of the underlying accelerator, notably in case an HW error event having happened.
* bbdev: add new operation for FFT processing
https://patches.dpdk.org/project/dpdk/list/?series=22111
This contribution adds a new operation type to the existing ones already supported by the bbdev PMDs.
This set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental).
I plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test.
* bbdev: add device info on queue topology
https://patches.dpdk.org/project/dpdk/list/?series=22076
Addressing an historical concern that the device info struct only imperfectly captured what queues are available on the device (number of operation and priority). This ended up being an iterative process for application to find each queue could be configured.
ie. the gap was captured as technical debt previously in comments
/* This isn't ideal because it reports the maximum number of queues but
* does not provide info on how many can be uplink/downlink or different
* priorities
*/
This is now being exposed explictly based on the what the device actually supports using the existing info_get api
* bbdev: allow operation type enum for growth
https://patches.dpdk.org/project/dpdk/list/?series=23509
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Nicolas Chautru (7):
bbdev: allow operation type enum for growth
bbdev: add device status info
bbdev: add device info on queue topology
drivers/baseband: update PMDs to expose queue per operation
bbdev: add new operation for FFT processing
bbdev: add queue related warning and status information
bbdev: add a lock option for enqueue/dequeue operation
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 6 +-
doc/guides/prog_guide/bbdev.rst | 130 ++++++++++++++++++
drivers/baseband/acc100/rte_acc100_pmd.c | 30 ++--
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 9 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 9 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 10 +-
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 12 ++
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 61 ++++++++-
lib/bbdev/rte_bbdev.h | 151 ++++++++++++++++++++-
lib/bbdev/rte_bbdev_op.h | 151 ++++++++++++++++++++-
lib/bbdev/version.map | 11 ++
14 files changed, 562 insertions(+), 23 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* RE: [PATCH v8] sched: enable CMAN at runtime
2022-07-05 17:05 1% ` [PATCH v8] " Marcin Danilewicz
@ 2022-07-05 18:00 0% ` Ajmera, Megha
2022-07-06 8:53 0% ` Singh, Jasvinder
2022-07-08 13:14 1% ` [PATCH v9] " Marcin Danilewicz
2 siblings, 0 replies; 200+ results
From: Ajmera, Megha @ 2022-07-05 18:00 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder, Dumitrescu, Cristian
>
> Added changes to enable CMAN (RED or PIE) at init from profile configuration
> file.
>
> By default CMAN code is enable but not in use, when there is no RED or PIE
> profile configured.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> Log: v2 change in rte_sched.h to avoid ABI breakage.
> v3 changes from comments
> v4 rebase to 22.07-rc1
> v5 rebase to main latest
> v6 commit message fixed
> v7 changes from comments
> v8 with changes from comments
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 47 +-------
> examples/qos_sched/cfg_file.h | 5 -
> examples/qos_sched/init.c | 76 +-----------
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 135 +--------------------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 47 +-------
> 11 files changed, 296 insertions(+), 320 deletions(-) create mode 100644
> examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
> diff --git a/config/rte_config.h b/config/rte_config.h index
> 46549cb062..ae56a86394 100644
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> @@ -88,9 +88,6 @@
> /* rte_power defines */
> #define RTE_MAX_LCORE_FREQS 64
>
> -/* rte_sched defines */
> -// RTE_SCHED_CMAN is not set
> -
> /* rte_graph defines */
> #define RTE_GRAPH_BURST_SIZE 256
> #define RTE_LIBRTE_GRAPH_STATS 1
> diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c
> b/drivers/net/softnic/rte_eth_softnic_tm.c
> index 6a7766ba1c..3e4bed81e9 100644
> --- a/drivers/net/softnic/rte_eth_softnic_tm.c
> +++ b/drivers/net/softnic/rte_eth_softnic_tm.c
> @@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
> return 0;
> }
>
> -#ifdef RTE_SCHED_CMAN
> -#define WRED_SUPPORTED 1
> -#else
> #define WRED_SUPPORTED 0
> -#endif
>
> #define STATS_MASK_DEFAULT \
> (RTE_TM_STATS_N_PKTS | \
> @@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev,
> uint32_t tc_id)
> return NULL;
> }
>
> -#ifdef RTE_SCHED_CMAN
> -
> static void
> wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id) { @@ -
> 2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t
> subport_id)
> }
> }
>
> -#else
> -
> -#define wred_profiles_set(dev, subport_id)
> -
> -#endif
> -
> static struct tm_shared_shaper *
> tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node) {
> diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c index
> b138e885cf..e68e9961be 100644
> --- a/examples/ip_pipeline/tmgr.c
> +++ b/examples/ip_pipeline/tmgr.c
> @@ -17,7 +17,6 @@ static uint32_t n_subport_profiles; static struct
> rte_sched_pipe_params
> pipe_profile[TMGR_PIPE_PROFILE_MAX];
>
> -#ifdef RTE_SCHED_CMAN
> static struct rte_sched_cman_params cman_params = {
> .red_params = {
> /* Traffic Class 0 Colors Green / Yellow / Red */ @@ -86,7
> +85,6 @@ static struct rte_sched_cman_params cman_params = {
> [12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2
> = 9},
> },
> };
> -#endif /* RTE_SCHED_CMAN */
>
> static uint32_t n_pipe_profiles;
>
> @@ -96,9 +94,7 @@ static const struct rte_sched_subport_params
> subport_params_default = {
> .pipe_profiles = pipe_profile,
> .n_pipe_profiles = 0, /* filled at run time */
> .n_max_pipe_profiles = RTE_DIM(pipe_profile), -#ifdef
> RTE_SCHED_CMAN
> .cman_params = &cman_params,
> -#endif /* RTE_SCHED_CMAN */
> };
>
> static struct tmgr_port_list tmgr_port_list; diff --git
> a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c index
> 450482f07d..7f4114bd56 100644
> --- a/examples/qos_sched/cfg_file.c
> +++ b/examples/qos_sched/cfg_file.c
> @@ -23,6 +23,8 @@
> uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
> uint32_t n_active_queues;
>
> +struct rte_sched_cman_params cman_params;
> +
> int
> cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params
> *port_params) { @@ -229,40 +231,6 @@ cfg_load_subport_profile(struct
> rte_cfgfile *cfg,
> return 0;
> }
>
> -#ifdef RTE_SCHED_CMAN
> -void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
> - struct rte_sched_cman_params
> cman_p)
> -{
> - int j, k;
> - subport_p->cman_params->cman_mode = cman_p.cman_mode;
> -
> - for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
> - if (subport_p->cman_params->cman_mode ==
> - RTE_SCHED_CMAN_RED) {
> - for (k = 0; k < RTE_COLORS; k++) {
> - subport_p->cman_params-
> >red_params[j][k].min_th =
> - cman_p.red_params[j][k].min_th;
> - subport_p->cman_params-
> >red_params[j][k].max_th =
> - cman_p.red_params[j][k].max_th;
> - subport_p->cman_params-
> >red_params[j][k].maxp_inv =
> - cman_p.red_params[j][k].maxp_inv;
> - subport_p->cman_params-
> >red_params[j][k].wq_log2 =
> - cman_p.red_params[j][k].wq_log2;
> - }
> - } else {
> - subport_p->cman_params->pie_params[j].qdelay_ref =
> - cman_p.pie_params[j].qdelay_ref;
> - subport_p->cman_params-
> >pie_params[j].dp_update_interval =
> - cman_p.pie_params[j].dp_update_interval;
> - subport_p->cman_params->pie_params[j].max_burst =
> - cman_p.pie_params[j].max_burst;
> - subport_p->cman_params->pie_params[j].tailq_th =
> - cman_p.pie_params[j].tailq_th;
> - }
> - }
> -}
> -#endif
> -
> int
> cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params
> *subport_params) { @@ -276,11 +244,7 @@ cfg_load_subport(struct
> rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
> memset(active_queues, 0, sizeof(active_queues));
> n_active_queues = 0;
>
> -#ifdef RTE_SCHED_CMAN
> - struct rte_sched_cman_params cman_params = {
> - .cman_mode = RTE_SCHED_CMAN_RED,
> - .red_params = { },
> - };
> + subport_params->cman_params = NULL;
>
> if (rte_cfgfile_has_section(cfg, "red")) {
> cman_params.cman_mode = RTE_SCHED_CMAN_RED; @@ -
> 387,7 +351,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct
> rte_sched_subport_params *subpo
>
> }
> }
Here only mode is set to RTE_SCHED_CMAN_RED. But I could not find the place where cman_params are set from cfg_file (for e.g. red_params). Can you clarify?
^ permalink raw reply [relevance 0%]
* [PATCH v8] sched: enable CMAN at runtime
2022-07-04 9:19 1% ` [PATCH v7] " Marcin Danilewicz
@ 2022-07-05 17:05 1% ` Marcin Danilewicz
2022-07-05 18:00 0% ` Ajmera, Megha
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Marcin Danilewicz @ 2022-07-05 17:05 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
v6 commit message fixed
v7 changes from comments
v8 with changes from comments
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 47 +-------
examples/qos_sched/cfg_file.h | 5 -
examples/qos_sched/init.c | 76 +-----------
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 135 +--------------------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 296 insertions(+), 320 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3e4bed81e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-#define WRED_SUPPORTED 1
-#else
#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..7f4114bd56 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -23,6 +23,8 @@
uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
uint32_t n_active_queues;
+struct rte_sched_cman_params cman_params;
+
int
cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port_params)
{
@@ -229,40 +231,6 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
- struct rte_sched_cman_params cman_p)
-{
- int j, k;
- subport_p->cman_params->cman_mode = cman_p.cman_mode;
-
- for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
- if (subport_p->cman_params->cman_mode ==
- RTE_SCHED_CMAN_RED) {
- for (k = 0; k < RTE_COLORS; k++) {
- subport_p->cman_params->red_params[j][k].min_th =
- cman_p.red_params[j][k].min_th;
- subport_p->cman_params->red_params[j][k].max_th =
- cman_p.red_params[j][k].max_th;
- subport_p->cman_params->red_params[j][k].maxp_inv =
- cman_p.red_params[j][k].maxp_inv;
- subport_p->cman_params->red_params[j][k].wq_log2 =
- cman_p.red_params[j][k].wq_log2;
- }
- } else {
- subport_p->cman_params->pie_params[j].qdelay_ref =
- cman_p.pie_params[j].qdelay_ref;
- subport_p->cman_params->pie_params[j].dp_update_interval =
- cman_p.pie_params[j].dp_update_interval;
- subport_p->cman_params->pie_params[j].max_burst =
- cman_p.pie_params[j].max_burst;
- subport_p->cman_params->pie_params[j].tailq_th =
- cman_p.pie_params[j].tailq_th;
- }
- }
-}
-#endif
-
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
{
@@ -276,11 +244,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
- struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
- .red_params = { },
- };
+ subport_params->cman_params = NULL;
if (rte_cfgfile_has_section(cfg, "red")) {
cman_params.cman_mode = RTE_SCHED_CMAN_RED;
@@ -387,7 +351,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +428,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
- set_subport_cman_params(subport_params+i, cman_params);
-#endif
+ subport_params[i].cman_params = &cman_params;
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..0dc458aa71 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,11 +12,6 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
-void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
- struct rte_sched_cman_params cman_p);
-#endif
-
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
int cfg_load_subport_profile(struct rte_cfgfile *cfg,
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..e8b819ffb9 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,78 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
-struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
- .red_params = {
- /* Traffic Class 0 Colors Green / Yellow / Red */
- [0][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [0][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 1 - Colors Green / Yellow / Red */
- [1][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [1][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 2 - Colors Green / Yellow / Red */
- [2][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [2][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 3 - Colors Green / Yellow / Red */
- [3][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [3][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 4 - Colors Green / Yellow / Red */
- [4][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [4][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 5 - Colors Green / Yellow / Red */
- [5][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [5][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 6 - Colors Green / Yellow / Red */
- [6][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [6][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 7 - Colors Green / Yellow / Red */
- [7][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [7][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 8 - Colors Green / Yellow / Red */
- [8][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [8][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 9 - Colors Green / Yellow / Red */
- [9][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [9][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 10 - Colors Green / Yellow / Red */
- [10][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [10][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 11 - Colors Green / Yellow / Red */
- [11][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [11][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
-
- /* Traffic Class 12 - Colors Green / Yellow / Red */
- [12][0] = {.min_th = 48, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][1] = {.min_th = 40, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- [12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
- },
-};
-#endif /* RTE_SCHED_CMAN */
-
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
.n_pipes_per_subport_enabled = 4096,
@@ -281,9 +209,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
- .cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
+ .cman_params = NULL,
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..c9ec187c93 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -73,137 +73,4 @@ tc period = 40 ; Milliseconds
tc 12 oversubscription weight = 1
-tc 12 wrr weights = 1 1 1 1
-
-; RED params per traffic class and color (Green / Yellow / Red)
-;[red]
-;tc 0 wred min = 48 40 32
-;tc 0 wred max = 64 64 64
-;tc 0 wred inv prob = 10 10 10
-;tc 0 wred weight = 9 9 9
-
-;tc 1 wred min = 48 40 32
-;tc 1 wred max = 64 64 64
-;tc 1 wred inv prob = 10 10 10
-;tc 1 wred weight = 9 9 9
-
-;tc 2 wred min = 48 40 32
-;tc 2 wred max = 64 64 64
-;tc 2 wred inv prob = 10 10 10
-;tc 2 wred weight = 9 9 9
-
-;tc 3 wred min = 48 40 32
-;tc 3 wred max = 64 64 64
-;tc 3 wred inv prob = 10 10 10
-;tc 3 wred weight = 9 9 9
-
-;tc 4 wred min = 48 40 32
-;tc 4 wred max = 64 64 64
-;tc 4 wred inv prob = 10 10 10
-;tc 4 wred weight = 9 9 9
-
-;tc 5 wred min = 48 40 32
-;tc 5 wred max = 64 64 64
-;tc 5 wred inv prob = 10 10 10
-;tc 5 wred weight = 9 9 9
-
-;tc 6 wred min = 48 40 32
-;tc 6 wred max = 64 64 64
-;tc 6 wred inv prob = 10 10 10
-;tc 6 wred weight = 9 9 9
-
-;tc 7 wred min = 48 40 32
-;tc 7 wred max = 64 64 64
-;tc 7 wred inv prob = 10 10 10
-;tc 7 wred weight = 9 9 9
-
-;tc 8 wred min = 48 40 32
-;tc 8 wred max = 64 64 64
-;tc 8 wred inv prob = 10 10 10
-;tc 8 wred weight = 9 9 9
-
-;tc 9 wred min = 48 40 32
-;tc 9 wred max = 64 64 64
-;tc 9 wred inv prob = 10 10 10
-;tc 9 wred weight = 9 9 9
-
-;tc 10 wred min = 48 40 32
-;tc 10 wred max = 64 64 64
-;tc 10 wred inv prob = 10 10 10
-;tc 10 wred weight = 9 9 9
-
-;tc 11 wred min = 48 40 32
-;tc 11 wred max = 64 64 64
-;tc 11 wred inv prob = 10 10 10
-;tc 11 wred weight = 9 9 9
-
-;tc 12 wred min = 48 40 32
-;tc 12 wred max = 64 64 64
-;tc 12 wred inv prob = 10 10 10
-;tc 12 wred weight = 9 9 9
-
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+tc 12 wrr weights = 1 1 1 1
\ No newline at end of file
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
2022-06-09 7:53 0% ` Maxime Coquelin
@ 2022-07-05 15:45 0% ` Bruce Richardson
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-07-05 15:45 UTC (permalink / raw)
To: Nicolas Chautru
Cc: dev, gakhil, thomas, maxime.coquelin, trix, ray.kinsella,
hemant.agrawal, david.marchand, stephen
On Wed, Jun 08, 2022 at 05:34:30PM -0700, Nicolas Chautru wrote:
> Intent to resolve in DPDK 22.11 historical usage which prevents
> graceful extension of enum and API without troublesome ABI breakage
> as well as extending API RTE_BBDEV_OP_FFT for new operation type
> in bbdev as well as other new members in existing structures.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking bus object as internal
2022-07-05 4:43 0% ` Hemant Agrawal
@ 2022-07-05 6:59 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2022-07-05 6:59 UTC (permalink / raw)
To: hemant.agrawal, Kevin Laatz, David Marchand, dev, techboard; +Cc: Ray Kinsella
On 7/5/22 07:43, Hemant Agrawal wrote:
> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>
> On 7/4/2022 7:59 PM, Kevin Laatz wrote:
>> On 30/06/2022 10:41, David Marchand wrote:
>>> rte_bus is unnecessarily exposed in the public API/ABI.
>>> Besides, we had cases where extending rte_bus was necessary.
>>> Announce that rte_bus will be made opaque in the public API and mark
>>> associated API as internal.
>>>
>>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>>> ---
>>> A RFC series of the intended changes is available at:
>>> https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both
>>>
>>>
>>> ---
>>> doc/guides/rel_notes/deprecation.rst | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>> Acked-by: Kevin Laatz <kevin.laatz@intel.com>
>>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking bus object as internal
2022-07-04 14:29 0% ` Kevin Laatz
@ 2022-07-05 4:43 0% ` Hemant Agrawal
2022-07-05 6:59 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Hemant Agrawal @ 2022-07-05 4:43 UTC (permalink / raw)
To: Kevin Laatz, David Marchand, dev, techboard; +Cc: Ray Kinsella
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
On 7/4/2022 7:59 PM, Kevin Laatz wrote:
> On 30/06/2022 10:41, David Marchand wrote:
>> rte_bus is unnecessarily exposed in the public API/ABI.
>> Besides, we had cases where extending rte_bus was necessary.
>> Announce that rte_bus will be made opaque in the public API and mark
>> associated API as internal.
>>
>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>> ---
>> A RFC series of the intended changes is available at:
>> https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both
>>
>>
>> ---
>> doc/guides/rel_notes/deprecation.rst | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
> Acked-by: Kevin Laatz <kevin.laatz@intel.com>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking bus object as internal
2022-06-30 9:41 8% [PATCH] doc: announce marking bus object as internal David Marchand
2022-06-30 9:54 0% ` Bruce Richardson
@ 2022-07-04 14:29 0% ` Kevin Laatz
2022-07-05 4:43 0% ` Hemant Agrawal
1 sibling, 1 reply; 200+ results
From: Kevin Laatz @ 2022-07-04 14:29 UTC (permalink / raw)
To: David Marchand, dev, techboard; +Cc: Ray Kinsella
On 30/06/2022 10:41, David Marchand wrote:
> rte_bus is unnecessarily exposed in the public API/ABI.
> Besides, we had cases where extending rte_bus was necessary.
> Announce that rte_bus will be made opaque in the public API and mark
> associated API as internal.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> A RFC series of the intended changes is available at:
> https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both
>
> ---
> doc/guides/rel_notes/deprecation.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Acked-by: Kevin Laatz <kevin.laatz@intel.com>
^ permalink raw reply [relevance 0%]
* [PATCH v7] sched: enable CMAN at runtime
2022-06-21 8:16 1% ` [PATCH v6] sched: " Marcin Danilewicz
@ 2022-07-04 9:19 1% ` Marcin Danilewicz
2022-07-05 17:05 1% ` [PATCH v8] " Marcin Danilewicz
0 siblings, 1 reply; 200+ results
From: Marcin Danilewicz @ 2022-07-04 9:19 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
v6 commit message fixed
v7 changes from comments
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 135 +--------------------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 295 insertions(+), 210 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3e4bed81e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
-#define WRED_SUPPORTED 1
-#else
#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..c9ec187c93 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -73,137 +73,4 @@ tc period = 40 ; Milliseconds
tc 12 oversubscription weight = 1
-tc 12 wrr weights = 1 1 1 1
-
-; RED params per traffic class and color (Green / Yellow / Red)
-;[red]
-;tc 0 wred min = 48 40 32
-;tc 0 wred max = 64 64 64
-;tc 0 wred inv prob = 10 10 10
-;tc 0 wred weight = 9 9 9
-
-;tc 1 wred min = 48 40 32
-;tc 1 wred max = 64 64 64
-;tc 1 wred inv prob = 10 10 10
-;tc 1 wred weight = 9 9 9
-
-;tc 2 wred min = 48 40 32
-;tc 2 wred max = 64 64 64
-;tc 2 wred inv prob = 10 10 10
-;tc 2 wred weight = 9 9 9
-
-;tc 3 wred min = 48 40 32
-;tc 3 wred max = 64 64 64
-;tc 3 wred inv prob = 10 10 10
-;tc 3 wred weight = 9 9 9
-
-;tc 4 wred min = 48 40 32
-;tc 4 wred max = 64 64 64
-;tc 4 wred inv prob = 10 10 10
-;tc 4 wred weight = 9 9 9
-
-;tc 5 wred min = 48 40 32
-;tc 5 wred max = 64 64 64
-;tc 5 wred inv prob = 10 10 10
-;tc 5 wred weight = 9 9 9
-
-;tc 6 wred min = 48 40 32
-;tc 6 wred max = 64 64 64
-;tc 6 wred inv prob = 10 10 10
-;tc 6 wred weight = 9 9 9
-
-;tc 7 wred min = 48 40 32
-;tc 7 wred max = 64 64 64
-;tc 7 wred inv prob = 10 10 10
-;tc 7 wred weight = 9 9 9
-
-;tc 8 wred min = 48 40 32
-;tc 8 wred max = 64 64 64
-;tc 8 wred inv prob = 10 10 10
-;tc 8 wred weight = 9 9 9
-
-;tc 9 wred min = 48 40 32
-;tc 9 wred max = 64 64 64
-;tc 9 wred inv prob = 10 10 10
-;tc 9 wred weight = 9 9 9
-
-;tc 10 wred min = 48 40 32
-;tc 10 wred max = 64 64 64
-;tc 10 wred inv prob = 10 10 10
-;tc 10 wred weight = 9 9 9
-
-;tc 11 wred min = 48 40 32
-;tc 11 wred max = 64 64 64
-;tc 11 wred inv prob = 10 10 10
-;tc 11 wred weight = 9 9 9
-
-;tc 12 wred min = 48 40 32
-;tc 12 wred max = 64 64 64
-;tc 12 wred inv prob = 10 10 10
-;tc 12 wred weight = 9 9 9
-
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+tc 12 wrr weights = 1 1 1 1
\ No newline at end of file
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: Optimizations are not features
2022-06-29 20:44 0% ` Honnappa Nagarahalli
2022-06-30 15:39 0% ` Morten Brørup
@ 2022-07-03 19:38 0% ` Konstantin Ananyev
1 sibling, 0 replies; 200+ results
From: Konstantin Ananyev @ 2022-07-03 19:38 UTC (permalink / raw)
To: Honnappa Nagarahalli, Andrew Rybchenko, Morten Brørup, Jerin Jacob
Cc: dpdk-dev, techboard, nd
29/06/2022 21:44, Honnappa Nagarahalli пишет:
> <snip>
>
>>
>> 04/06/2022 13:51, Andrew Rybchenko пишет:
>>> On 6/4/22 15:19, Morten Brørup wrote:
>>>>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
>>>>> Sent: Saturday, 4 June 2022 13.10
>>>>>
>>>>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
>>>>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>>>>
>>>>>> On 6/4/22 12:33, Jerin Jacob wrote:
>>>>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
>>>>> <mb@smartsharesystems.com> wrote:
>>>>>>>>
>>>>>>>> I would like the DPDK community to change its view on compile
>>>>>>>> time
>>>>> options. Here is why:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Application specific performance micro-optimizations like “fast
>>>>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
>>>>> presented as features.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> They are not features, but optimizations, and I don’t understand
>>>>> the need for them to be available at run-time!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Instead of adding a bunch of exotic exceptions to the fast path
>>>>>>>> of
>>>>> the PMDs, they should be compile time options. This will improve
>>>>> performance by avoiding branches in the fast path, both for the
>>>>> applications using them, and for generic applications (where the
>>>>> exotic code is omitted).
>>>>>>>
>>>>>>> Agree. I think, keeping the best of both worlds would be
>>>>>>>
>>>>>>> -Enable the feature/optimization as runtime -Have a compile-time
>>>>>>> option to disable the feature/optimization as
>>>>> an override.
>>>>>>
>>>>>> It is hard to find the right balance, but in general compile time
>>>>>> options are a nightmare for maintenance. Number of required builds
>>>>>> will grow as an exponent.
>>>>
>>>> Test combinations are exponential for N features, regardless if N are
>>>> runtime or compile time options.
>>>
>>> But since I'm talking about build checks I don't care about
>>> exponential grows in run time. Yes, testing should care, but it is a separate
>> story.
>>>
>>>>
>>>>>> Of course, we can
>>>>>> limit number of checked combinations, but it will result in flow of
>>>>>> patches to fix build in other cases.
>>>>>
>>>>> The build breakage can be fixed if we use (2) vs (1)
>>>>>
>>>>> 1)
>>>>> #ifdef ...
>>>>> My feature
>>>>> #endif
>>>>>
>>>>> 2)
>>>>> static __rte_always_inline int
>>>>> rte_has_xyz_feature(void)
>>>>> {
>>>>> #ifdef RTE_LIBRTE_XYZ_FEATURE
>>>>> return RTE_LIBRTE_XYZ_FEATURE; #else
>>>>> return 0;
>>>>> #endif
>>>>> }
>>>>>
>>>>> if(rte_has_xyz_feature())) {
>>>>> My feature code
>>>>>
>>>>> }
>>>>>
>>>
>>> Jerin, thanks, very good example.
>>>
>>>> I'm not sure all the features can be covered by that, e.g. added
>>>> fields in structures.
>>>
>>> +1
>>>
>>>>
>>>> Also, I would consider such features "opt in" at compile time only.
>>>> As such, they could be allowed to break the ABI/API.
>>>>
>>>>>
>>>>>
>>>>>> Also compile time options tend to make code less readable which
>>>>>> makes all aspects of the development harder.
>>>>>>
>>>>>> Yes, compile time is nice for micro optimizations, but I have great
>>>>>> concerns that it is a right way to go.
>>>>>>
>>>>>>>> Please note that I am only talking about the performance
>>>>> optimizations that are limited to application specific use cases. I
>>>>> think it makes sense to require that performance optimizing an
>>>>> application also requires recompiling the performance critical
>>>>> libraries used by it.
>>>>>>>> abandon some of existing functionality to create a 'short-cut'
>>>>>>>>
>>>>>>>>
>>>>>>>> Allowing compile time options for application specific
>>>>>>>> performance
>>>>> optimizations in DPDK would also open a path for other
>>>>> optimizations, which can only be achieved at compile time, such as
>>>>> “no fragmented packets”, “no attached mbufs” and “single mbuf pool”.
>>>>> And even more exotic optimizations, such as the “indexed mempool
>>>>> cache”, which was rejected due to ABI violations – they could be
>>>>> marked as “risky and untested” or similar, but still be part of the DPDK main
>> repository.
>>>>>>>>
>>
>>
>> Thanks Morten for bringing it up, it is an interesting topic.
>> Though I look at it from different angle.
>> All optimizations you mentioned above introduce new limitations:
>> MBUF_FAST_FREE - no indirect mbufs and multiple mempools, mempool object
>> indexes - mempool size is limited to 4GB, direct rearm - drop ability to
>> stop/reconfigure TX queue, while RX queue is still running, etc.
>> Note that all these limitations are not forced by HW.
>> All of them are pure SW limitations that developers forced in (or tried to) to get
>> few extra performance.
>> That's concerning tendency.
>>
>> As more and more such 'optimization via limitation' will come in:
>> - DPDK feature list will become more and more fragmented.
>> - Would cause more and more confusion for the users.
>> - Unmet expectations - difference in performance between 'default'
>> and 'optimized' version of DPDK will become bigger and bigger.
>> - As Andrew already mentioned, maintaining all these 'sub-flavours'
>> of DPDK will become more and more difficult.
> The point that we need to remember is, these features/optimizations are introduced after seeing performance issues in practical use cases.
Sorry I didn't get it: what performance issues you are talking about?
If let say our mempool code is sub-optimal in some place for some
architecture due to bad design or bad implementation - please point to
it and let's try to fix it, instead of avoiding using mempool API
If you just saying that avoiding using mempool in some cases
could buy us few extra performance (a short-cut),
then yes it surely could.
Another question - is it really worth it?
Having all mbufs management covered by one SW abstraction
helps a lot in terms of project maintainability, further extensions,
introducing new common optimizations, etc.
> DPDK is not being used in just one use case, it is being used in several use cases which have their own unique requirements. Is 4GB enough for packet buffers - yes it is enough in certain use
cases. Are their NICs with single port - yes there are.
Sure there are NICs with one port.
But also there are NICs with 2 ports, 4 ports, etc.
Should we maintain specific DPDK sub-versions for all these cases?
From my perspective - no.
It would be overwhelming effort for DPDK community, plus
many customers use DPDK to build their own products that supposed
to work seamlessly across multiple use-cases/platforms.
HW is being created because use cases and business cases exist. It is
obvious that as DPDK gets adopted on more platforms that differ largely,
the features will increase and it will become complex. Complexity should
not be used as a criteria to reject patches.
Well, we do have plenty of HW specific optimizations inside DPDK
and we put a lot of effort that all this HW specific staff be
transparent to the user as much as possible.
I don't see why for SW specific optimizations it should be different.
>
> There is different perspective to what you are calling as 'limitations'.
By 'limitations' I mean situation when user has to cut off
existing functionality to enable these 'optimizations'.
I can argue that multiple mempools, stop/reconfigure TX queue while RX
queue is still running are exotic. Just because those are allowed
currently (probably accidently) does not mean they are being used. Are
there use cases that make use of these features?
If DPDK examples/l3fwd doesn't use these features,
it doesn't mean they are useless :)
I believe both multiple mempools (indirect-mbufs) and ability to
start/stop queues separately are major DPDK features that are used
across many real-world deployments.
>
> The base/existing design for DPDK was done with one particular HW architecture in mind where there was an abundance of resources. Unfortunately, that HW architecture is fast evolving and DPDK is adopted in use cases where that kind of resources are not available. For ex: efficiency cores are being introduced by every CPU vendor now. Soon enough, we will see big-little architecture in networking as well. The existing PMD design introduces 512B of stores (256B for copying to stack variable and 256B to store lcore cache) and 256B load/store on RX side every 32 packets back to back. It doesn't make sense to have that kind of memcopy for little/efficiency cores just for the driver code.
I don't object about specific use-case optimizations.
Specially if the use-case is a common one.
But I think such changes has to be transparent to the user as
much as possible and shouldn't cause further DPDK code fragmentation
(new CONFIG options, etc.).
I understand that it is not always possible, but for pure SW based
optimizations, I think it is a reasonable expectation.
>>
>> So, probably instead of making such changes easier, we need somehow to
>> persuade developers to think more about optimizations that would be generic
>> and transparent to the user.
> Or may be we need to think of creating alternate ways of programming.
>
>> I do realize that it is not always possible due to various reasons (HW limitations,
>> external dependencies, etc.) but that's another story.
>>
>> Let's take for example MBUF_FAST_FREE.
>> In fact, I am not sure that we need it as tx offload flag at all.
>> PMD TX-path has all necessary information to decide at run-time can it do
>> fast_free() for not:
>> At tx_burst() PMD can check are all mbufs satisfy these conditions (same
>> mempool, refcnt==1) and update some fields and/or counters inside TXQ to
>> reflect it.
>> Then, at tx_free() we can use this info to decide between fast_free() and
>> normal_free().
>> As at tx_burst() we read mbuf fields anyway, impact for this extra step I guess
>> would be minimal.
>> Yes, most likely, it wouldn't be as fast as with current TX offload flag, or
>> conditional compilation approach.
>> But it might be still significantly faster then normal_free(), plus such approach
>> will be generic and transparent to the user.
> IMO, this depends on the philosophy that we want to adopt. I would prefer to make control plane complex for performance gains on the data plane. The performance on the data plane has a multiplying effect due to the ratio of number of cores assigned for data plane vs control plane.
>
> I am not against evaluating alternatives, but the alternative approaches need to have similar (not the same) performance.
>
>>
>> Konstantin
^ permalink raw reply [relevance 0%]
* Re: DPDK Release Status Meeting 2022-06-30
2022-06-30 12:43 0% ` Dodji Seketeli
@ 2022-06-30 17:52 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-06-30 17:52 UTC (permalink / raw)
To: Dodji Seketeli, David Marchand; +Cc: Mcnamara, John, dev, thomas
On 6/30/2022 1:43 PM, Dodji Seketeli wrote:
> David Marchand <david.marchand@redhat.com> writes:
>
>> On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit <ferruh.yigit@xilinx.com> wrote:
>>> Last minute opens were:
>>>
>>> * I am getting ABI check crash, when again v21.11 with abigail 2.0.0,
>>> for the file 'librte_common_qat'. Not sure if this is specific to my
>>> environment, would be good if someone double checks.
>>
>> I ran into a crash too with 2.0.0.
>> This seems fixed in (unreleased) latest libabigail.
>
> Sorry about that. We are working towards releasing 2.1 soon, which
> should hopefully fix that.
>
I confirm issue is solved with latest head
(libabigail-2.0-140-gd21dbadddd84).
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* RE: Optimizations are not features
2022-06-29 20:44 0% ` Honnappa Nagarahalli
@ 2022-06-30 15:39 0% ` Morten Brørup
2022-07-03 19:38 0% ` Konstantin Ananyev
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-30 15:39 UTC (permalink / raw)
To: Honnappa Nagarahalli, Konstantin Ananyev, Andrew Rybchenko, Jerin Jacob
Cc: dpdk-dev, techboard, nd, nd
> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Wednesday, 29 June 2022 22.44
>
> <snip>
>
> >
> > 04/06/2022 13:51, Andrew Rybchenko пишет:
> > > On 6/4/22 15:19, Morten Brørup wrote:
> > >>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> > >>> Sent: Saturday, 4 June 2022 13.10
> > >>>
> > >>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> > >>> <andrew.rybchenko@oktetlabs.ru> wrote:
> > >>>>
> > >>>> On 6/4/22 12:33, Jerin Jacob wrote:
> > >>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> > >>> <mb@smartsharesystems.com> wrote:
> > >>>>>>
> > >>>>>> I would like the DPDK community to change its view on compile
> > >>>>>> time
> > >>> options. Here is why:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Application specific performance micro-optimizations like
> “fast
> > >>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> > >>> presented as features.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> They are not features, but optimizations, and I don’t
> understand
> > >>> the need for them to be available at run-time!
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Instead of adding a bunch of exotic exceptions to the fast
> path
> > >>>>>> of
> > >>> the PMDs, they should be compile time options. This will improve
> > >>> performance by avoiding branches in the fast path, both for the
> > >>> applications using them, and for generic applications (where the
> > >>> exotic code is omitted).
> > >>>>>
> > >>>>> Agree. I think, keeping the best of both worlds would be
> > >>>>>
> > >>>>> -Enable the feature/optimization as runtime -Have a compile-
> time
> > >>>>> option to disable the feature/optimization as
> > >>> an override.
> > >>>>
> > >>>> It is hard to find the right balance, but in general compile
> time
> > >>>> options are a nightmare for maintenance. Number of required
> builds
> > >>>> will grow as an exponent.
> > >>
> > >> Test combinations are exponential for N features, regardless if N
> are
> > >> runtime or compile time options.
> > >
> > > But since I'm talking about build checks I don't care about
> > > exponential grows in run time. Yes, testing should care, but it is
> a separate
> > story.
> > >
> > >>
> > >>>> Of course, we can
> > >>>> limit number of checked combinations, but it will result in flow
> of
> > >>>> patches to fix build in other cases.
> > >>>
> > >>> The build breakage can be fixed if we use (2) vs (1)
> > >>>
> > >>> 1)
> > >>> #ifdef ...
> > >>> My feature
> > >>> #endif
> > >>>
> > >>> 2)
> > >>> static __rte_always_inline int
> > >>> rte_has_xyz_feature(void)
> > >>> {
> > >>> #ifdef RTE_LIBRTE_XYZ_FEATURE
> > >>> return RTE_LIBRTE_XYZ_FEATURE; #else
> > >>> return 0;
> > >>> #endif
> > >>> }
> > >>>
> > >>> if(rte_has_xyz_feature())) {
> > >>> My feature code
> > >>>
> > >>> }
> > >>>
> > >
> > > Jerin, thanks, very good example.
> > >
> > >> I'm not sure all the features can be covered by that, e.g. added
> > >> fields in structures.
> > >
> > > +1
> > >
> > >>
> > >> Also, I would consider such features "opt in" at compile time
> only.
> > >> As such, they could be allowed to break the ABI/API.
> > >>
> > >>>
> > >>>
> > >>>> Also compile time options tend to make code less readable which
> > >>>> makes all aspects of the development harder.
> > >>>>
> > >>>> Yes, compile time is nice for micro optimizations, but I have
> great
> > >>>> concerns that it is a right way to go.
> > >>>>
> > >>>>>> Please note that I am only talking about the performance
> > >>> optimizations that are limited to application specific use cases.
> I
> > >>> think it makes sense to require that performance optimizing an
> > >>> application also requires recompiling the performance critical
> > >>> libraries used by it.
> > >>>>>>abandon some of existing functionality to create a 'short-cut'
> > >>>>>>
> > >>>>>>
> > >>>>>> Allowing compile time options for application specific
> > >>>>>> performance
> > >>> optimizations in DPDK would also open a path for other
> > >>> optimizations, which can only be achieved at compile time, such
> as
> > >>> “no fragmented packets”, “no attached mbufs” and “single mbuf
> pool”.
> > >>> And even more exotic optimizations, such as the “indexed mempool
> > >>> cache”, which was rejected due to ABI violations – they could be
> > >>> marked as “risky and untested” or similar, but still be part of
> the DPDK main
> > repository.
> > >>>>>>
> >
> >
> > Thanks Morten for bringing it up, it is an interesting topic.
> > Though I look at it from different angle.
> > All optimizations you mentioned above introduce new limitations:
> > MBUF_FAST_FREE - no indirect mbufs and multiple mempools, mempool
> object
> > indexes - mempool size is limited to 4GB, direct rearm - drop ability
> to
> > stop/reconfigure TX queue, while RX queue is still running, etc.
> > Note that all these limitations are not forced by HW.
> > All of them are pure SW limitations that developers forced in (or
> tried to) to get
> > few extra performance.
> > That's concerning tendency.
> >
> > As more and more such 'optimization via limitation' will come in:
> > - DPDK feature list will become more and more fragmented.
> > - Would cause more and more confusion for the users.
> > - Unmet expectations - difference in performance between 'default'
> > and 'optimized' version of DPDK will become bigger and bigger.
I strongly disagree with this bullet!
We should not limit the performance to only what is possible with all features enabled.
An application developer should have the ability to disable performance-costly features not being used.
> > - As Andrew already mentioned, maintaining all these 'sub-flavours'
> > of DPDK will become more and more difficult.
> The point that we need to remember is, these features/optimizations are
> introduced after seeing performance issues in practical use cases.
> DPDK is not being used in just one use case, it is being used in
> several use cases which have their own unique requirements. Is 4GB
> enough for packet buffers - yes it is enough in certain use cases. Are
> their NICs with single port - yes there are. HW is being created
> because use cases and business cases exist. It is obvious that as DPDK
> gets adopted on more platforms that differ largely, the features will
> increase and it will become complex. Complexity should not be used as a
> criteria to reject patches.
>
> There is different perspective to what you are calling as
> 'limitations'. I can argue that multiple mempools, stop/reconfigure TX
> queue while RX queue is still running are exotic. Just because those
> are allowed currently (probably accidently) does not mean they are
> being used. Are there use cases that make use of these features?
>
> The base/existing design for DPDK was done with one particular HW
> architecture in mind where there was an abundance of resources.
> Unfortunately, that HW architecture is fast evolving and DPDK is
> adopted in use cases where that kind of resources are not available.
> For ex: efficiency cores are being introduced by every CPU vendor now.
> Soon enough, we will see big-little architecture in networking as well.
> The existing PMD design introduces 512B of stores (256B for copying to
> stack variable and 256B to store lcore cache) and 256B load/store on RX
> side every 32 packets back to back. It doesn't make sense to have that
> kind of memcopy for little/efficiency cores just for the driver code.
>
> >
> > So, probably instead of making such changes easier, we need somehow
> to
> > persuade developers to think more about optimizations that would be
> generic
> > and transparent to the user.
> Or may be we need to think of creating alternate ways of programming.
Exactly what I was hoping to achieve with this discussion.
>
> > I do realize that it is not always possible due to various reasons
> (HW limitations,
> > external dependencies, etc.) but that's another story.
> >
> > Let's take for example MBUF_FAST_FREE.
> > In fact, I am not sure that we need it as tx offload flag at all.
> > PMD TX-path has all necessary information to decide at run-time can
> it do
> > fast_free() for not:
> > At tx_burst() PMD can check are all mbufs satisfy these conditions
> (same
> > mempool, refcnt==1) and update some fields and/or counters inside TXQ
> to
> > reflect it.
> > Then, at tx_free() we can use this info to decide between fast_free()
> and
> > normal_free().
> > As at tx_burst() we read mbuf fields anyway, impact for this extra
> step I guess
> > would be minimal.
> > Yes, most likely, it wouldn't be as fast as with current TX offload
> flag, or
> > conditional compilation approach.
> > But it might be still significantly faster then normal_free(), plus
> such approach
> > will be generic and transparent to the user.
> IMO, this depends on the philosophy that we want to adopt. I would
> prefer to make control plane complex for performance gains on the data
> plane. The performance on the data plane has a multiplying effect due
> to the ratio of number of cores assigned for data plane vs control
> plane.
Yes. And if some performance-costing feature is not possible to move out from the data plane to the control plane, it should be compile time optional.
And please note that I don't buy the argument that "it will be caught by branch prediction". You are not allowed to fill up my branch predictor table with cruft!
>
> I am not against evaluating alternatives, but the alternative
> approaches need to have similar (not the same) performance.
>
> >
> > Konstantin
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-27 20:47 0% ` Chautru, Nicolas
@ 2022-06-30 14:52 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-06-30 14:52 UTC (permalink / raw)
To: dev, thomas
Cc: trix, Kinsella, Ray, Richardson, Bruce, hemant.agrawal,
david.marchand, stephen, Maxime Coquelin, gakhil, Mcnamara, John
Hi Thomas,
Any concern with that deprecation notice please?
Thanks
Nic
> -----Original Message-----
> From: Chautru, Nicolas <nicolas.chautru@intel.com>
> Sent: Monday, June 27, 2022 1:48 PM
> To: dev@dpdk.org; thomas@monjalon.net
> Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>; Richardson,
> Bruce <bruce.richardson@intel.com>; hemant.agrawal@nxp.com;
> david.marchand@redhat.com; stephen@networkplumber.org; Maxime
> Coquelin <maxime.coquelin@redhat.com>; gakhil@marvell.com
> Subject: RE: [PATCH v4] doc: announce changes in bbdev related to enum
> extension
>
> Hi Thomas,
> Kind reminder on this one.
> Thanks
> Nic
>
> > -----Original Message-----
> > From: Chautru, Nicolas
> > Sent: Friday, June 17, 2022 9:13 AM
> > To: dev@dpdk.org; thomas@monjalon.net
> > Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>;
> > Richardson, Bruce <bruce.richardson@intel.com>;
> > hemant.agrawal@nxp.com; david.marchand@redhat.com;
> > stephen@networkplumber.org; Maxime Coquelin
> > <maxime.coquelin@redhat.com>; gakhil@marvell.com
> > Subject: RE: [PATCH v4] doc: announce changes in bbdev related to enum
> > extension
> >
> > Hi Thomas,
> > Can this one be applied based on your review?
> > Thanks
> > Nic
> >
> > > -----Original Message-----
> > > From: Maxime Coquelin <maxime.coquelin@redhat.com>
> > > Sent: Thursday, June 9, 2022 12:54 AM
> > > To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> > > gakhil@marvell.com; thomas@monjalon.net
> > > Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Richardson, Bruce <bruce.richardson@intel.com>;
> > > hemant.agrawal@nxp.com; david.marchand@redhat.com;
> > > stephen@networkplumber.org
> > > Subject: Re: [PATCH v4] doc: announce changes in bbdev related to
> > > enum extension
> > >
> > > Hi Nicolas,
> > >
> > > On 6/9/22 02:34, Nicolas Chautru wrote:
> > > > Intent to resolve in DPDK 22.11 historical usage which prevents
> > > > graceful extension of enum and API without troublesome ABI
> > > > breakage as well as extending API RTE_BBDEV_OP_FFT for new
> > > > operation type in bbdev as well as other new members in existing
> structures.
> > > >
> > > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > > ---
> > > > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > > > 1 file changed, 11 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > b/doc/guides/rel_notes/deprecation.rst
> > > > index 4e5b23c..c8ab1ec 100644
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > @@ -112,6 +112,17 @@ Deprecation Notices
> > > > session and the private data of session. An opaque pointer can
> > > > be
> > exposed
> > > > directly to application which can be attached to the
> ``rte_crypto_op``.
> > > >
> > > > +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the
> > > > +``rte_bbdev_op_type``
> > > > + enum will be deprecated and instead use fixed array size when
> > > > +required to allow for
> > > > + future enum extension.
> > > > + Will extend API to support new operation type
> > > > +``RTE_BBDEV_OP_FFT`` as per this
> > > > + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
> > > > + New members will be added in ``rte_bbdev_driver_info`` to
> > > > +expose PMD queue topology inspired
> > > > + by this RFC
> > > > +https://patches.dpdk.org/project/dpdk/list/?series=22076
> > > > + New member will be added in ``rte_bbdev_driver_info`` to expose
> > > > +the device status as per
> > > > + this RFC
> > > > +https://patches.dpdk.org/project/dpdk/list/?series=23367
> > > > + This should be updated in DPDK 22.11.
> > > > +
> > > > * security: Hide structure ``rte_security_session`` and expose an
> opaque
> > > > pointer for the private data to the application which can be attached
> > > > to the packet while enqueuing.
> > >
> > > Thanks for rewording the notice.
> > >
> > > Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> > >
> > > Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce marking bus object as internal
2022-06-30 9:54 0% ` Bruce Richardson
@ 2022-06-30 14:36 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-30 14:36 UTC (permalink / raw)
To: David Marchand; +Cc: techboard, dev, Ray Kinsella, Bruce Richardson
30/06/2022 11:54, Bruce Richardson:
> On Thu, Jun 30, 2022 at 11:41:53AM +0200, David Marchand wrote:
> > rte_bus is unnecessarily exposed in the public API/ABI.
> > Besides, we had cases where extending rte_bus was necessary.
> > Announce that rte_bus will be made opaque in the public API and mark
> > associated API as internal.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > A RFC series of the intended changes is available at:
> > https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both
> >
> > ---
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 0%]
* Re: DPDK Release Status Meeting 2022-06-30
2022-06-30 11:57 0% ` David Marchand
2022-06-30 12:40 0% ` Ferruh Yigit
@ 2022-06-30 12:43 0% ` Dodji Seketeli
2022-06-30 17:52 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Dodji Seketeli @ 2022-06-30 12:43 UTC (permalink / raw)
To: David Marchand; +Cc: Ferruh Yigit, Mcnamara, John, dev, thomas
David Marchand <david.marchand@redhat.com> writes:
> On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit <ferruh.yigit@xilinx.com> wrote:
>> Last minute opens were:
>>
>> * I am getting ABI check crash, when again v21.11 with abigail 2.0.0,
>> for the file 'librte_common_qat'. Not sure if this is specific to my
>> environment, would be good if someone double checks.
>
> I ran into a crash too with 2.0.0.
> This seems fixed in (unreleased) latest libabigail.
Sorry about that. We are working towards releasing 2.1 soon, which
should hopefully fix that.
Cheers,
--
Dodji
^ permalink raw reply [relevance 0%]
* Re: DPDK Release Status Meeting 2022-06-30
2022-06-30 11:57 0% ` David Marchand
@ 2022-06-30 12:40 0% ` Ferruh Yigit
2022-06-30 12:43 0% ` Dodji Seketeli
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-06-30 12:40 UTC (permalink / raw)
To: David Marchand; +Cc: Mcnamara, John, dev, thomas, Dodji Seketeli
On 6/30/2022 12:57 PM, David Marchand wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit <ferruh.yigit@xilinx.com> wrote:
>> Last minute opens were:
>>
>> * I am getting ABI check crash, when again v21.11 with abigail 2.0.0,
>> for the file 'librte_common_qat'. Not sure if this is specific to my
>> environment, would be good if someone double checks.
>
> I ran into a crash too with 2.0.0.
> This seems fixed in (unreleased) latest libabigail.
>
Thanks David, I will try latest code.
^ permalink raw reply [relevance 0%]
* Re: DPDK Release Status Meeting 2022-06-30
2022-06-30 11:43 3% ` Ferruh Yigit
@ 2022-06-30 11:57 0% ` David Marchand
2022-06-30 12:40 0% ` Ferruh Yigit
2022-06-30 12:43 0% ` Dodji Seketeli
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2022-06-30 11:57 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Mcnamara, John, dev, thomas, Dodji Seketeli
On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit <ferruh.yigit@xilinx.com> wrote:
> Last minute opens were:
>
> * I am getting ABI check crash, when again v21.11 with abigail 2.0.0,
> for the file 'librte_common_qat'. Not sure if this is specific to my
> environment, would be good if someone double checks.
I ran into a crash too with 2.0.0.
This seems fixed in (unreleased) latest libabigail.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: DPDK Release Status Meeting 2022-06-30
@ 2022-06-30 11:43 3% ` Ferruh Yigit
2022-06-30 11:57 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-06-30 11:43 UTC (permalink / raw)
To: Mcnamara, John, dev; +Cc: thomas, david.marchand
On 6/30/2022 11:47 AM, Mcnamara, John wrote:
> Release status meeting minutes 2022-06-30
> =========================================
<...>
>
> Opens
> -----
Last minute opens were:
* I am getting ABI check crash, when again v21.11 with abigail 2.0.0,
for the file 'librte_common_qat'. Not sure if this is specific to my
environment, would be good if someone double checks.
* igb_uio build fails with latest kernel, a fix is required.
^ permalink raw reply [relevance 3%]
* Re: [PATCH] doc: announce marking bus object as internal
2022-06-30 9:41 8% [PATCH] doc: announce marking bus object as internal David Marchand
@ 2022-06-30 9:54 0% ` Bruce Richardson
2022-06-30 14:36 0% ` Thomas Monjalon
2022-07-04 14:29 0% ` Kevin Laatz
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2022-06-30 9:54 UTC (permalink / raw)
To: David Marchand; +Cc: dev, techboard, Ray Kinsella
On Thu, Jun 30, 2022 at 11:41:53AM +0200, David Marchand wrote:
> rte_bus is unnecessarily exposed in the public API/ABI.
> Besides, we had cases where extending rte_bus was necessary.
> Announce that rte_bus will be made opaque in the public API and mark
> associated API as internal.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> A RFC series of the intended changes is available at:
> https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both
>
> ---
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 0%]
* [PATCH] doc: announce marking bus object as internal
@ 2022-06-30 9:41 8% David Marchand
2022-06-30 9:54 0% ` Bruce Richardson
2022-07-04 14:29 0% ` Kevin Laatz
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2022-06-30 9:41 UTC (permalink / raw)
To: dev, techboard; +Cc: Ray Kinsella
rte_bus is unnecessarily exposed in the public API/ABI.
Besides, we had cases where extending rte_bus was necessary.
Announce that rte_bus will be made opaque in the public API and mark
associated API as internal.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
A RFC series of the intended changes is available at:
https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both
---
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 64d649777a..a9fd6676be 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -32,6 +32,12 @@ Deprecation Notices
``__atomic_thread_fence`` must be used for patches that need to be merged in
20.08 onwards. This change will not introduce any performance degradation.
+* bus: The ``rte_bus`` object will be made opaque in DPDK 22.11.
+ The goal is to remove it from the public ABI and make this object extendable.
+ As a side effect, registering a bus will be marked as an internal API:
+ external users may still register their bus using a new driver header (see
+ ``enable_driver_sdk`` meson option).
+
* mempool: Helper macro ``MEMPOOL_HEADER_SIZE()`` is deprecated and will
be removed in DPDK 22.11. The replacement macro
``RTE_MEMPOOL_HEADER_SIZE()`` is internal only.
--
2.36.1
^ permalink raw reply [relevance 8%]
* Call for Proposals - Userspace 2022
@ 2022-06-29 21:22 3% Nathan Southern
0 siblings, 0 replies; 200+ results
From: Nathan Southern @ 2022-06-29 21:22 UTC (permalink / raw)
To: announce
[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]
Dear DPDK Community,
We hope this message finds each of you well.
The Call for Proposals to speak at the upcoming in personal and virtual
Userspace event in Arcachon, France (Sep. 6-8, 2022) is now live and ends
at midnight eastern time on Friday, July 22nd: You can submit at the
following online registration form:
https://linuxfoundation.smapply.io/prog/dpdk_userspace_summit_2022/
We’re seeking speakers for 30-40 minutes each to address the following
topics as listed on this page:
- End user applications and usage of DPDK for real world deployed
solutions (such as cloud, edge, IoT, or networking applications)
- Developer stories, technical challenges when integrating or developing
with DPDK
- Enhancements and additions to the DPDK libraries, functional or
performance-wise
- New networking technologies and their applicability to DPDK
- Hardware NIC capabilities and offloads
- Hardware datapath accelerators (compression, crypto, baseband, GPU,
regex, etc.)
- Virtualization and container networking
- Debug tooling (logging, tracing, telemetry, monitoring)
- DPDK consumability (API/ABI compatibility, OS integration, packaging)
- Project infrastructure, security, testing
- Feedback from usage and deployment of DPDK applications (OSS or
proprietary)
- End user and DPDK adopter suggestions for improvements or feature
enhancement
All speaker applicants should also go through the Userspace registration
process beforehand, and will be granted Early Bird Admission fees ($100)
prior to August 8th. We are open to virtual presenters if absolutely
required, but prefer in-person participation.
Those who are approved by our Tech Board to speak at the event will have
this $100 refunded per Linux Foundation policy.
The main registration page for the event is located here:
https://events.linuxfoundation.org/dpdk-userspace-summit/
We appreciate your time, consideration and investment and look forward to
reviewing your proposals.
Many thanks
Nathan Southern
Project Coordinator, DPDK
The Linux Foundation
[-- Attachment #2: Type: text/html, Size: 8215 bytes --]
^ permalink raw reply [relevance 3%]
* RE: Optimizations are not features
2022-06-06 9:35 0% ` Konstantin Ananyev
@ 2022-06-29 20:44 0% ` Honnappa Nagarahalli
2022-06-30 15:39 0% ` Morten Brørup
2022-07-03 19:38 0% ` Konstantin Ananyev
0 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2022-06-29 20:44 UTC (permalink / raw)
To: Konstantin Ananyev, Andrew Rybchenko, Morten Brørup, Jerin Jacob
Cc: dpdk-dev, techboard, nd, nd
<snip>
>
> 04/06/2022 13:51, Andrew Rybchenko пишет:
> > On 6/4/22 15:19, Morten Brørup wrote:
> >>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> >>> Sent: Saturday, 4 June 2022 13.10
> >>>
> >>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> >>> <andrew.rybchenko@oktetlabs.ru> wrote:
> >>>>
> >>>> On 6/4/22 12:33, Jerin Jacob wrote:
> >>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> >>> <mb@smartsharesystems.com> wrote:
> >>>>>>
> >>>>>> I would like the DPDK community to change its view on compile
> >>>>>> time
> >>> options. Here is why:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Application specific performance micro-optimizations like “fast
> >>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> >>> presented as features.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> They are not features, but optimizations, and I don’t understand
> >>> the need for them to be available at run-time!
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Instead of adding a bunch of exotic exceptions to the fast path
> >>>>>> of
> >>> the PMDs, they should be compile time options. This will improve
> >>> performance by avoiding branches in the fast path, both for the
> >>> applications using them, and for generic applications (where the
> >>> exotic code is omitted).
> >>>>>
> >>>>> Agree. I think, keeping the best of both worlds would be
> >>>>>
> >>>>> -Enable the feature/optimization as runtime -Have a compile-time
> >>>>> option to disable the feature/optimization as
> >>> an override.
> >>>>
> >>>> It is hard to find the right balance, but in general compile time
> >>>> options are a nightmare for maintenance. Number of required builds
> >>>> will grow as an exponent.
> >>
> >> Test combinations are exponential for N features, regardless if N are
> >> runtime or compile time options.
> >
> > But since I'm talking about build checks I don't care about
> > exponential grows in run time. Yes, testing should care, but it is a separate
> story.
> >
> >>
> >>>> Of course, we can
> >>>> limit number of checked combinations, but it will result in flow of
> >>>> patches to fix build in other cases.
> >>>
> >>> The build breakage can be fixed if we use (2) vs (1)
> >>>
> >>> 1)
> >>> #ifdef ...
> >>> My feature
> >>> #endif
> >>>
> >>> 2)
> >>> static __rte_always_inline int
> >>> rte_has_xyz_feature(void)
> >>> {
> >>> #ifdef RTE_LIBRTE_XYZ_FEATURE
> >>> return RTE_LIBRTE_XYZ_FEATURE; #else
> >>> return 0;
> >>> #endif
> >>> }
> >>>
> >>> if(rte_has_xyz_feature())) {
> >>> My feature code
> >>>
> >>> }
> >>>
> >
> > Jerin, thanks, very good example.
> >
> >> I'm not sure all the features can be covered by that, e.g. added
> >> fields in structures.
> >
> > +1
> >
> >>
> >> Also, I would consider such features "opt in" at compile time only.
> >> As such, they could be allowed to break the ABI/API.
> >>
> >>>
> >>>
> >>>> Also compile time options tend to make code less readable which
> >>>> makes all aspects of the development harder.
> >>>>
> >>>> Yes, compile time is nice for micro optimizations, but I have great
> >>>> concerns that it is a right way to go.
> >>>>
> >>>>>> Please note that I am only talking about the performance
> >>> optimizations that are limited to application specific use cases. I
> >>> think it makes sense to require that performance optimizing an
> >>> application also requires recompiling the performance critical
> >>> libraries used by it.
> >>>>>>abandon some of existing functionality to create a 'short-cut'
> >>>>>>
> >>>>>>
> >>>>>> Allowing compile time options for application specific
> >>>>>> performance
> >>> optimizations in DPDK would also open a path for other
> >>> optimizations, which can only be achieved at compile time, such as
> >>> “no fragmented packets”, “no attached mbufs” and “single mbuf pool”.
> >>> And even more exotic optimizations, such as the “indexed mempool
> >>> cache”, which was rejected due to ABI violations – they could be
> >>> marked as “risky and untested” or similar, but still be part of the DPDK main
> repository.
> >>>>>>
>
>
> Thanks Morten for bringing it up, it is an interesting topic.
> Though I look at it from different angle.
> All optimizations you mentioned above introduce new limitations:
> MBUF_FAST_FREE - no indirect mbufs and multiple mempools, mempool object
> indexes - mempool size is limited to 4GB, direct rearm - drop ability to
> stop/reconfigure TX queue, while RX queue is still running, etc.
> Note that all these limitations are not forced by HW.
> All of them are pure SW limitations that developers forced in (or tried to) to get
> few extra performance.
> That's concerning tendency.
>
> As more and more such 'optimization via limitation' will come in:
> - DPDK feature list will become more and more fragmented.
> - Would cause more and more confusion for the users.
> - Unmet expectations - difference in performance between 'default'
> and 'optimized' version of DPDK will become bigger and bigger.
> - As Andrew already mentioned, maintaining all these 'sub-flavours'
> of DPDK will become more and more difficult.
The point that we need to remember is, these features/optimizations are introduced after seeing performance issues in practical use cases.
DPDK is not being used in just one use case, it is being used in several use cases which have their own unique requirements. Is 4GB enough for packet buffers - yes it is enough in certain use cases. Are their NICs with single port - yes there are. HW is being created because use cases and business cases exist. It is obvious that as DPDK gets adopted on more platforms that differ largely, the features will increase and it will become complex. Complexity should not be used as a criteria to reject patches.
There is different perspective to what you are calling as 'limitations'. I can argue that multiple mempools, stop/reconfigure TX queue while RX queue is still running are exotic. Just because those are allowed currently (probably accidently) does not mean they are being used. Are there use cases that make use of these features?
The base/existing design for DPDK was done with one particular HW architecture in mind where there was an abundance of resources. Unfortunately, that HW architecture is fast evolving and DPDK is adopted in use cases where that kind of resources are not available. For ex: efficiency cores are being introduced by every CPU vendor now. Soon enough, we will see big-little architecture in networking as well. The existing PMD design introduces 512B of stores (256B for copying to stack variable and 256B to store lcore cache) and 256B load/store on RX side every 32 packets back to back. It doesn't make sense to have that kind of memcopy for little/efficiency cores just for the driver code.
>
> So, probably instead of making such changes easier, we need somehow to
> persuade developers to think more about optimizations that would be generic
> and transparent to the user.
Or may be we need to think of creating alternate ways of programming.
> I do realize that it is not always possible due to various reasons (HW limitations,
> external dependencies, etc.) but that's another story.
>
> Let's take for example MBUF_FAST_FREE.
> In fact, I am not sure that we need it as tx offload flag at all.
> PMD TX-path has all necessary information to decide at run-time can it do
> fast_free() for not:
> At tx_burst() PMD can check are all mbufs satisfy these conditions (same
> mempool, refcnt==1) and update some fields and/or counters inside TXQ to
> reflect it.
> Then, at tx_free() we can use this info to decide between fast_free() and
> normal_free().
> As at tx_burst() we read mbuf fields anyway, impact for this extra step I guess
> would be minimal.
> Yes, most likely, it wouldn't be as fast as with current TX offload flag, or
> conditional compilation approach.
> But it might be still significantly faster then normal_free(), plus such approach
> will be generic and transparent to the user.
IMO, this depends on the philosophy that we want to adopt. I would prefer to make control plane complex for performance gains on the data plane. The performance on the data plane has a multiplying effect due to the ratio of number of cores assigned for data plane vs control plane.
I am not against evaluating alternatives, but the alternative approaches need to have similar (not the same) performance.
>
> Konstantin
^ permalink raw reply [relevance 0%]
* RE: [PATCH] doc: announce support for MACsec in rte_security
2022-06-28 19:08 3% [PATCH] doc: announce support for MACsec in rte_security Akhil Goyal
2022-06-29 3:37 0% ` Hemant Agrawal
@ 2022-06-29 7:40 0% ` Zhang, Roy Fan
2022-07-11 15:00 0% ` Jerin Jacob
1 sibling, 1 reply; 200+ results
From: Zhang, Roy Fan @ 2022-06-29 7:40 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
konstantin.v.ananyev, ferruh.yigit, andrew.rybchenko,
ndabilpuram, vattunuru, matan, jerinj, jiawenwu, Yang, Qiming
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, June 28, 2022 8:08 PM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; anoobj@marvell.com;
> konstantin.v.ananyev@yandex.ru; ferruh.yigit@xilinx.com;
> andrew.rybchenko@oktetlabs.ru; ndabilpuram@marvell.com;
> vattunuru@marvell.com; matan@nvidia.com; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; jerinj@marvell.com; jiawenwu@trustnetic.com;
> Yang, Qiming <qiming.yang@intel.com>; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] doc: announce support for MACsec in rte_security
>
> MACsec support is planned for DPDK 22.11, which would
> result in ABI breakage in some of the rte_security structures.
> This patch is to give deprecation notice for the affected structures.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c53d..1c3bf54d72 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -116,6 +116,11 @@ Deprecation Notices
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
>
> +* security: MACsec support is planned to be added in DPDK 22.11 which
> would
> + result in updates to structures ``rte_security_macsec_xform``,
> + ``rte_security_macsec_stats`` and security capability structure
> + ``rte_security_capability`` to accomodate MACsec capabilities.
> +
> * metrics: The function ``rte_metrics_init`` will have a non-void return
> in order to notify errors instead of calling ``rte_exit``.
>
> --
> 2.25.1
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: announce support for MACsec in rte_security
2022-06-28 19:08 3% [PATCH] doc: announce support for MACsec in rte_security Akhil Goyal
@ 2022-06-29 3:37 0% ` Hemant Agrawal
2022-06-29 7:40 0% ` Zhang, Roy Fan
1 sibling, 0 replies; 200+ results
From: Hemant Agrawal @ 2022-06-29 3:37 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
konstantin.v.ananyev, ferruh.yigit, andrew.rybchenko,
ndabilpuram, vattunuru, matan, roy.fan.zhang, jerinj, jiawenwu,
qiming.yang
On 6/29/2022 12:38 AM, Akhil Goyal wrote:
> MACsec support is planned for DPDK 22.11, which would
> result in ABI breakage in some of the rte_security structures.
> This patch is to give deprecation notice for the affected structures.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c53d..1c3bf54d72 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -116,6 +116,11 @@ Deprecation Notices
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
>
> +* security: MACsec support is planned to be added in DPDK 22.11 which would
> + result in updates to structures ``rte_security_macsec_xform``,
> + ``rte_security_macsec_stats`` and security capability structure
> + ``rte_security_capability`` to accomodate MACsec capabilities.
> +
> * metrics: The function ``rte_metrics_init`` will have a non-void return
> in order to notify errors instead of calling ``rte_exit``.
>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply [relevance 0%]
* [PATCH] doc: announce support for MACsec in rte_security
@ 2022-06-28 19:08 3% Akhil Goyal
2022-06-29 3:37 0% ` Hemant Agrawal
2022-06-29 7:40 0% ` Zhang, Roy Fan
0 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2022-06-28 19:08 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
konstantin.v.ananyev, ferruh.yigit, andrew.rybchenko,
ndabilpuram, vattunuru, matan, roy.fan.zhang, jerinj, jiawenwu,
qiming.yang, Akhil Goyal
MACsec support is planned for DPDK 22.11, which would
result in ABI breakage in some of the rte_security structures.
This patch is to give deprecation notice for the affected structures.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
doc/guides/rel_notes/deprecation.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c53d..1c3bf54d72 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -116,6 +116,11 @@ Deprecation Notices
pointer for the private data to the application which can be attached
to the packet while enqueuing.
+* security: MACsec support is planned to be added in DPDK 22.11 which would
+ result in updates to structures ``rte_security_macsec_xform``,
+ ``rte_security_macsec_stats`` and security capability structure
+ ``rte_security_capability`` to accomodate MACsec capabilities.
+
* metrics: The function ``rte_metrics_init`` will have a non-void return
in order to notify errors instead of calling ``rte_exit``.
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH 11/11] bus: hide bus object
2022-06-28 16:29 0% ` Stephen Hemminger
@ 2022-06-28 17:07 0% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-06-28 17:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Marchand, dev, thomas, bruce.richardson, kevin.laatz,
Parav Pandit, Xueming Li, Hemant Agrawal, Sachin Saxena,
Rosen Xu, Stephen Hemminger, Long Li, Chas Williams,
Min Hu (Connor),
Matan Azrad, Ray Kinsella, Ferruh Yigit, Andrew Rybchenko
On Tue, Jun 28, 2022 at 09:29:05AM -0700, Stephen Hemminger wrote:
> On Tue, 28 Jun 2022 09:22:13 -0700
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
>
> > On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote:
> > > Make rte_bus opaque for non internal users.
> > > This will make extending this object possible without breaking the ABI.
> > >
> > > Introduce a new driver header and move rte_bus definition and helpers.
> > >
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > ---
> >
> > ... snip ...
> >
> > > -struct rte_bus {
> > > - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
> > > - const char *name; /**< Name of the bus */
> > > - rte_bus_scan_t scan; /**< Scan for devices attached to bus */
> > > - rte_bus_probe_t probe; /**< Probe devices on bus */
> > > - rte_bus_find_device_t find_device; /**< Find a device on the bus */
> > > - rte_bus_plug_t plug; /**< Probe single device for drivers */
> > > - rte_bus_unplug_t unplug; /**< Remove single device from driver */
> > > - rte_bus_parse_t parse; /**< Parse a device name */
> > > - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
> > > - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
> > > - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
> > > - struct rte_bus_conf conf; /**< Bus configuration */
> > > - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> > > - rte_dev_iterate_t dev_iterate; /**< Device iterator. */
> > > - rte_bus_hot_unplug_handler_t hot_unplug_handler;
> > > - /**< handle hot-unplug failure on the bus */
> > > - rte_bus_sigbus_handler_t sigbus_handler;
> > > - /**< handle sigbus error on the bus */
> > > -
> > > -};
> >
> > since we're overhauling anyway we could follow suit with a number of the
> > lessons from posix apis e.g. pthread and eliminate typed pointers for a
> > little extra value.
> >
> > > +struct rte_bus;
> > > +struct rte_device;
> >
> > to avoid people tripping over mishandling pointers in/out of the api
> > surface taking the opaque object you could declare opaque handle for the
> > api to operate on instead. it would force the use of a cast in the
> > implementation but would avoid accidental void * of the wrong thing that
> > got cached being passed in. if the cast was really undesirable just
> > whack it under an inline / internal function.
>
> I don't like that because it least to dangerous casts in the internal code.
> Better to keep the the type of the object. As long as the API only passes
> around an pointer to a struct, without exposing the contents of the struct;
> it is safer and easier to debug.
as i mentioned you can use an inline/internal function or even a macro
to hide the cast, you could provide some additional integrity checks
here if desired as a value add.
the fact that you expose that it is a struct is an internal
implementation detail, if truly opaque tomorrow you could convert it
to a simple integer that indexes or enumerates something and prevents
any meaningful interpretation in the application.
when you say it is safer to debug i think you mean for dpdk devs not the
application developer because unless the app developer does something
really gross/dangerous casting they really can't "mishandle" the opaque
object except to use one that isn't initialized at all which we
can detect and handle internally in a general way.
i will however concede there would be slightly more finger work when
debugging dpdk itself since gdb / debugger doesn't automatically infer
type so you end up having to tell gdb what is in the uintptr_t.
anyway just drawing from experience in the driver frameworks we maintain
in windows, i think one of our regrets is that we didn't do this from
day 1 and subsequentl that we initially only used one opaque type
instead of defining separate (not implicitly convertable) types to each
opaque type.
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH 11/11] bus: hide bus object
2022-06-28 16:22 3% ` Tyler Retzlaff
@ 2022-06-28 16:29 0% ` Stephen Hemminger
2022-06-28 17:07 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-28 16:29 UTC (permalink / raw)
To: Tyler Retzlaff
Cc: David Marchand, dev, thomas, bruce.richardson, kevin.laatz,
Parav Pandit, Xueming Li, Hemant Agrawal, Sachin Saxena,
Rosen Xu, Stephen Hemminger, Long Li, Chas Williams,
Min Hu (Connor),
Matan Azrad, Ray Kinsella, Ferruh Yigit, Andrew Rybchenko
On Tue, 28 Jun 2022 09:22:13 -0700
Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote:
> > Make rte_bus opaque for non internal users.
> > This will make extending this object possible without breaking the ABI.
> >
> > Introduce a new driver header and move rte_bus definition and helpers.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
>
> ... snip ...
>
> > -struct rte_bus {
> > - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
> > - const char *name; /**< Name of the bus */
> > - rte_bus_scan_t scan; /**< Scan for devices attached to bus */
> > - rte_bus_probe_t probe; /**< Probe devices on bus */
> > - rte_bus_find_device_t find_device; /**< Find a device on the bus */
> > - rte_bus_plug_t plug; /**< Probe single device for drivers */
> > - rte_bus_unplug_t unplug; /**< Remove single device from driver */
> > - rte_bus_parse_t parse; /**< Parse a device name */
> > - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
> > - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
> > - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
> > - struct rte_bus_conf conf; /**< Bus configuration */
> > - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> > - rte_dev_iterate_t dev_iterate; /**< Device iterator. */
> > - rte_bus_hot_unplug_handler_t hot_unplug_handler;
> > - /**< handle hot-unplug failure on the bus */
> > - rte_bus_sigbus_handler_t sigbus_handler;
> > - /**< handle sigbus error on the bus */
> > -
> > -};
>
> since we're overhauling anyway we could follow suit with a number of the
> lessons from posix apis e.g. pthread and eliminate typed pointers for a
> little extra value.
>
> > +struct rte_bus;
> > +struct rte_device;
>
> to avoid people tripping over mishandling pointers in/out of the api
> surface taking the opaque object you could declare opaque handle for the
> api to operate on instead. it would force the use of a cast in the
> implementation but would avoid accidental void * of the wrong thing that
> got cached being passed in. if the cast was really undesirable just
> whack it under an inline / internal function.
I don't like that because it least to dangerous casts in the internal code.
Better to keep the the type of the object. As long as the API only passes
around an pointer to a struct, without exposing the contents of the struct;
it is safer and easier to debug.
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH 11/11] bus: hide bus object
2022-06-28 14:46 1% ` [RFC PATCH 11/11] bus: hide bus object David Marchand
@ 2022-06-28 16:22 3% ` Tyler Retzlaff
2022-06-28 16:29 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-06-28 16:22 UTC (permalink / raw)
To: David Marchand
Cc: dev, thomas, bruce.richardson, kevin.laatz, Parav Pandit,
Xueming Li, Hemant Agrawal, Sachin Saxena, Rosen Xu,
Stephen Hemminger, Long Li, Chas Williams, Min Hu (Connor),
Matan Azrad, Ray Kinsella, Ferruh Yigit, Andrew Rybchenko
On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote:
> Make rte_bus opaque for non internal users.
> This will make extending this object possible without breaking the ABI.
>
> Introduce a new driver header and move rte_bus definition and helpers.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
... snip ...
> -struct rte_bus {
> - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
> - const char *name; /**< Name of the bus */
> - rte_bus_scan_t scan; /**< Scan for devices attached to bus */
> - rte_bus_probe_t probe; /**< Probe devices on bus */
> - rte_bus_find_device_t find_device; /**< Find a device on the bus */
> - rte_bus_plug_t plug; /**< Probe single device for drivers */
> - rte_bus_unplug_t unplug; /**< Remove single device from driver */
> - rte_bus_parse_t parse; /**< Parse a device name */
> - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
> - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
> - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
> - struct rte_bus_conf conf; /**< Bus configuration */
> - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> - rte_dev_iterate_t dev_iterate; /**< Device iterator. */
> - rte_bus_hot_unplug_handler_t hot_unplug_handler;
> - /**< handle hot-unplug failure on the bus */
> - rte_bus_sigbus_handler_t sigbus_handler;
> - /**< handle sigbus error on the bus */
> -
> -};
since we're overhauling anyway we could follow suit with a number of the
lessons from posix apis e.g. pthread and eliminate typed pointers for a
little extra value.
> +struct rte_bus;
> +struct rte_device;
to avoid people tripping over mishandling pointers in/out of the api
surface taking the opaque object you could declare opaque handle for the
api to operate on instead. it would force the use of a cast in the
implementation but would avoid accidental void * of the wrong thing that
got cached being passed in. if the cast was really undesirable just
whack it under an inline / internal function.
e.g. make the opaque object an explicit type.
struct {
uintptr_t opaque;
} rte_bus_handle_t;
// implementation
rte_bus_handle_t
rte_bus_find(rte_bus_handle_t start,
rte_bus_cmp_t cmp, const void *data)
{
struct rte_bus *bus = (struct rte_bus *)start.opaque;
// do bus things on bus
return {.opaque = whatever};
}
then you will get hard compile time failure if someone messes up
argument passing.
e.g.
void *somerandomp = ...;
...
rte_bus_find(somerandomp, ...); // compile fail
i would actually suggest this wrapping in a struct / handle approach for
any opaque object that is passed over the api surface. the change is
bigger of course...
it has various other advantages when/if we decide to make the bus/driver
surface stable in abi which i understand is not a promise dpdk makes
right now but still we might one day.
anyway, just a suggestion. i like the series either way.
^ permalink raw reply [relevance 3%]
* [RFC PATCH 11/11] bus: hide bus object
2022-06-28 14:46 2% [RFC PATCH 00/11] Bus cleanup for 22.11 David Marchand
@ 2022-06-28 14:46 1% ` David Marchand
2022-06-28 16:22 3% ` Tyler Retzlaff
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2022-06-28 14:46 UTC (permalink / raw)
To: dev
Cc: thomas, bruce.richardson, kevin.laatz, Parav Pandit, Xueming Li,
Hemant Agrawal, Sachin Saxena, Rosen Xu, Stephen Hemminger,
Long Li, Chas Williams, Min Hu (Connor),
Matan Azrad, Ray Kinsella, Ferruh Yigit, Andrew Rybchenko
Make rte_bus opaque for non internal users.
This will make extending this object possible without breaking the ABI.
Introduce a new driver header and move rte_bus definition and helpers.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
app/test/test_devargs.c | 2 +-
app/test/test_vdev.c | 2 +-
drivers/bus/auxiliary/private.h | 2 +-
drivers/bus/dpaa/dpaa_bus.c | 2 +-
drivers/bus/fslmc/private.h | 2 +-
drivers/bus/ifpga/ifpga_bus.c | 2 +-
drivers/bus/pci/private.h | 2 +-
drivers/bus/vdev/vdev.c | 2 +-
drivers/bus/vmbus/private.h | 2 +-
drivers/dma/idxd/idxd_bus.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 2 +-
lib/eal/common/eal_common_bus.c | 2 +-
lib/eal/common/eal_common_dev.c | 2 +-
lib/eal/common/eal_common_devargs.c | 2 +-
lib/eal/common/hotplug_mp.c | 2 +-
lib/eal/include/bus_driver.h | 295 ++++++++++++++++++++++++
lib/eal/include/meson.build | 4 +
lib/eal/include/rte_bus.h | 275 +---------------------
lib/eal/linux/eal_dev.c | 2 +-
lib/eal/version.map | 4 +-
lib/ethdev/rte_ethdev.c | 2 +-
22 files changed, 322 insertions(+), 292 deletions(-)
create mode 100644 lib/eal/include/bus_driver.h
diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c
index ac5bc34c18..0a4c34a1ad 100644
--- a/app/test/test_devargs.c
+++ b/app/test/test_devargs.c
@@ -9,7 +9,7 @@
#include <rte_common.h>
#include <rte_devargs.h>
#include <rte_kvargs.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_class.h>
#include "test.h"
diff --git a/app/test/test_vdev.c b/app/test/test_vdev.c
index 5eeff3106d..1904e76e44 100644
--- a/app/test/test_vdev.c
+++ b/app/test/test_vdev.c
@@ -8,7 +8,7 @@
#include <rte_common.h>
#include <rte_kvargs.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_vdev.h>
#include "test.h"
diff --git a/drivers/bus/auxiliary/private.h b/drivers/bus/auxiliary/private.h
index 06a920114c..7e8ae8c2f9 100644
--- a/drivers/bus/auxiliary/private.h
+++ b/drivers/bus/auxiliary/private.h
@@ -9,7 +9,7 @@
#include <stdio.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include "rte_bus_auxiliary.h"
diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index ad4ea156a6..4f12944470 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -29,7 +29,7 @@
#include <ethdev_driver.h>
#include <rte_malloc.h>
#include <rte_ring.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_mbuf_pool_ops.h>
#include <rte_mbuf_dyn.h>
diff --git a/drivers/bus/fslmc/private.h b/drivers/bus/fslmc/private.h
index 80d4673ca8..f08dc7716b 100644
--- a/drivers/bus/fslmc/private.h
+++ b/drivers/bus/fslmc/private.h
@@ -5,7 +5,7 @@
#ifndef __PRIVATE_H__
#define __PRIVATE_H__
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_fslmc.h>
diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c
index e005f2cb70..a2c2f13cf7 100644
--- a/drivers/bus/ifpga/ifpga_bus.c
+++ b/drivers/bus/ifpga/ifpga_bus.c
@@ -14,7 +14,7 @@
#include <fcntl.h>
#include <rte_errno.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_per_lcore.h>
#include <rte_memory.h>
#include <rte_memzone.h>
diff --git a/drivers/bus/pci/private.h b/drivers/bus/pci/private.h
index 6ccec15655..0cefed5edf 100644
--- a/drivers/bus/pci/private.h
+++ b/drivers/bus/pci/private.h
@@ -8,7 +8,7 @@
#include <stdbool.h>
#include <stdio.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_os_shim.h>
#include <rte_pci.h>
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index a8d8b2327e..dd4e931687 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -12,7 +12,7 @@
#include <rte_eal.h>
#include <rte_dev.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_common.h>
#include <rte_devargs.h>
#include <rte_memory.h>
diff --git a/drivers/bus/vmbus/private.h b/drivers/bus/vmbus/private.h
index 732cb6d583..5205e17a3f 100644
--- a/drivers/bus/vmbus/private.h
+++ b/drivers/bus/vmbus/private.h
@@ -9,7 +9,7 @@
#include <stdbool.h>
#include <sys/uio.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_log.h>
#include <rte_eal_paging.h>
#include <rte_vmbus_reg.h>
diff --git a/drivers/dma/idxd/idxd_bus.c b/drivers/dma/idxd/idxd_bus.c
index 13cb967f6d..e30dcfc281 100644
--- a/drivers/dma/idxd/idxd_bus.c
+++ b/drivers/dma/idxd/idxd_bus.c
@@ -8,7 +8,7 @@
#include <sys/mman.h>
#include <libgen.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_devargs.h>
#include <rte_eal.h>
#include <rte_log.h>
diff --git a/drivers/net/bonding/rte_eth_bond_args.c b/drivers/net/bonding/rte_eth_bond_args.c
index b90757756a..f461bf9207 100644
--- a/drivers/net/bonding/rte_eth_bond_args.c
+++ b/drivers/net/bonding/rte_eth_bond_args.c
@@ -4,7 +4,7 @@
#include <rte_devargs.h>
#include <rte_pci.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_pci.h>
#include <rte_kvargs.h>
diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 2587195168..24edf9f3c4 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -24,7 +24,7 @@
#include <unistd.h>
#include <rte_alarm.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_bus_vdev.h>
#include <rte_common.h>
#include <rte_dev.h>
diff --git a/lib/eal/common/eal_common_bus.c b/lib/eal/common/eal_common_bus.c
index cbf382f967..be64d31b0f 100644
--- a/lib/eal/common/eal_common_bus.c
+++ b/lib/eal/common/eal_common_bus.c
@@ -6,7 +6,7 @@
#include <string.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_debug.h>
#include <rte_string_fns.h>
#include <rte_errno.h>
diff --git a/lib/eal/common/eal_common_dev.c b/lib/eal/common/eal_common_dev.c
index bbaf518570..a366bb3689 100644
--- a/lib/eal/common/eal_common_dev.c
+++ b/lib/eal/common/eal_common_dev.c
@@ -7,7 +7,7 @@
#include <string.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_class.h>
#include <rte_dev.h>
#include <rte_devargs.h>
diff --git a/lib/eal/common/eal_common_devargs.c b/lib/eal/common/eal_common_devargs.c
index fa95c52708..adccfa713f 100644
--- a/lib/eal/common/eal_common_devargs.c
+++ b/lib/eal/common/eal_common_devargs.c
@@ -10,7 +10,7 @@
#include <string.h>
#include <stdarg.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_class.h>
#include <rte_dev.h>
#include <rte_devargs.h>
diff --git a/lib/eal/common/hotplug_mp.c b/lib/eal/common/hotplug_mp.c
index 252f147b6f..9e6eddec92 100644
--- a/lib/eal/common/hotplug_mp.c
+++ b/lib/eal/common/hotplug_mp.c
@@ -3,7 +3,7 @@
*/
#include <string.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_eal.h>
#include <rte_errno.h>
#include <rte_alarm.h>
diff --git a/lib/eal/include/bus_driver.h b/lib/eal/include/bus_driver.h
new file mode 100644
index 0000000000..ac404c3d5e
--- /dev/null
+++ b/lib/eal/include/bus_driver.h
@@ -0,0 +1,295 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2022 Red Hat, Inc.
+ */
+
+#ifndef BUS_DRIVER_H
+#define BUS_DRIVER_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_bus.h>
+#include <rte_compat.h>
+#include <rte_dev.h>
+#include <rte_eal.h>
+#include <rte_tailq.h>
+
+struct rte_device;
+
+/** Double linked list of buses */
+RTE_TAILQ_HEAD(rte_bus_list, rte_bus);
+
+/**
+ * Bus specific scan for devices attached on the bus.
+ * For each bus object, the scan would be responsible for finding devices and
+ * adding them to its private device list.
+ *
+ * A bus should mandatorily implement this method.
+ *
+ * @return
+ * 0 for successful scan
+ * <0 for unsuccessful scan with error value
+ */
+typedef int (*rte_bus_scan_t)(void);
+
+/**
+ * Implementation specific probe function which is responsible for linking
+ * devices on that bus with applicable drivers.
+ *
+ * This is called while iterating over each registered bus.
+ *
+ * @return
+ * 0 for successful probe
+ * !0 for any error while probing
+ */
+typedef int (*rte_bus_probe_t)(void);
+
+/**
+ * Device iterator to find a device on a bus.
+ *
+ * This function returns an rte_device if one of those held by the bus
+ * matches the data passed as parameter.
+ *
+ * If the comparison function returns zero this function should stop iterating
+ * over any more devices. To continue a search the device of a previous search
+ * can be passed via the start parameter.
+ *
+ * @param cmp
+ * Comparison function.
+ *
+ * @param data
+ * Data to compare each device against.
+ *
+ * @param start
+ * starting point for the iteration
+ *
+ * @return
+ * The first device matching the data, NULL if none exists.
+ */
+typedef struct rte_device *
+(*rte_bus_find_device_t)(const struct rte_device *start, rte_dev_cmp_t cmp,
+ const void *data);
+
+/**
+ * Implementation specific probe function which is responsible for linking
+ * devices on that bus with applicable drivers.
+ *
+ * @param dev
+ * Device pointer that was returned by a previous call to find_device.
+ *
+ * @return
+ * 0 on success.
+ * !0 on error.
+ */
+typedef int (*rte_bus_plug_t)(struct rte_device *dev);
+
+/**
+ * Implementation specific remove function which is responsible for unlinking
+ * devices on that bus from assigned driver.
+ *
+ * @param dev
+ * Device pointer that was returned by a previous call to find_device.
+ *
+ * @return
+ * 0 on success.
+ * !0 on error.
+ */
+typedef int (*rte_bus_unplug_t)(struct rte_device *dev);
+
+/**
+ * Bus specific parsing function.
+ * Validates the syntax used in the textual representation of a device,
+ * If the syntax is valid and ``addr`` is not NULL, writes the bus-specific
+ * device representation to ``addr``.
+ *
+ * @param[in] name
+ * device textual description
+ *
+ * @param[out] addr
+ * device information location address, into which parsed info
+ * should be written. If NULL, nothing should be written, which
+ * is not an error.
+ *
+ * @return
+ * 0 if parsing was successful.
+ * !0 for any error.
+ */
+typedef int (*rte_bus_parse_t)(const char *name, void *addr);
+
+/**
+ * Parse bus part of the device arguments.
+ *
+ * The field name of the struct rte_devargs will be set.
+ *
+ * @param da
+ * Pointer to the devargs to parse.
+ *
+ * @return
+ * 0 on successful parsing, otherwise rte_errno is set.
+ * -EINVAL: on parsing error.
+ * -ENODEV: if no key matching a device argument is specified.
+ * -E2BIG: device name is too long.
+ */
+typedef int (*rte_bus_devargs_parse_t)(struct rte_devargs *da);
+
+/**
+ * Device level DMA map function.
+ * After a successful call, the memory segment will be mapped to the
+ * given device.
+ *
+ * @param dev
+ * Device pointer.
+ * @param addr
+ * Virtual address to map.
+ * @param iova
+ * IOVA address to map.
+ * @param len
+ * Length of the memory segment being mapped.
+ *
+ * @return
+ * 0 if mapping was successful.
+ * Negative value and rte_errno is set otherwise.
+ */
+typedef int (*rte_dev_dma_map_t)(struct rte_device *dev, void *addr,
+ uint64_t iova, size_t len);
+
+/**
+ * Device level DMA unmap function.
+ * After a successful call, the memory segment will no longer be
+ * accessible by the given device.
+ *
+ * @param dev
+ * Device pointer.
+ * @param addr
+ * Virtual address to unmap.
+ * @param iova
+ * IOVA address to unmap.
+ * @param len
+ * Length of the memory segment being mapped.
+ *
+ * @return
+ * 0 if un-mapping was successful.
+ * Negative value and rte_errno is set otherwise.
+ */
+typedef int (*rte_dev_dma_unmap_t)(struct rte_device *dev, void *addr,
+ uint64_t iova, size_t len);
+
+/**
+ * Implement a specific hot-unplug handler, which is responsible for
+ * handle the failure when device be hot-unplugged. When the event of
+ * hot-unplug be detected, it could call this function to handle
+ * the hot-unplug failure and avoid app crash.
+ * @param dev
+ * Pointer of the device structure.
+ *
+ * @return
+ * 0 on success.
+ * !0 on error.
+ */
+typedef int (*rte_bus_hot_unplug_handler_t)(struct rte_device *dev);
+
+/**
+ * Implement a specific sigbus handler, which is responsible for handling
+ * the sigbus error which is either original memory error, or specific memory
+ * error that caused of device be hot-unplugged. When sigbus error be captured,
+ * it could call this function to handle sigbus error.
+ * @param failure_addr
+ * Pointer of the fault address of the sigbus error.
+ *
+ * @return
+ * 0 for success handle the sigbus for hot-unplug.
+ * 1 for not process it, because it is a generic sigbus error.
+ * -1 for failed to handle the sigbus for hot-unplug.
+ */
+typedef int (*rte_bus_sigbus_handler_t)(const void *failure_addr);
+
+/**
+ * Bus scan policies
+ */
+enum rte_bus_scan_mode {
+ RTE_BUS_SCAN_UNDEFINED,
+ RTE_BUS_SCAN_ALLOWLIST,
+ RTE_BUS_SCAN_BLOCKLIST,
+};
+
+/**
+ * A structure used to configure bus operations.
+ */
+struct rte_bus_conf {
+ enum rte_bus_scan_mode scan_mode; /**< Scan policy. */
+};
+
+
+/**
+ * Get common iommu class of the all the devices on the bus. The bus may
+ * check that those devices are attached to iommu driver.
+ * If no devices are attached to the bus. The bus may return with don't care
+ * (_DC) value.
+ * Otherwise, The bus will return appropriate _pa or _va iova mode.
+ *
+ * @return
+ * enum rte_iova_mode value.
+ */
+typedef enum rte_iova_mode (*rte_bus_get_iommu_class_t)(void);
+
+/**
+ * A structure describing a generic bus.
+ */
+struct rte_bus {
+ RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
+ const char *name; /**< Name of the bus */
+ rte_bus_scan_t scan; /**< Scan for devices attached to bus */
+ rte_bus_probe_t probe; /**< Probe devices on bus */
+ rte_bus_find_device_t find_device; /**< Find a device on the bus */
+ rte_bus_plug_t plug; /**< Probe single device for drivers */
+ rte_bus_unplug_t unplug; /**< Remove single device from driver */
+ rte_bus_parse_t parse; /**< Parse a device name */
+ rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
+ rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
+ rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
+ struct rte_bus_conf conf; /**< Bus configuration */
+ rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
+ rte_dev_iterate_t dev_iterate; /**< Device iterator. */
+ rte_bus_hot_unplug_handler_t hot_unplug_handler;
+ /**< handle hot-unplug failure on the bus */
+ rte_bus_sigbus_handler_t sigbus_handler;
+ /**< handle sigbus error on the bus */
+};
+
+/**
+ * Register a Bus handler.
+ *
+ * @param bus
+ * A pointer to a rte_bus structure describing the bus
+ * to be registered.
+ */
+__rte_internal
+void rte_bus_register(struct rte_bus *bus);
+
+/**
+ * Helper for Bus registration.
+ * The constructor has higher priority than PMD constructors.
+ */
+#define RTE_REGISTER_BUS(nm, bus) \
+RTE_INIT_PRIO(businitfn_ ##nm, BUS) \
+{\
+ (bus).name = RTE_STR(nm);\
+ rte_bus_register(&bus); \
+}
+
+/**
+ * Unregister a Bus handler.
+ *
+ * @param bus
+ * A pointer to a rte_bus structure describing the bus
+ * to be unregistered.
+ */
+__rte_internal
+void rte_bus_unregister(struct rte_bus *bus);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* BUS_DRIVER_H */
diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
index fd6e844224..77d8621a51 100644
--- a/lib/eal/include/meson.build
+++ b/lib/eal/include/meson.build
@@ -55,6 +55,10 @@ headers += files(
'rte_vfio.h',
)
+driver_sdk_headers = files(
+ 'bus_driver.h',
+)
+
# special case install the generic headers, since they go in a subdir
generic_headers = files(
'generic/rte_atomic.h',
diff --git a/lib/eal/include/rte_bus.h b/lib/eal/include/rte_bus.h
index 9b70f2f7b2..1b08407e53 100644
--- a/lib/eal/include/rte_bus.h
+++ b/lib/eal/include/rte_bus.h
@@ -20,251 +20,11 @@ extern "C" {
#include <stdio.h>
-#include <rte_dev.h>
+#include <rte_compat.h>
#include <rte_eal.h>
-#include <rte_log.h>
-/** Double linked list of buses */
-RTE_TAILQ_HEAD(rte_bus_list, rte_bus);
-
-/**
- * Bus specific scan for devices attached on the bus.
- * For each bus object, the scan would be responsible for finding devices and
- * adding them to its private device list.
- *
- * A bus should mandatorily implement this method.
- *
- * @return
- * 0 for successful scan
- * <0 for unsuccessful scan with error value
- */
-typedef int (*rte_bus_scan_t)(void);
-
-/**
- * Implementation specific probe function which is responsible for linking
- * devices on that bus with applicable drivers.
- *
- * This is called while iterating over each registered bus.
- *
- * @return
- * 0 for successful probe
- * !0 for any error while probing
- */
-typedef int (*rte_bus_probe_t)(void);
-
-/**
- * Device iterator to find a device on a bus.
- *
- * This function returns an rte_device if one of those held by the bus
- * matches the data passed as parameter.
- *
- * If the comparison function returns zero this function should stop iterating
- * over any more devices. To continue a search the device of a previous search
- * can be passed via the start parameter.
- *
- * @param cmp
- * Comparison function.
- *
- * @param data
- * Data to compare each device against.
- *
- * @param start
- * starting point for the iteration
- *
- * @return
- * The first device matching the data, NULL if none exists.
- */
-typedef struct rte_device *
-(*rte_bus_find_device_t)(const struct rte_device *start, rte_dev_cmp_t cmp,
- const void *data);
-
-/**
- * Implementation specific probe function which is responsible for linking
- * devices on that bus with applicable drivers.
- *
- * @param dev
- * Device pointer that was returned by a previous call to find_device.
- *
- * @return
- * 0 on success.
- * !0 on error.
- */
-typedef int (*rte_bus_plug_t)(struct rte_device *dev);
-
-/**
- * Implementation specific remove function which is responsible for unlinking
- * devices on that bus from assigned driver.
- *
- * @param dev
- * Device pointer that was returned by a previous call to find_device.
- *
- * @return
- * 0 on success.
- * !0 on error.
- */
-typedef int (*rte_bus_unplug_t)(struct rte_device *dev);
-
-/**
- * Bus specific parsing function.
- * Validates the syntax used in the textual representation of a device,
- * If the syntax is valid and ``addr`` is not NULL, writes the bus-specific
- * device representation to ``addr``.
- *
- * @param[in] name
- * device textual description
- *
- * @param[out] addr
- * device information location address, into which parsed info
- * should be written. If NULL, nothing should be written, which
- * is not an error.
- *
- * @return
- * 0 if parsing was successful.
- * !0 for any error.
- */
-typedef int (*rte_bus_parse_t)(const char *name, void *addr);
-
-/**
- * Parse bus part of the device arguments.
- *
- * The field name of the struct rte_devargs will be set.
- *
- * @param da
- * Pointer to the devargs to parse.
- *
- * @return
- * 0 on successful parsing, otherwise rte_errno is set.
- * -EINVAL: on parsing error.
- * -ENODEV: if no key matching a device argument is specified.
- * -E2BIG: device name is too long.
- */
-typedef int (*rte_bus_devargs_parse_t)(struct rte_devargs *da);
-
-/**
- * Device level DMA map function.
- * After a successful call, the memory segment will be mapped to the
- * given device.
- *
- * @param dev
- * Device pointer.
- * @param addr
- * Virtual address to map.
- * @param iova
- * IOVA address to map.
- * @param len
- * Length of the memory segment being mapped.
- *
- * @return
- * 0 if mapping was successful.
- * Negative value and rte_errno is set otherwise.
- */
-typedef int (*rte_dev_dma_map_t)(struct rte_device *dev, void *addr,
- uint64_t iova, size_t len);
-
-/**
- * Device level DMA unmap function.
- * After a successful call, the memory segment will no longer be
- * accessible by the given device.
- *
- * @param dev
- * Device pointer.
- * @param addr
- * Virtual address to unmap.
- * @param iova
- * IOVA address to unmap.
- * @param len
- * Length of the memory segment being mapped.
- *
- * @return
- * 0 if un-mapping was successful.
- * Negative value and rte_errno is set otherwise.
- */
-typedef int (*rte_dev_dma_unmap_t)(struct rte_device *dev, void *addr,
- uint64_t iova, size_t len);
-
-/**
- * Implement a specific hot-unplug handler, which is responsible for
- * handle the failure when device be hot-unplugged. When the event of
- * hot-unplug be detected, it could call this function to handle
- * the hot-unplug failure and avoid app crash.
- * @param dev
- * Pointer of the device structure.
- *
- * @return
- * 0 on success.
- * !0 on error.
- */
-typedef int (*rte_bus_hot_unplug_handler_t)(struct rte_device *dev);
-
-/**
- * Implement a specific sigbus handler, which is responsible for handling
- * the sigbus error which is either original memory error, or specific memory
- * error that caused of device be hot-unplugged. When sigbus error be captured,
- * it could call this function to handle sigbus error.
- * @param failure_addr
- * Pointer of the fault address of the sigbus error.
- *
- * @return
- * 0 for success handle the sigbus for hot-unplug.
- * 1 for not process it, because it is a generic sigbus error.
- * -1 for failed to handle the sigbus for hot-unplug.
- */
-typedef int (*rte_bus_sigbus_handler_t)(const void *failure_addr);
-
-/**
- * Bus scan policies
- */
-enum rte_bus_scan_mode {
- RTE_BUS_SCAN_UNDEFINED,
- RTE_BUS_SCAN_ALLOWLIST,
- RTE_BUS_SCAN_BLOCKLIST,
-};
-
-/**
- * A structure used to configure bus operations.
- */
-struct rte_bus_conf {
- enum rte_bus_scan_mode scan_mode; /**< Scan policy. */
-};
-
-
-/**
- * Get common iommu class of the all the devices on the bus. The bus may
- * check that those devices are attached to iommu driver.
- * If no devices are attached to the bus. The bus may return with don't care
- * (_DC) value.
- * Otherwise, The bus will return appropriate _pa or _va iova mode.
- *
- * @return
- * enum rte_iova_mode value.
- */
-typedef enum rte_iova_mode (*rte_bus_get_iommu_class_t)(void);
-
-
-/**
- * A structure describing a generic bus.
- */
-struct rte_bus {
- RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
- const char *name; /**< Name of the bus */
- rte_bus_scan_t scan; /**< Scan for devices attached to bus */
- rte_bus_probe_t probe; /**< Probe devices on bus */
- rte_bus_find_device_t find_device; /**< Find a device on the bus */
- rte_bus_plug_t plug; /**< Probe single device for drivers */
- rte_bus_unplug_t unplug; /**< Remove single device from driver */
- rte_bus_parse_t parse; /**< Parse a device name */
- rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
- rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
- rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
- struct rte_bus_conf conf; /**< Bus configuration */
- rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
- rte_dev_iterate_t dev_iterate; /**< Device iterator. */
- rte_bus_hot_unplug_handler_t hot_unplug_handler;
- /**< handle hot-unplug failure on the bus */
- rte_bus_sigbus_handler_t sigbus_handler;
- /**< handle sigbus error on the bus */
-
-};
+struct rte_bus;
+struct rte_device;
/**
* @warning
@@ -279,24 +39,6 @@ struct rte_bus {
__rte_experimental
const char *rte_bus_name(const struct rte_bus *bus);
-/**
- * Register a Bus handler.
- *
- * @param bus
- * A pointer to a rte_bus structure describing the bus
- * to be registered.
- */
-void rte_bus_register(struct rte_bus *bus);
-
-/**
- * Unregister a Bus handler.
- *
- * @param bus
- * A pointer to a rte_bus structure describing the bus
- * to be unregistered.
- */
-void rte_bus_unregister(struct rte_bus *bus);
-
/**
* Scan all the buses.
*
@@ -386,17 +128,6 @@ struct rte_bus *rte_bus_find_by_name(const char *busname);
*/
enum rte_iova_mode rte_bus_get_iommu_class(void);
-/**
- * Helper for Bus registration.
- * The constructor has higher priority than PMD constructors.
- */
-#define RTE_REGISTER_BUS(nm, bus) \
-RTE_INIT_PRIO(businitfn_ ##nm, BUS) \
-{\
- (bus).name = RTE_STR(nm);\
- rte_bus_register(&bus); \
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/eal/linux/eal_dev.c b/lib/eal/linux/eal_dev.c
index 02ae1cde29..098a2c3076 100644
--- a/lib/eal/linux/eal_dev.c
+++ b/lib/eal/linux/eal_dev.c
@@ -13,7 +13,7 @@
#include <rte_dev.h>
#include <rte_interrupts.h>
#include <rte_alarm.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_spinlock.h>
#include <rte_errno.h>
diff --git a/lib/eal/version.map b/lib/eal/version.map
index 6f713c987d..48c8a2f511 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -13,9 +13,7 @@ DPDK_22 {
rte_bus_find_by_name;
rte_bus_get_iommu_class;
rte_bus_probe;
- rte_bus_register;
rte_bus_scan;
- rte_bus_unregister;
rte_calloc;
rte_calloc_socket;
rte_cpu_get_flag_enabled;
@@ -432,6 +430,8 @@ EXPERIMENTAL {
INTERNAL {
global:
+ rte_bus_register;
+ rte_bus_unregister;
rte_eal_get_baseaddr;
rte_firmware_read;
rte_intr_allow_others;
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index c94d6573d5..6679bd8276 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -11,7 +11,7 @@
#include <string.h>
#include <sys/queue.h>
-#include <rte_bus.h>
+#include <bus_driver.h>
#include <rte_log.h>
#include <rte_interrupts.h>
#include <rte_memcpy.h>
--
2.36.1
^ permalink raw reply [relevance 1%]
* [RFC PATCH 00/11] Bus cleanup for 22.11
@ 2022-06-28 14:46 2% David Marchand
2022-06-28 14:46 1% ` [RFC PATCH 11/11] bus: hide bus object David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2022-06-28 14:46 UTC (permalink / raw)
To: dev; +Cc: thomas, bruce.richardson, kevin.laatz
This is a PoC for hiding the rte_bus object and mark associated API
as internal.
A good amount of the patches are preparation work on rte_bus.h,
rte_dev.h, rte_devargs.h and rte_eal.h headers, removing dependencies
between them. This is something I had in store for some time, maybe I
should have dropped it from the PoC, but I think those cleanups are
worth it in any case.
The last two patches do the actual job: add accessors and make the
rte_bus object opaque to non internal users.
Disclaimer: this series is a bit rushed (I brute forced compilation
tests in GHA so that it passes between patches, but there still may be
something broken...).
Not surprisingly, the ABI check in the CI is expected to fail.
Comments welcome.
I also hope we can do the same work on other generic objects
(rte_driver, rte_device), but this is another story.
--
David Marchand
David Marchand (11):
common/mlx5: rework check on driver registration
raw/ifpga: remove PCI bus accessor
dev: hide debug messages in device iterator
dev: move unrelated macros from header
devargs: remove dependency on bus header
bus: remove unneded inclusion of bus header
bus: move IOVA definition from header
drivers/bus: remove back reference to bus objects
drivers/bus: hide specific structures
bus: introduce accessors
bus: hide bus object
app/test-compress-perf/comp_perf_options.h | 2 +
app/test-pmd/config.c | 10 +-
app/test-pmd/testpmd.c | 4 +-
app/test-pmd/testpmd.h | 5 +-
app/test/test_devargs.c | 6 +-
app/test/test_kni.c | 7 +-
app/test/test_vdev.c | 1 +
drivers/bus/auxiliary/auxiliary_common.c | 2 -
drivers/bus/auxiliary/linux/auxiliary.c | 1 -
drivers/bus/auxiliary/private.h | 30 +-
drivers/bus/auxiliary/rte_bus_auxiliary.h | 5 -
drivers/bus/dpaa/dpaa_bus.c | 20 +-
drivers/bus/dpaa/rte_dpaa_bus.h | 14 -
drivers/bus/fslmc/fslmc_bus.c | 11 +-
drivers/bus/fslmc/fslmc_vfio.c | 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dprc.c | 1 +
drivers/bus/fslmc/private.h | 27 ++
drivers/bus/fslmc/rte_fslmc.h | 21 --
drivers/bus/ifpga/ifpga_bus.c | 2 +-
drivers/bus/ifpga/ifpga_common.c | 1 -
drivers/bus/ifpga/rte_bus_ifpga.h | 1 -
drivers/bus/pci/bsd/pci.c | 2 -
drivers/bus/pci/linux/pci.c | 3 -
drivers/bus/pci/pci_common.c | 2 -
drivers/bus/pci/private.h | 18 +-
drivers/bus/pci/rte_bus_pci.h | 23 --
drivers/bus/pci/windows/pci.c | 1 +
drivers/bus/pci/windows/pci_netuio.c | 1 +
drivers/bus/vdev/vdev.c | 2 +-
drivers/bus/vdev/vdev_params.c | 1 -
drivers/bus/vmbus/linux/vmbus_uio.c | 1 -
drivers/bus/vmbus/private.h | 18 ++
drivers/bus/vmbus/rte_bus_vmbus.h | 21 --
drivers/bus/vmbus/vmbus_bufring.c | 1 -
drivers/bus/vmbus/vmbus_channel.c | 1 -
drivers/bus/vmbus/vmbus_common.c | 3 -
drivers/bus/vmbus/vmbus_common_uio.c | 1 -
.../common/mlx5/linux/mlx5_common_auxiliary.c | 10 +-
drivers/common/mlx5/mlx5_common_pci.c | 3 +-
drivers/common/qat/qat_device.c | 1 +
drivers/compress/qat/qat_comp_pmd.c | 1 +
drivers/compress/zlib/zlib_pmd_ops.c | 1 +
.../scheduler/rte_cryptodev_scheduler.c | 1 +
drivers/crypto/virtio/virtio_pci.c | 1 -
drivers/dma/cnxk/cnxk_dmadev.c | 1 -
drivers/dma/idxd/idxd_bus.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 1 +
drivers/net/failsafe/failsafe.c | 3 +-
drivers/net/failsafe/failsafe_eal.c | 3 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 1 +
drivers/net/liquidio/lio_ethdev.c | 1 +
drivers/net/mlx5/linux/mlx5_os.c | 3 +-
drivers/net/netvsc/hn_ethdev.c | 5 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 2 +-
drivers/raw/ifpga/ifpga_rawdev.c | 7 +-
drivers/raw/ifpga/ifpga_rawdev.h | 1 -
drivers/raw/ifpga/rte_pmd_ifpga.c | 6 -
drivers/raw/ifpga/rte_pmd_ifpga.h | 10 -
drivers/raw/ifpga/version.map | 1 -
examples/ethtool/lib/rte_ethtool.c | 4 +-
examples/ip_pipeline/kni.c | 3 +-
examples/multi_process/hotplug_mp/commands.c | 6 +-
lib/compressdev/rte_compressdev.c | 2 +
lib/compressdev/rte_compressdev_pmd.c | 1 +
lib/cryptodev/cryptodev_pmd.c | 2 +
lib/dmadev/rte_dmadev.c | 1 +
lib/eal/common/eal_common_bus.c | 28 +-
lib/eal/common/eal_common_dev.c | 15 +-
lib/eal/common/eal_common_devargs.c | 14 +-
lib/eal/common/eal_thread.h | 1 +
lib/eal/common/hotplug_mp.c | 9 +-
lib/eal/include/bus_driver.h | 295 ++++++++++++++++++
lib/eal/include/meson.build | 4 +
lib/eal/include/rte_bus.h | 290 +----------------
lib/eal/include/rte_common.h | 11 +
lib/eal/include/rte_dev.h | 11 -
lib/eal/include/rte_devargs.h | 4 +-
lib/eal/include/rte_eal.h | 15 +-
lib/eal/include/rte_lcore.h | 2 +
lib/eal/linux/eal_dev.c | 2 +-
lib/eal/version.map | 7 +-
lib/eal/windows/eal.c | 1 +
lib/ethdev/ethdev_driver.c | 1 +
lib/ethdev/ethdev_pci.h | 1 +
lib/ethdev/rte_ethdev.c | 11 +-
lib/mempool/rte_mempool_ops.c | 1 +
lib/pcapng/rte_pcapng.c | 3 +-
lib/regexdev/rte_regexdev.c | 1 +
lib/security/rte_security.c | 1 +
lib/vhost/vdpa.c | 1 +
90 files changed, 554 insertions(+), 531 deletions(-)
create mode 100644 drivers/bus/fslmc/private.h
create mode 100644 lib/eal/include/bus_driver.h
--
2.36.1
^ permalink raw reply [relevance 2%]
* [PATCH v3 1/7] bbdev: allow operation type enum for growth
2022-06-28 1:35 4% ` [PATCH v3 0/7] bbdev changes for 22.11 Nicolas Chautru
@ 2022-06-28 1:35 3% ` Nicolas Chautru
0 siblings, 0 replies; 200+ results
From: Nicolas Chautru @ 2022-06-28 1:35 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Updating the enum for rte_bbdev_op_type
to allow to keep ABI compatible for enum insertion
while adding padded maximum value for array need.
Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
RTE_BBDEV_OP_TYPE_PADDED_MAX.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 ++--
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 9 +++++----
lib/bbdev/rte_bbdev_op.h | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index ac06d73..1063f6e 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
rte_mempool_free(mp);
TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
- RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
+ RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) == NULL,
"Failed test for rte_bbdev_op_pool_create: "
"returned value is not NULL for invalid type");
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index fad3b1e..1abda2d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device *ad,
/* Find capabilities */
const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
- for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
+ do {
if (cap->type == test_vector.op_type) {
capabilities = cap;
break;
}
cap++;
- }
+ } while (cap->type != RTE_BBDEV_OP_NONE);
TEST_ASSERT_NOT_NULL(capabilities,
"Couldn't find capabilities");
diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fc7e8b8..ef0ba76 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
void *sigret;
struct app_config_params app_params = def_app_config;
struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
- struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
+ struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
struct stats_lcore_params stats_lcore;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index aaee7b7..22bd894 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -23,6 +23,8 @@
#define DEV_NAME "BBDEV"
+/* Number of supported operation types */
+#define BBDEV_OP_TYPE_COUNT 5
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -890,10 +892,10 @@ struct rte_mempool *
return NULL;
}
- if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
+ if (type >= BBDEV_OP_TYPE_COUNT) {
rte_bbdev_log(ERR,
"Invalid op type (%u), should be less than %u",
- type, RTE_BBDEV_OP_TYPE_COUNT);
+ type, BBDEV_OP_TYPE_COUNT);
return NULL;
}
@@ -1122,10 +1124,9 @@ struct rte_mempool *
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
"RTE_BBDEV_OP_LDPC_DEC",
- "RTE_BBDEV_OP_LDPC_ENC",
};
- if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
+ if (op_type < BBDEV_OP_TYPE_COUNT)
return op_types[op_type];
rte_bbdev_log(ERR, "Invalid operation type");
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 6d56133..cd82418 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
- RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
+ RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number including padding */
};
/** Bit indexes of possible errors reported through status field */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v3 0/7] bbdev changes for 22.11
@ 2022-06-28 1:35 4% ` Nicolas Chautru
2022-06-28 1:35 3% ` [PATCH v3 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-07-06 0:23 4% ` [PATCH v4 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-07-06 23:28 4% ` [PATCH v5 0/7] bbdev changes for 22.11 Nicolas Chautru
2 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-28 1:35 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
v3: update to device status info to also use padded size for the related array.
Adding also 2 additionals commits to allow the API struc to expose more information related to queues
corner cases/warning as well as an optional rw lock.
Hemant, Maxime, this is planned for DPDK 21.11 but would like review/ack early is possible
to get this applied earlier and due to time off this summer.
Thanks
Nic
--
Hi,
Agregating together in a single serie a number of bbdev api changes previously submitted over the last few months and all targeted for 22.11 (4 different series detailed below). Related deprecation notice being pushed in 22.07 in parallel.
* bbdev: add device status info
* bbdev: add new operation for FFT processing
* bbdev: add device info on queue topology
* bbdev: allow operation type enum for growth
v2: Update to the RTE_BBDEV_COUNT removal based on feedback from Thomas/Stephen : rejecting out of range op type and adjusting the new name for the padded maximum value used for fixed size arrays.
---
Previous cover letters agregated below:
* bbdev: add device status info
https://patches.dpdk.org/project/dpdk/list/?series=23367
The updated structure will allow PMDs to expose through info_get what be may the status of the underlying accelerator, notably in case an HW error event having happened.
* bbdev: add new operation for FFT processing
https://patches.dpdk.org/project/dpdk/list/?series=22111
This contribution adds a new operation type to the existing ones already supported by the bbdev PMDs.
This set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental).
I plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test.
* bbdev: add device info on queue topology
https://patches.dpdk.org/project/dpdk/list/?series=22076
Addressing an historical concern that the device info struct only
imperfectly captured what queues are available on the device
(number of operation and priority). This ended up being an iterative
process for application to find each queue could be configured.
ie. the gap was captured as technical debt previously in comments
/* This isn't ideal because it reports the maximum number of queues but
* does not provide info on how many can be uplink/downlink or different
* priorities
*/
This is now being exposed explictly based on the what the device actually
supports using the existing info_get api
* bbdev: allow operation type enum for growth
https://patches.dpdk.org/project/dpdk/list/?series=23509
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Nicolas Chautru (7):
bbdev: allow operation type enum for growth
bbdev: add device status info
bbdev: add device info on queue topology
drivers/baseband: update PMDs to expose queue per operation
bbdev: add new operation for FFT processing
bbdev: add queue related warning and status information
bbdev: add a lock option for enqueue/dequeue operation
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 6 +-
doc/guides/prog_guide/bbdev.rst | 130 ++++++++++++++++++
drivers/baseband/acc100/rte_acc100_pmd.c | 30 ++--
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 9 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 9 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 10 +-
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 12 ++
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 42 +++++-
lib/bbdev/rte_bbdev.h | 136 ++++++++++++++++++-
lib/bbdev/rte_bbdev_op.h | 151 ++++++++++++++++++++-
lib/bbdev/version.map | 10 ++
14 files changed, 527 insertions(+), 23 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-17 16:13 0% ` Chautru, Nicolas
@ 2022-06-27 20:47 0% ` Chautru, Nicolas
2022-06-30 14:52 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2022-06-27 20:47 UTC (permalink / raw)
To: dev, thomas
Cc: trix, Kinsella, Ray, Richardson, Bruce, hemant.agrawal,
david.marchand, stephen, Maxime Coquelin, gakhil
Hi Thomas,
Kind reminder on this one.
Thanks
Nic
> -----Original Message-----
> From: Chautru, Nicolas
> Sent: Friday, June 17, 2022 9:13 AM
> To: dev@dpdk.org; thomas@monjalon.net
> Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>; Richardson,
> Bruce <bruce.richardson@intel.com>; hemant.agrawal@nxp.com;
> david.marchand@redhat.com; stephen@networkplumber.org; Maxime
> Coquelin <maxime.coquelin@redhat.com>; gakhil@marvell.com
> Subject: RE: [PATCH v4] doc: announce changes in bbdev related to enum
> extension
>
> Hi Thomas,
> Can this one be applied based on your review?
> Thanks
> Nic
>
> > -----Original Message-----
> > From: Maxime Coquelin <maxime.coquelin@redhat.com>
> > Sent: Thursday, June 9, 2022 12:54 AM
> > To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> > gakhil@marvell.com; thomas@monjalon.net
> > Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>;
> > Richardson, Bruce <bruce.richardson@intel.com>;
> > hemant.agrawal@nxp.com; david.marchand@redhat.com;
> > stephen@networkplumber.org
> > Subject: Re: [PATCH v4] doc: announce changes in bbdev related to enum
> > extension
> >
> > Hi Nicolas,
> >
> > On 6/9/22 02:34, Nicolas Chautru wrote:
> > > Intent to resolve in DPDK 22.11 historical usage which prevents
> > > graceful extension of enum and API without troublesome ABI breakage
> > > as well as extending API RTE_BBDEV_OP_FFT for new operation type in
> > > bbdev as well as other new members in existing structures.
> > >
> > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > ---
> > > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > b/doc/guides/rel_notes/deprecation.rst
> > > index 4e5b23c..c8ab1ec 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -112,6 +112,17 @@ Deprecation Notices
> > > session and the private data of session. An opaque pointer can be
> exposed
> > > directly to application which can be attached to the ``rte_crypto_op``.
> > >
> > > +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the
> > > +``rte_bbdev_op_type``
> > > + enum will be deprecated and instead use fixed array size when
> > > +required to allow for
> > > + future enum extension.
> > > + Will extend API to support new operation type
> > > +``RTE_BBDEV_OP_FFT`` as per this
> > > + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
> > > + New members will be added in ``rte_bbdev_driver_info`` to expose
> > > +PMD queue topology inspired
> > > + by this RFC
> > > +https://patches.dpdk.org/project/dpdk/list/?series=22076
> > > + New member will be added in ``rte_bbdev_driver_info`` to expose
> > > +the device status as per
> > > + this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
> > > + This should be updated in DPDK 22.11.
> > > +
> > > * security: Hide structure ``rte_security_session`` and expose an opaque
> > > pointer for the private data to the application which can be attached
> > > to the packet while enqueuing.
> >
> > Thanks for rewording the notice.
> >
> > Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> >
> > Maxime
^ permalink raw reply [relevance 0%]
* [Bug 1042] [dpdk-22.07](ABI) unit_tests_eal/link_bonding_rssconf: link_bonding_rssconf_autotest test failed
@ 2022-06-27 9:32 4% bugzilla
0 siblings, 0 replies; 200+ results
From: bugzilla @ 2022-06-27 9:32 UTC (permalink / raw)
To: dev
https://bugs.dpdk.org/show_bug.cgi?id=1042
Bug ID: 1042
Summary: [dpdk-22.07](ABI) unit_tests_eal/link_bonding_rssconf:
link_bonding_rssconf_autotest test failed
Product: DPDK
Version: 22.03
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: examples
Assignee: dev@dpdk.org
Reporter: weix.ling@intel.com
Target Milestone: ---
[Environment]
DPDK version: Use make showversion or for a non-released version: git remote -v
&& git show-ref --heads
commit 7cac53f205ebd04d8ebd3ee6a9dd84f698d4ada3 (HEAD -> main, tag: v22.07-rc2,
origin/main, origin/HEAD)
Author: Thomas Monjalon <thomas@monjalon.net>
Date: Mon Jun 27 04:03:44 2022 +0200 version: 22.07-rc2
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Other software versions: N/A
OS: Red Hat Enterprise Linux 8.4 (Ootpa)/Linux 4.18.0-305.el8.x86_64
Compiler: gcc version 8.5.0 20210514 (Red Hat 8.5.0-4) (GCC)
Hardware platform: Intel(R) Xeon(R) Platinum 8180 CPU @ 2.50GHz
NIC hardware: Intel Ethernet Controller XL710 for 40GbE QSFP+ 1583
NIC firmware: i40e-4.18.0-305.el8.x86_64/8.70 0x8000c40f 1.3179.0
[Test Setup]
Steps to reproduce
List the steps to reproduce the issue.
1. Build the DPDK-22.07-rc2 lib with the following steps:
Note: /tmp/dpdk.tar.gz is the DPDK-22.07-rc2 packet.
tar zxfm /tmp/dpdk.tar.gz -C ~
cd ~/dpdk
cd .. && rm -rf dpdk_lib && mv dpdk dpdk_lib && cd dpdk_lib
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=shared
x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
rm -rf /root/tmp/dpdk_share_lib
DESTDIR=/root/tmp/dpdk_share_lib ninja -C x86_64-native-linuxapp-gcc -j 110
install
rm -rf /root/shared_lib_dpdk
mv /root/tmp/dpdk_share_lib/usr/local/lib /root/shared_lib_dpdk
2. Build the DPDK-21.11 APP with the following steps:
Note: /tmp/dpdk_abi.tar.gz is the DPDK-21.11 packet.
cd ..
tar zxf /tmp/dpdk_abi.tar.gz -C ~
cd ~/dpdk/
rm -rf x86_64-native-linuxapp-gcc
CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=shared
x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
# delete the DPDK-21.11 target/lib and drivers directory
rm -rf x86_64-native-linuxapp-gcc/lib
rm -rf x86_64-native-linuxapp-gcc/drivers
3. Bind 2 NIC port to vfio-pci driver:
dpdk-devbind.py --force --bind=vfio-pci 0000:18:00.0 0000:18:00.1
4. Start dpdk-test APP:
x86_64-native-linuxapp-gcc/app/test/dpdk-test -l 1-4 -n 4 -a 0000:18:00.0 -a
0000:18:00.1 --file-prefix=dpdk_63552_20220624173253 -d
/root/shared_lib_dpdk
5. Execute `link_bonding_rssconf_autotest` command to test:
RTE>>link_bonding_rssconf_autotest
Show the output from the previous commands.
[root@abi80 dpdk]# x86_64-native-linuxapp-gcc/app/test/dpdk-test -l 1-4 -n 4 -a
0000:18:00.0 -a 0000:18:00.1 --file-prefix=dpdk_63552_20220624173253 -d
/root/shared_lib_dpdk
EAL: Detected CPU lcores: 112
EAL: Detected NUMA nodes: 2
EAL: Detected shared linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/dpdk_63552_20220624173253/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs found
for that size
EAL: VFIO support initialized
EAL: Using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(1)
EAL: Ignore mapping IO port bar(4)
EAL: Probe PCI driver: net_i40e (8086:1583) device: 0000:18:00.0 (socket 0)
i40e_GLQF_reg_init(): i40e device 0000:18:00.0 changed global register
[0x002689a0]. original: 0x00000000, new: 0x00000029
i40e_GLQF_reg_init(): i40e device 0000:18:00.0 changed global register
[0x00268ca4]. original: 0x00001840, new: 0x00009420
i40e_aq_debug_write_global_register(): i40e device 0000:18:00.0 changed global
register [0x0026c7a0]. original: 0xa8, after: 0x28
EAL: Ignore mapping IO port bar(1)
EAL: Ignore mapping IO port bar(4)
EAL: Probe PCI driver: net_i40e (8086:1583) device: 0000:18:00.1 (socket 0)
TELEMETRY: No legacy callbacks, legacy socket not created
APP: HPET is not enabled, using TSC as default timer
RTE>>link_bonding_rssconf_autotest
+ ------------------------------------------------------- +
+ Test Suite : RSS Dynamic Configuration for Bonding Unit Test Suite
+ ------------------------------------------------------- +
+ TestCase [ 0] : test_setup succeeded
Device with port_id=2 already stopped
Device with port_id=3 already stopped
Device with port_id=4 already stopped
Device with port_id=5 already stopped
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 2: Operation not supported
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 3: Operation not supported
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 4: Operation not supported
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 5: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 2: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 3: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 4: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 5: Operation not supported
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
bond_ethdev_rss_hash_update(3139) - rss_key will be truncated
Port 2 must be stopped to allow reset
Port 2 must be stopped to allow reset
Port 3 must be stopped to allow reset
Port 4 must be stopped to allow reset
Port 5 must be stopped to allow reset
+ TestCase [ 1] : test_rss succeeded
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 2: Operation not supported
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 3: Operation not supported
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 4: Operation not supported
bond_ethdev_promiscuous_disable(2684) - Failed to disable promiscuous mode for
port 5: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 2: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 3: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 4: Operation not supported
bond_ethdev_allmulticast_disable(2830) - Failed to disable allmulti mode for
port 5: Operation not supported
Multi-queue RSS mode isn't enabled.
EAL: Test assert test_propagate line 350 failed: Cannot set slaves hash
function
EAL: Test assert test_rss_lazy line 496 failed: Propagation test failed
Port 2 must be stopped to allow reset
Port 3 must be stopped to allow reset
Port 4 must be stopped to allow reset
Port 5 must be stopped to allow reset
+ TestCase [ 2] : test_rss_lazy failed
Device with port_id=6 already stopped
+ ------------------------------------------------------- +
+ Test Suite Summary : RSS Dynamic Configuration for Bonding Unit Test Suite
+ ------------------------------------------------------- +
+ Tests Total : 3
+ Tests Skipped : 0
+ Tests Executed : 3
+ Tests Unsupported: 0
+ Tests Passed : 2
+ Tests Failed : 1
+ ------------------------------------------------------- +
Test Failed
RTE>>
[Expected Result]
Explain what is the expected result in text or as an example output:
[root@abi80 dpdk]# x86_64-native-linuxapp-gcc/app/test/dpdk-test -l 1-4 -n 4 -a
0000:18:00.0 -a 0000:18:00.1 --file-prefix=dpdk_63552_20220624173253 -d
/root/shared_lib_dpdk EAL: Detected CPU lcores: 112
EAL: Detected NUMA nodes: 2
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/dpdk_63552_202206241732/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs found
for that size
EAL: VFIO support initialized
EAL: Using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(1)
EAL: Ignore mapping IO port bar(4)
EAL: Probe PCI driver: net_i40e (8086:1583) device: 0000:18:00.0 (socket 0)
EAL: Ignore mapping IO port bar(1)
EAL: Ignore mapping IO port bar(4)
EAL: Probe PCI driver: net_i40e (8086:1583) device: 0000:18:00.1 (socket 0)
TELEMETRY: No legacy callbacks, legacy socket not created
APP: HPET is not enabled, using TSC as default timer
RTE>>link_bonding_rssconf_autotest
+ ------------------------------------------------------- +
+ Test Suite : RSS Dynamic Configuration for Bonding Unit Test Suite
+ ------------------------------------------------------- +
+ TestCase [ 0] : test_setup succeeded
Device with port_id=2 already stopped
Device with port_id=3 already stopped
Device with port_id=4 already stopped
Device with port_id=5 already stopped
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 2: Operation not supported
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 3: Operation not supported
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 4: Operation not supported
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 5: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 2: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 3: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 4: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 5: Operation not supported
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
bond_ethdev_rss_hash_update(3145) - rss_key will be truncated
Port 2 must be stopped to allow reset
Port 2 must be stopped to allow reset
Port 3 must be stopped to allow reset
Port 4 must be stopped to allow reset
Port 5 must be stopped to allow reset
+ TestCase [ 1] : test_rss succeeded
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 2: Operation not supported
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 3: Operation not supported
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 4: Operation not supported
bond_ethdev_promiscuous_disable(2690) - Failed to disable promiscuous mode for
port 5: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 2: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 3: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 4: Operation not supported
bond_ethdev_allmulticast_disable(2836) - Failed to disable allmulti mode for
port 5: Operation not supported
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Multi-queue RSS mode isn't enabled.
Port 2 must be stopped to allow reset
Port 3 must be stopped to allow reset
Port 4 must be stopped to allow reset
Port 5 must be stopped to allow reset
+ TestCase [ 2] : test_rss_lazy succeeded
Device with port_id=6 already stopped
+ ------------------------------------------------------- +
+ Test Suite Summary : RSS Dynamic Configuration for Bonding Unit Test Suite
+ ------------------------------------------------------- +
+ Tests Total : 3
+ Tests Skipped : 0
+ Tests Executed : 3
+ Tests Unsupported: 0
+ Tests Passed : 3
+ Tests Failed : 0
+ ------------------------------------------------------- +
Test OK
RTE>>quit
[Regression]
Is this issue a regression: (Y/N)Y
Version the regression was introduced: Specify git id if known.
[Bad Commit]:
commit 93e1ea6dfa99dea359b8d66123576a395c2c0acd (HEAD, refs/bisect/bad)
Author: Huisong Li <lihuisong@huawei.com>
Date: Wed Apr 6 14:57:00 2022 +0800
ethdev: fix RSS update when RSS is disabled
The RTE_ETH_MQ_RX_RSS_FLAG flag is a switch to enable RSS. If the flag
is not set in dev_configure, RSS will be not configured and enabled.
However, RSS hash and reta can still be configured by ethdev ops to
enable RSS if the flag isn't set. The behavior is inconsistent.
Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@xilinx.com>
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3 0/8] yet more unnecessary NULL checks
@ 2022-06-24 12:41 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-06-24 12:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Sun, Feb 20, 2022 at 7:22 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> Thomas suggested there are some other functions that could
> use the nullfree cleanup; this covers the rest of the story.
>
> Note: this does not change existing API/ABI, there are still
> some outliers that don't use the convention but fixing these
> will have to wait until next LTS.
>
> v3 - fix another typo and add more functions
>
> v2 - fix spelling typo and add functions
>
> Stephen Hemminger (8):
> cocci/nullfree: add more functions
> acl: remove unnecessary null checks
> lpm: remove unnecessary NULL checks
> lib: document existing free functions
> test: remove unnecessary NULL checks before free
> fips_validation: remove unnecessary NULL check
> event/sw: remove unnecessary NULL check
> pipeline: remove unnecessary checks for NULL pointer before free
Series applied.
I reran the script and fixed two more instances.
Thanks for the cleanup Stephen.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-22 9:19 0% ` Bruce Richardson
@ 2022-06-23 16:45 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-06-23 16:45 UTC (permalink / raw)
To: Power, Ciara
Cc: Morten Brørup, fengchengwen, Stephen Hemminger, thomas,
ferruh.yigit, Laatz, Kevin, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
On Wed, Jun 22, 2022 at 10:19:48AM +0100, Bruce Richardson wrote:
> On Wed, Jun 22, 2022 at 08:57:43AM +0100, Power, Ciara wrote:
> > Hi folks,
> >
> > > -----Original Message-----
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: Saturday 18 June 2022 10:59
> > > To: fengchengwen <fengchengwen@huawei.com>; Stephen Hemminger
> > > <stephen@networkplumber.org>; Richardson, Bruce
> > > <bruce.richardson@intel.com>
> > > Cc: thomas@monjalon.net; ferruh.yigit@xilinx.com; Laatz, Kevin
> > > <kevin.laatz@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > > jerinj@marvell.com; sachin.saxena@oss.nxp.com;
> > > hemant.agrawal@nxp.com; dev@dpdk.org; Power, Ciara
> > > <ciara.power@intel.com>
> > > Subject: RE: [PATCH v2 1/5] telemetry: escape special char when tel string
> > >
> > > +CC: Ciara Power, Telemetry library maintainer
> > >
> > > > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > > > Sent: Saturday, 18 June 2022 05.52
> > > >
> > > > On 2022/6/18 1:05, Stephen Hemminger wrote:
> > > > > On Fri, 17 Jun 2022 12:25:04 +0100
> > > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > > >
> > > > >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> > > > >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > > >>>> Sent: Friday, 17 June 2022 11.46
> > > > >>>>
> > > > >>>> This patch supports escape special characters (including:
> > > > \",\\,/,\b,
> > > > >>>> /f,/n,/r,/t) when telemetry string.
> > > > >>>> This patch is used to support telemetry xxx-dump commands which
> > > > the
> > > > >>>> string may include special characters.
> > > > >>>>
> > > > >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > > >>>> ---
> > > > >>>> lib/telemetry/telemetry.c | 96
> > > > +++++++++++++++++++++++++++++++++++++--
> > > > >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> > > > >>>>
> > > > >>>> diff --git a/lib/telemetry/telemetry.c
> > > > >>>> b/lib/telemetry/telemetry.c index c6fd03a5ab..0f762f633e 100644
> > > > >>>> --- a/lib/telemetry/telemetry.c
> > > > >>>> +++ b/lib/telemetry/telemetry.c
> > > > >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> > > > *d,
> > > > >>>> char *out_buf, size_t buf_len)
> > > > >>>> return used;
> > > > >>>> }
> > > > >>>>
> > > > >>>> +static bool
> > > > >>>> +json_is_special_char(char ch)
> > > > >>>> +{
> > > > >>>> + static unsigned char is_spec[256] = { 0 };
> > > > >>>> + static bool init_once;
> > > > >>>> +
> > > > >>>> + if (!init_once) {
> > > > >>>> + is_spec['\"'] = 1;
> > > > >>>> + is_spec['\\'] = 1;
> > > > >>>> + is_spec['/'] = 1;
> > > > >>>> + is_spec['\b'] = 1;
> > > > >>>> + is_spec['\f'] = 1;
> > > > >>>> + is_spec['\n'] = 1;
> > > > >>>> + is_spec['\r'] = 1;
> > > > >>>> + is_spec['\t'] = 1;
> > > > >>>> + init_once = true;
> > > > >>>> + }
> > > > >>>> +
> > > > >>>> + return (bool)is_spec[(unsigned char)ch]; }
> > > > >>
> > > > >> According to the json spec at [1], the characters that need to be
> > > > escaped
> > > > >> are:
> > > > >> a) any characters <0x20
> > > > >> b) inverted commas/quote character \"
> > > > >> c) the "reverse solidus character", better known to you and I as
> > > > >> the back-slash.
> > > > >>
> > > > >> Therefore, I think this table generation could be simplified, but
> > > > also
> > > > >> expanded using this. For completeness we should also see about
> > > > handling all
> > > > >> control characters if they are encountered.
> > > > >>
> > > > >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > > > >>
> > > > >> /Bruce
> > > > >
> > > > > Since it is trivial could be initializer?
> > > > >
> > > > > static const uint8_t is_spec[256] = {
> > > > > [0 ... 0x20] = 1,
> > > > > ['\"' ] = 1,
> > > > > ['\\' ] = 1,
> > > > > ['/'] = 1,
> > > > >
> > > > > etc
> > > > >
> > > > > Or we could change the telemetry API to disallow control characters?
> > > >
> > > > I was thinking about converting 0~0x20, but I don't think there's a
> > > > scenario.
> > > >
> > > > I prefer change the telemetry API to disallow control characters, and
> > > > this may not be a violation of the ABI, if yes, the dpdk-telemetry.py
> > > > will returns an error.
> > >
> > > I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
> > >
> > > So we need to define exactly what the STRING type contains.
> > >
> > > I hope we can all agree that control characters should be disallowed.
> > >
> > > The more complicated question is: Do we want to use the ASCII character set
> > > only, or do we want to use UTF-8 encoded Unicode?
> > >
> > > Personally, think UTF-8 encoded Unicode is more future proof, and would
> > > vote for that.
> > >
> > > But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce
> > > another data type for UTF-8 strings.
> > >
> > > UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many
> > > SNMP MIBs.
> > >
> > [CP]
> >
> > Just from looking at the spec [1] , I would say UTF-8, as it seems to suggest its use for JSON (section 8.1).
> >
> > [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> >
> > > >
> > > > So I think we could add declaring and checking functions to make sure
> > > > telemetry string do not allow control characters.
> > [CP]
> >
> > I am not sure why we don't want these at all - I thought we do want some of them, like tab (\u0009) for example.
> >
> > <snip>
> >
> > In general, I think Bruce's suggestion of using a customised printf function instead of snprintf would be a good way forward, to scan the chars as they are being copied in.
> >
>
> I'm hoping to have some time to try and prototype this myself soon, and
> send out a draft patch to this mailing list for consideration.
>
Here is an RFC of my current prototype of this:
http://patches.dpdk.org/project/dpdk/list/?series=23739
Feedback welcome.
Regards,
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH v1] bbdev: allow operation type enum for growth
2022-06-17 8:21 3% ` Thomas Monjalon
2022-06-17 16:12 0% ` Chautru, Nicolas
@ 2022-06-23 16:09 0% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2022-06-23 16:09 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Nicolas Chautru, dev, maxime.coquelin, trix, bruce.richardson,
hemant.agrawal, david.marchand, stephen, techboard
Thomas Monjalon <thomas@monjalon.net> writes:
> This solution is what I proposed to the techboard some years ago,
> but the preference was to completely remove the MAX values.
I am mindful we don't have an explicit guidance in the documentation.
I am including to add something to the abi_versioning document, that
basically says
1. Try not to use _MAX values with enumerations.
2. If you have to use _MAX values with enumeration, consider giving
yourself some headroom along with rigourous checking?
>
>
> 13/06/2022 20:24, Nicolas Chautru:
>> Updating the last enum for rte_bbdev_op_type
>> to allow for enum insertion.
>
> Please explain that the reason is to keep ABI compatible,
> and you want to keep the MAX value for array needs.
>
>> --- a/lib/bbdev/rte_bbdev.c
>> +++ b/lib/bbdev/rte_bbdev.c
>> @@ -1122,7 +1122,10 @@ struct rte_mempool *
>> "RTE_BBDEV_OP_TURBO_DEC",
>> "RTE_BBDEV_OP_TURBO_ENC",
>> "RTE_BBDEV_OP_LDPC_DEC",
>> - "RTE_BBDEV_OP_LDPC_ENC",
>> + "RTE_BBDEV_OP_RESERVED_1",
>> + "RTE_BBDEV_OP_RESERVED_2",
>> + "RTE_BBDEV_OP_RESERVED_3",
>> + "RTE_BBDEV_OP_RESERVED_4",
>
> As Stephen said, you should make sure that using these values
> with the API functions will lead to a clear and expected error.
>
>> @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
>> RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
>> RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
>> RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
>> - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
>> + RTE_BBDEV_OP_TYPE_COUNT = 8, /**< Count of different op types */
>
> You must update the comment to explain there may be a padding,
> it is not exactly the count.
> Maybe "MAX" is a better fit than "COUNT" in this case.
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* [PATCH v4 07/13] net/nfp: support firmware with NFDk
@ 2022-06-23 2:26 5% ` Jin Liu
0 siblings, 0 replies; 200+ results
From: Jin Liu @ 2022-06-23 2:26 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
doc/guides/nics/nfp.rst | 7 ++--
doc/guides/rel_notes/release_22_07.rst | 1 +
drivers/net/nfp/nfp_ctrl.h | 2 +
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++-----
drivers/net/nfp/nfp_ethdev_vf.c | 53 +++++++++++++++++++-------
5 files changed, 85 insertions(+), 27 deletions(-)
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index dcefac3ef6..55539accc2 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -100,9 +100,10 @@ more than one SmartNIC, same type of SmartNIC or different ones, and to upload a
different firmware to each SmartNIC.
.. Note::
- Currently the NFP PMD supports using the PF with Agilio Basic Firmware. See
- https://help.netronome.com/support/solutions for more information on the
- various firmwares supported by the Netronome Agilio CX smartNIC.
+ Currently the NFP PMD supports using the PF with Agilio Firmware with NFD3
+ and Agilio Firmware with NFDk. See https://help.netronome.com/support/solutions
+ for more information on the various firmwares supported by the Netronome
+ Agilio CX smartNIC.
PF multiport support
--------------------
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index d5d8c735b1..64308e6c1a 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -111,6 +111,7 @@ New Features
* **Updated Netronome nfp driver.**
* Added support for NFP3800 NIC.
+ * Added support for firmware with NFDk.
* **Updated VMware vmxnet3 networking driver.**
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index cb84dc3188..1bbba9187e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -402,11 +428,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -441,6 +462,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -473,7 +499,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -939,6 +964,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -988,11 +1014,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"secondary process attach failed, ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index c46ee0f913..0b4660aba6 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -265,6 +265,32 @@ static const struct eth_dev_ops nfp_netvf_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_netvf_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_netvf_init(struct rte_eth_dev *eth_dev)
{
@@ -292,10 +318,19 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
- eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_netvf_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -313,15 +348,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -354,7 +380,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
--
2.27.0
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-22 7:57 0% ` Power, Ciara
@ 2022-06-22 9:19 0% ` Bruce Richardson
2022-06-23 16:45 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-06-22 9:19 UTC (permalink / raw)
To: Power, Ciara
Cc: Morten Brørup, fengchengwen, Stephen Hemminger, thomas,
ferruh.yigit, Laatz, Kevin, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
On Wed, Jun 22, 2022 at 08:57:43AM +0100, Power, Ciara wrote:
> Hi folks,
>
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Saturday 18 June 2022 10:59
> > To: fengchengwen <fengchengwen@huawei.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; Richardson, Bruce
> > <bruce.richardson@intel.com>
> > Cc: thomas@monjalon.net; ferruh.yigit@xilinx.com; Laatz, Kevin
> > <kevin.laatz@intel.com>; andrew.rybchenko@oktetlabs.ru;
> > jerinj@marvell.com; sachin.saxena@oss.nxp.com;
> > hemant.agrawal@nxp.com; dev@dpdk.org; Power, Ciara
> > <ciara.power@intel.com>
> > Subject: RE: [PATCH v2 1/5] telemetry: escape special char when tel string
> >
> > +CC: Ciara Power, Telemetry library maintainer
> >
> > > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > > Sent: Saturday, 18 June 2022 05.52
> > >
> > > On 2022/6/18 1:05, Stephen Hemminger wrote:
> > > > On Fri, 17 Jun 2022 12:25:04 +0100
> > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > >
> > > >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> > > >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > >>>> Sent: Friday, 17 June 2022 11.46
> > > >>>>
> > > >>>> This patch supports escape special characters (including:
> > > \",\\,/,\b,
> > > >>>> /f,/n,/r,/t) when telemetry string.
> > > >>>> This patch is used to support telemetry xxx-dump commands which
> > > the
> > > >>>> string may include special characters.
> > > >>>>
> > > >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > >>>> ---
> > > >>>> lib/telemetry/telemetry.c | 96
> > > +++++++++++++++++++++++++++++++++++++--
> > > >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> > > >>>>
> > > >>>> diff --git a/lib/telemetry/telemetry.c
> > > >>>> b/lib/telemetry/telemetry.c index c6fd03a5ab..0f762f633e 100644
> > > >>>> --- a/lib/telemetry/telemetry.c
> > > >>>> +++ b/lib/telemetry/telemetry.c
> > > >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> > > *d,
> > > >>>> char *out_buf, size_t buf_len)
> > > >>>> return used;
> > > >>>> }
> > > >>>>
> > > >>>> +static bool
> > > >>>> +json_is_special_char(char ch)
> > > >>>> +{
> > > >>>> + static unsigned char is_spec[256] = { 0 };
> > > >>>> + static bool init_once;
> > > >>>> +
> > > >>>> + if (!init_once) {
> > > >>>> + is_spec['\"'] = 1;
> > > >>>> + is_spec['\\'] = 1;
> > > >>>> + is_spec['/'] = 1;
> > > >>>> + is_spec['\b'] = 1;
> > > >>>> + is_spec['\f'] = 1;
> > > >>>> + is_spec['\n'] = 1;
> > > >>>> + is_spec['\r'] = 1;
> > > >>>> + is_spec['\t'] = 1;
> > > >>>> + init_once = true;
> > > >>>> + }
> > > >>>> +
> > > >>>> + return (bool)is_spec[(unsigned char)ch]; }
> > > >>
> > > >> According to the json spec at [1], the characters that need to be
> > > escaped
> > > >> are:
> > > >> a) any characters <0x20
> > > >> b) inverted commas/quote character \"
> > > >> c) the "reverse solidus character", better known to you and I as
> > > >> the back-slash.
> > > >>
> > > >> Therefore, I think this table generation could be simplified, but
> > > also
> > > >> expanded using this. For completeness we should also see about
> > > handling all
> > > >> control characters if they are encountered.
> > > >>
> > > >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > > >>
> > > >> /Bruce
> > > >
> > > > Since it is trivial could be initializer?
> > > >
> > > > static const uint8_t is_spec[256] = {
> > > > [0 ... 0x20] = 1,
> > > > ['\"' ] = 1,
> > > > ['\\' ] = 1,
> > > > ['/'] = 1,
> > > >
> > > > etc
> > > >
> > > > Or we could change the telemetry API to disallow control characters?
> > >
> > > I was thinking about converting 0~0x20, but I don't think there's a
> > > scenario.
> > >
> > > I prefer change the telemetry API to disallow control characters, and
> > > this may not be a violation of the ABI, if yes, the dpdk-telemetry.py
> > > will returns an error.
> >
> > I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
> >
> > So we need to define exactly what the STRING type contains.
> >
> > I hope we can all agree that control characters should be disallowed.
> >
> > The more complicated question is: Do we want to use the ASCII character set
> > only, or do we want to use UTF-8 encoded Unicode?
> >
> > Personally, think UTF-8 encoded Unicode is more future proof, and would
> > vote for that.
> >
> > But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce
> > another data type for UTF-8 strings.
> >
> > UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many
> > SNMP MIBs.
> >
> [CP]
>
> Just from looking at the spec [1] , I would say UTF-8, as it seems to suggest its use for JSON (section 8.1).
>
> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
>
> > >
> > > So I think we could add declaring and checking functions to make sure
> > > telemetry string do not allow control characters.
> [CP]
>
> I am not sure why we don't want these at all - I thought we do want some of them, like tab (\u0009) for example.
>
> <snip>
>
> In general, I think Bruce's suggestion of using a customised printf function instead of snprintf would be a good way forward, to scan the chars as they are being copied in.
>
I'm hoping to have some time to try and prototype this myself soon, and
send out a draft patch to this mailing list for consideration.
/Bruce
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-18 9:59 0% ` Morten Brørup
@ 2022-06-22 7:57 0% ` Power, Ciara
2022-06-22 9:19 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Power, Ciara @ 2022-06-22 7:57 UTC (permalink / raw)
To: Morten Brørup, fengchengwen, Stephen Hemminger, Richardson, Bruce
Cc: thomas, ferruh.yigit, Laatz, Kevin, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
Hi folks,
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Saturday 18 June 2022 10:59
> To: fengchengwen <fengchengwen@huawei.com>; Stephen Hemminger
> <stephen@networkplumber.org>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Cc: thomas@monjalon.net; ferruh.yigit@xilinx.com; Laatz, Kevin
> <kevin.laatz@intel.com>; andrew.rybchenko@oktetlabs.ru;
> jerinj@marvell.com; sachin.saxena@oss.nxp.com;
> hemant.agrawal@nxp.com; dev@dpdk.org; Power, Ciara
> <ciara.power@intel.com>
> Subject: RE: [PATCH v2 1/5] telemetry: escape special char when tel string
>
> +CC: Ciara Power, Telemetry library maintainer
>
> > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > Sent: Saturday, 18 June 2022 05.52
> >
> > On 2022/6/18 1:05, Stephen Hemminger wrote:
> > > On Fri, 17 Jun 2022 12:25:04 +0100
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > >
> > >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> > >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > >>>> Sent: Friday, 17 June 2022 11.46
> > >>>>
> > >>>> This patch supports escape special characters (including:
> > \",\\,/,\b,
> > >>>> /f,/n,/r,/t) when telemetry string.
> > >>>> This patch is used to support telemetry xxx-dump commands which
> > the
> > >>>> string may include special characters.
> > >>>>
> > >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > >>>> ---
> > >>>> lib/telemetry/telemetry.c | 96
> > +++++++++++++++++++++++++++++++++++++--
> > >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> > >>>>
> > >>>> diff --git a/lib/telemetry/telemetry.c
> > >>>> b/lib/telemetry/telemetry.c index c6fd03a5ab..0f762f633e 100644
> > >>>> --- a/lib/telemetry/telemetry.c
> > >>>> +++ b/lib/telemetry/telemetry.c
> > >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> > *d,
> > >>>> char *out_buf, size_t buf_len)
> > >>>> return used;
> > >>>> }
> > >>>>
> > >>>> +static bool
> > >>>> +json_is_special_char(char ch)
> > >>>> +{
> > >>>> + static unsigned char is_spec[256] = { 0 };
> > >>>> + static bool init_once;
> > >>>> +
> > >>>> + if (!init_once) {
> > >>>> + is_spec['\"'] = 1;
> > >>>> + is_spec['\\'] = 1;
> > >>>> + is_spec['/'] = 1;
> > >>>> + is_spec['\b'] = 1;
> > >>>> + is_spec['\f'] = 1;
> > >>>> + is_spec['\n'] = 1;
> > >>>> + is_spec['\r'] = 1;
> > >>>> + is_spec['\t'] = 1;
> > >>>> + init_once = true;
> > >>>> + }
> > >>>> +
> > >>>> + return (bool)is_spec[(unsigned char)ch]; }
> > >>
> > >> According to the json spec at [1], the characters that need to be
> > escaped
> > >> are:
> > >> a) any characters <0x20
> > >> b) inverted commas/quote character \"
> > >> c) the "reverse solidus character", better known to you and I as
> > >> the back-slash.
> > >>
> > >> Therefore, I think this table generation could be simplified, but
> > also
> > >> expanded using this. For completeness we should also see about
> > handling all
> > >> control characters if they are encountered.
> > >>
> > >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > >>
> > >> /Bruce
> > >
> > > Since it is trivial could be initializer?
> > >
> > > static const uint8_t is_spec[256] = {
> > > [0 ... 0x20] = 1,
> > > ['\"' ] = 1,
> > > ['\\' ] = 1,
> > > ['/'] = 1,
> > >
> > > etc
> > >
> > > Or we could change the telemetry API to disallow control characters?
> >
> > I was thinking about converting 0~0x20, but I don't think there's a
> > scenario.
> >
> > I prefer change the telemetry API to disallow control characters, and
> > this may not be a violation of the ABI, if yes, the dpdk-telemetry.py
> > will returns an error.
>
> I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
>
> So we need to define exactly what the STRING type contains.
>
> I hope we can all agree that control characters should be disallowed.
>
> The more complicated question is: Do we want to use the ASCII character set
> only, or do we want to use UTF-8 encoded Unicode?
>
> Personally, think UTF-8 encoded Unicode is more future proof, and would
> vote for that.
>
> But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce
> another data type for UTF-8 strings.
>
> UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many
> SNMP MIBs.
>
[CP]
Just from looking at the spec [1] , I would say UTF-8, as it seems to suggest its use for JSON (section 8.1).
[1] https://www.rfc-editor.org/rfc/rfc8259.txt
> >
> > So I think we could add declaring and checking functions to make sure
> > telemetry string do not allow control characters.
[CP]
I am not sure why we don't want these at all - I thought we do want some of them, like tab (\u0009) for example.
<snip>
In general, I think Bruce's suggestion of using a customised printf function instead of snprintf would be a good way forward, to scan the chars as they are being copied in.
Thanks,
Ciara
^ permalink raw reply [relevance 0%]
* [PATCH] config/riscv: name the cross file properly
@ 2022-06-21 12:29 5% Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-06-21 12:29 UTC (permalink / raw)
To: David Marchand; +Cc: Stanislaw Kardach, dev, upstream
Since the riscv64_linux_gcc was in fact a Ubuntu-specific cross-file,
rename it.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
.ci/linux-build.sh | 2 +-
config/riscv/{riscv64_linux_gcc => riscv64_linux_gcc_ubuntu} | 0
devtools/test-meson-builds.sh | 2 +-
doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst | 4 ++--
4 files changed, 4 insertions(+), 4 deletions(-)
rename config/riscv/{riscv64_linux_gcc => riscv64_linux_gcc_ubuntu} (100%)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 06104eca22..dcf4d4ccb3 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -75,7 +75,7 @@ if [ "$PPC64LE" = "true" ]; then
fi
if [ "$RISCV64" = "true" ]; then
- cross_file=config/riscv/riscv64_linux_gcc
+ cross_file=config/riscv/riscv64_linux_gcc_ubuntu
fi
if [ -n "$cross_file" ]; then
diff --git a/config/riscv/riscv64_linux_gcc b/config/riscv/riscv64_linux_gcc_ubuntu
similarity index 100%
rename from config/riscv/riscv64_linux_gcc
rename to config/riscv/riscv64_linux_gcc_ubuntu
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 04a85fe987..00b97a3e50 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -265,7 +265,7 @@ f=$srcdir/config/ppc/ppc64le-power8-linux-gcc
build build-ppc64-power8-gcc $f ABI $use_shared
# generic RISC-V
-f=$srcdir/config/riscv/riscv64_linux_gcc
+f=$srcdir/config/riscv/riscv64_linux_gcc_ubuntu
build build-riscv64-generic-gcc $f ABI $use_shared
# Test installation of the x86-generic target, to be used for checking
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst b/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst
index 9e121645a8..84d1ea3aa6 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_riscv.rst
@@ -74,7 +74,7 @@ To cross-compile DPDK for a desired target machine use the following command::
For example if the target machine is a generic rv64gc RISC-V, use the following
command::
- meson riscv64-build-gcc --cross-file config/riscv/riscv64_linux_gcc
+ meson riscv64-build-gcc --cross-file config/riscv/riscv64_linux_gcc_ubuntu
ninja -C riscv64-build-gcc
If riscv-gnu-toolchain is used, binary names should be updated to match. Update
@@ -106,7 +106,7 @@ Supported cross-compilation targets
Currently the following targets are supported:
-* Generic rv64gc ISA: ``config/riscv/riscv64_linux_gcc``
+* Generic rv64gc ISA: ``config/riscv/riscv64_linux_gcc_ubuntu``
* SiFive U740 SoC: ``config/riscv/riscv64_sifive_u740_linux_gcc``
--
2.30.2
^ permalink raw reply [relevance 5%]
* [PATCH v6] sched: enable CMAN at runtime
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
@ 2022-06-21 8:16 1% ` Marcin Danilewicz
2022-07-04 9:19 1% ` [PATCH v7] " Marcin Danilewicz
0 siblings, 1 reply; 200+ results
From: Marcin Danilewicz @ 2022-06-21 8:16 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
v6 commit message fixed
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* [PATCH v5] ched: enable CMAN at runtime
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
2022-06-17 11:48 0% ` Dumitrescu, Cristian
@ 2022-06-20 13:56 1% ` Marcin Danilewicz
2022-06-21 8:16 1% ` [PATCH v6] sched: " Marcin Danilewicz
1 sibling, 1 reply; 200+ results
From: Marcin Danilewicz @ 2022-06-20 13:56 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
v4 rebase to 22.07-rc1
v5 rebase to main latest
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 46549cb062..ae56a86394 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-// RTE_SCHED_CMAN is not set
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* [PATCH v8 0/3] pcap: support MTU set for linux interfaces
` (3 preceding siblings ...)
2022-06-19 9:30 3% ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
@ 2022-06-20 8:39 3% ` Ido Goshen
4 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-20 8:39 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
patch series:
[PATCH v8 1/3] pcap: support MTU set for linux interfaces
[PATCH v8 2/3] pcap: support MTU set for linux interfaces TX
[PATCH v8 3/3] pcap: support MTU set for linux interfaces count
doc/guides/rel_notes/release_22_07.rst | 3 +
drivers/net/pcap/pcap_ethdev.c | 126 +++++++++++++++++++++++++--------
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 ++
drivers/net/pcap/pcap_osdep_linux.c | 21 ++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 ++
6 files changed, 134 insertions(+), 31 deletions(-)
---
v8:
cosmetics only
1. checkpatch typo fix
2. rel_notes apply patch fix by rebasing on latest main
v7:
1. TX drop only individual oversized packets and not the entire burst
2. Count oversize drops by i/oerrors
v6:
Fixes for v5 approach
1. freebsd compilation fix
2. checkpatch warning fix
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
^ permalink raw reply [relevance 3%]
* [PATCH v7 0/3] pcap: support MTU set for linux interfaces
` (2 preceding siblings ...)
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
@ 2022-06-19 9:30 3% ` Ido Goshen
2022-06-20 8:39 3% ` [PATCH v8 " Ido Goshen
4 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-19 9:30 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
patch series:
[PATCH v7 1/3] pcap: support MTU set for linux interfaces
[PATCH v7 2/3] pcap: support MTU set for linux interfaces TX
[PATCH v7 3/3] pcap: support MTU set for linux interfaces count
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 126 +++++++++++++++++++++++++++++++++-----------
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 +++
drivers/net/pcap/pcap_osdep_linux.c | 21 ++++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 +++
6 files changed, 134 insertions(+), 31 deletions(-)
---
v7:
1. TX drop only individual oversized packets and not the entire burst
2. Count oversize drops by i/oerrors
v6:
Fixes for v5 approach
1. freebsd compilation fix
2. checkpatch warning fix
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 1/5] telemetry: escape special char when tel string
2022-06-18 3:52 3% ` fengchengwen
@ 2022-06-18 9:59 0% ` Morten Brørup
2022-06-22 7:57 0% ` Power, Ciara
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-06-18 9:59 UTC (permalink / raw)
To: fengchengwen, Stephen Hemminger, Bruce Richardson
Cc: thomas, ferruh.yigit, kevin.laatz, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev, Ciara Power
+CC: Ciara Power, Telemetry library maintainer
> From: fengchengwen [mailto:fengchengwen@huawei.com]
> Sent: Saturday, 18 June 2022 05.52
>
> On 2022/6/18 1:05, Stephen Hemminger wrote:
> > On Fri, 17 Jun 2022 12:25:04 +0100
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> >> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
> >>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> >>>> Sent: Friday, 17 June 2022 11.46
> >>>>
> >>>> This patch supports escape special characters (including:
> \",\\,/,\b,
> >>>> /f,/n,/r,/t) when telemetry string.
> >>>> This patch is used to support telemetry xxx-dump commands which
> the
> >>>> string may include special characters.
> >>>>
> >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>>> ---
> >>>> lib/telemetry/telemetry.c | 96
> +++++++++++++++++++++++++++++++++++++--
> >>>> 1 file changed, 93 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
> >>>> index c6fd03a5ab..0f762f633e 100644
> >>>> --- a/lib/telemetry/telemetry.c
> >>>> +++ b/lib/telemetry/telemetry.c
> >>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data
> *d,
> >>>> char *out_buf, size_t buf_len)
> >>>> return used;
> >>>> }
> >>>>
> >>>> +static bool
> >>>> +json_is_special_char(char ch)
> >>>> +{
> >>>> + static unsigned char is_spec[256] = { 0 };
> >>>> + static bool init_once;
> >>>> +
> >>>> + if (!init_once) {
> >>>> + is_spec['\"'] = 1;
> >>>> + is_spec['\\'] = 1;
> >>>> + is_spec['/'] = 1;
> >>>> + is_spec['\b'] = 1;
> >>>> + is_spec['\f'] = 1;
> >>>> + is_spec['\n'] = 1;
> >>>> + is_spec['\r'] = 1;
> >>>> + is_spec['\t'] = 1;
> >>>> + init_once = true;
> >>>> + }
> >>>> +
> >>>> + return (bool)is_spec[(unsigned char)ch];
> >>>> +}
> >>
> >> According to the json spec at [1], the characters that need to be
> escaped
> >> are:
> >> a) any characters <0x20
> >> b) inverted commas/quote character \"
> >> c) the "reverse solidus character", better known to you and I as the
> >> back-slash.
> >>
> >> Therefore, I think this table generation could be simplified, but
> also
> >> expanded using this. For completeness we should also see about
> handling all
> >> control characters if they are encountered.
> >>
> >> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> >>
> >> /Bruce
> >
> > Since it is trivial could be initializer?
> >
> > static const uint8_t is_spec[256] = {
> > [0 ... 0x20] = 1,
> > ['\"' ] = 1,
> > ['\\' ] = 1,
> > ['/'] = 1,
> >
> > etc
> >
> > Or we could change the telemetry API to disallow control characters?
>
> I was thinking about converting 0~0x20, but I don't think there's a
> scenario.
>
> I prefer change the telemetry API to disallow control characters, and
> this may not
> be a violation of the ABI, if yes, the dpdk-telemetry.py will returns
> an error.
I agree with Chengwen Feng. The telemetry data type is STRING, not BLOB.
So we need to define exactly what the STRING type contains.
I hope we can all agree that control characters should be disallowed.
The more complicated question is: Do we want to use the ASCII character set only, or do we want to use UTF-8 encoded Unicode?
Personally, think UTF-8 encoded Unicode is more future proof, and would vote for that.
But I wouldn't reject limiting it to ASCII, and perhaps in the future introduce another data type for UTF-8 strings.
UTF-8 is the modern choice, but it is incompatible with old stuff, e.g. many SNMP MIBs.
>
> So I think we could add declaring and checking functions to make sure
> telemetry string
> do not allow control characters.
Input validation (when storing a string in the telemetry database) has a performance cost, so it could be a compile time debug option, like the memory cookies and mbuf integrity checks. Just a thought.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/5] telemetry: escape special char when tel string
@ 2022-06-18 3:52 3% ` fengchengwen
2022-06-18 9:59 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: fengchengwen @ 2022-06-18 3:52 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: Morten Brørup, thomas, ferruh.yigit, kevin.laatz,
andrew.rybchenko, jerinj, sachin.saxena, hemant.agrawal, dev
On 2022/6/18 1:05, Stephen Hemminger wrote:
> On Fri, 17 Jun 2022 12:25:04 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> On Fri, Jun 17, 2022 at 01:16:08PM +0200, Morten Brørup wrote:
>>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
>>>> Sent: Friday, 17 June 2022 11.46
>>>>
>>>> This patch supports escape special characters (including: \",\\,/,\b,
>>>> /f,/n,/r,/t) when telemetry string.
>>>> This patch is used to support telemetry xxx-dump commands which the
>>>> string may include special characters.
>>>>
>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>> ---
>>>> lib/telemetry/telemetry.c | 96 +++++++++++++++++++++++++++++++++++++--
>>>> 1 file changed, 93 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
>>>> index c6fd03a5ab..0f762f633e 100644
>>>> --- a/lib/telemetry/telemetry.c
>>>> +++ b/lib/telemetry/telemetry.c
>>>> @@ -215,6 +215,94 @@ container_to_json(const struct rte_tel_data *d,
>>>> char *out_buf, size_t buf_len)
>>>> return used;
>>>> }
>>>>
>>>> +static bool
>>>> +json_is_special_char(char ch)
>>>> +{
>>>> + static unsigned char is_spec[256] = { 0 };
>>>> + static bool init_once;
>>>> +
>>>> + if (!init_once) {
>>>> + is_spec['\"'] = 1;
>>>> + is_spec['\\'] = 1;
>>>> + is_spec['/'] = 1;
>>>> + is_spec['\b'] = 1;
>>>> + is_spec['\f'] = 1;
>>>> + is_spec['\n'] = 1;
>>>> + is_spec['\r'] = 1;
>>>> + is_spec['\t'] = 1;
>>>> + init_once = true;
>>>> + }
>>>> +
>>>> + return (bool)is_spec[(unsigned char)ch];
>>>> +}
>>
>> According to the json spec at [1], the characters that need to be escaped
>> are:
>> a) any characters <0x20
>> b) inverted commas/quote character \"
>> c) the "reverse solidus character", better known to you and I as the
>> back-slash.
>>
>> Therefore, I think this table generation could be simplified, but also
>> expanded using this. For completeness we should also see about handling all
>> control characters if they are encountered.
>>
>> [1] https://www.rfc-editor.org/rfc/rfc8259.txt
>>
>> /Bruce
>
> Since it is trivial could be initializer?
>
> static const uint8_t is_spec[256] = {
> [0 ... 0x20] = 1,
> ['\"' ] = 1,
> ['\\' ] = 1,
> ['/'] = 1,
>
> etc
>
> Or we could change the telemetry API to disallow control characters?
I was thinking about converting 0~0x20, but I don't think there's a scenario.
I prefer change the telemetry API to disallow control characters, and this may not
be a violation of the ABI, if yes, the dpdk-telemetry.py will returns an error.
So I think we could add declaring and checking functions to make sure telemetry string
do not allow control characters.
>
>
> .
>
^ permalink raw reply [relevance 3%]
* [PATCH v2 1/5] bbdev: allow operation type enum for growth
2022-06-17 18:37 4% ` [PATCH v2 0/5] bbdev changes for 22.11 Nicolas Chautru
@ 2022-06-17 18:37 3% ` Nicolas Chautru
0 siblings, 0 replies; 200+ results
From: Nicolas Chautru @ 2022-06-17 18:37 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Updating the enum for rte_bbdev_op_type
to allow to keep ABI compatible for enum insertion
while adding padded maximum value for array need.
Removing RTE_BBDEV_OP_TYPE_COUNT and instead exposing
RTE_BBDEV_OP_TYPE_PADDED_MAX.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 ++--
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 9 +++++----
lib/bbdev/rte_bbdev_op.h | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/app/test-bbdev/test_bbdev.c b/app/test-bbdev/test_bbdev.c
index ac06d73..1063f6e 100644
--- a/app/test-bbdev/test_bbdev.c
+++ b/app/test-bbdev/test_bbdev.c
@@ -521,7 +521,7 @@ struct bbdev_testsuite_params {
rte_mempool_free(mp);
TEST_ASSERT((mp = rte_bbdev_op_pool_create("Test_INV",
- RTE_BBDEV_OP_TYPE_COUNT, size, cache_size, 0)) == NULL,
+ RTE_BBDEV_OP_TYPE_PADDED_MAX, size, cache_size, 0)) == NULL,
"Failed test for rte_bbdev_op_pool_create: "
"returned value is not NULL for invalid type");
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index fad3b1e..1abda2d 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2428,13 +2428,13 @@ typedef int (test_case_function)(struct active_device *ad,
/* Find capabilities */
const struct rte_bbdev_op_cap *cap = info.drv.capabilities;
- for (i = 0; i < RTE_BBDEV_OP_TYPE_COUNT; i++) {
+ do {
if (cap->type == test_vector.op_type) {
capabilities = cap;
break;
}
cap++;
- }
+ } while (cap->type != RTE_BBDEV_OP_NONE);
TEST_ASSERT_NOT_NULL(capabilities,
"Couldn't find capabilities");
diff --git a/examples/bbdev_app/main.c b/examples/bbdev_app/main.c
index fc7e8b8..ef0ba76 100644
--- a/examples/bbdev_app/main.c
+++ b/examples/bbdev_app/main.c
@@ -1041,7 +1041,7 @@ uint16_t bbdev_parse_number(const char *mask)
void *sigret;
struct app_config_params app_params = def_app_config;
struct rte_mempool *ethdev_mbuf_mempool, *bbdev_mbuf_mempool;
- struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_COUNT];
+ struct rte_mempool *bbdev_op_pools[RTE_BBDEV_OP_TYPE_PADDED_MAX];
struct lcore_conf lcore_conf[RTE_MAX_LCORE] = { {0} };
struct lcore_statistics lcore_stats[RTE_MAX_LCORE] = { {0} };
struct stats_lcore_params stats_lcore;
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index aaee7b7..22bd894 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -23,6 +23,8 @@
#define DEV_NAME "BBDEV"
+/* Number of supported operation types */
+#define BBDEV_OP_TYPE_COUNT 5
/* BBDev library logging ID */
RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE);
@@ -890,10 +892,10 @@ struct rte_mempool *
return NULL;
}
- if (type >= RTE_BBDEV_OP_TYPE_COUNT) {
+ if (type >= BBDEV_OP_TYPE_COUNT) {
rte_bbdev_log(ERR,
"Invalid op type (%u), should be less than %u",
- type, RTE_BBDEV_OP_TYPE_COUNT);
+ type, BBDEV_OP_TYPE_COUNT);
return NULL;
}
@@ -1122,10 +1124,9 @@ struct rte_mempool *
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
"RTE_BBDEV_OP_LDPC_DEC",
- "RTE_BBDEV_OP_LDPC_ENC",
};
- if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
+ if (op_type < BBDEV_OP_TYPE_COUNT)
return op_types[op_type];
rte_bbdev_log(ERR, "Invalid operation type");
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 6d56133..cd82418 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
- RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
+ RTE_BBDEV_OP_TYPE_PADDED_MAX = 8, /**< Maximum op type number including padding */
};
/** Bit indexes of possible errors reported through status field */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v2 0/5] bbdev changes for 22.11
@ 2022-06-17 18:37 4% ` Nicolas Chautru
2022-06-17 18:37 3% ` [PATCH v2 1/5] bbdev: allow operation type enum for growth Nicolas Chautru
0 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-17 18:37 UTC (permalink / raw)
To: dev, thomas, gakhil, hemant.agrawal
Cc: maxime.coquelin, trix, mdr, bruce.richardson, david.marchand,
stephen, Nicolas Chautru
Hi,
Agregating together in a single serie a number of bbdev api changes previously submitted over the last few months and all targeted for 22.11 (4 different series detailed below). Related deprecation notice being pushed in 22.07 in parallel.
* bbdev: add device status info
* bbdev: add new operation for FFT processing
* bbdev: add device info on queue topology
* bbdev: allow operation type enum for growth
v2: Update to the RTE_BBDEV_COUNT removal based on feedback from Thomas/Stephen : rejecting out of range op type and adjusting the new name for the padded maximum value used for fixed size arrays.
---
Previous cover letters agregated below:
* bbdev: add device status info
https://patches.dpdk.org/project/dpdk/list/?series=23367
The updated structure will allow PMDs to expose through info_get what be may the status of the underlying accelerator, notably in case an HW error event having happened.
* bbdev: add new operation for FFT processing
https://patches.dpdk.org/project/dpdk/list/?series=22111
This contribution adds a new operation type to the existing ones already supported by the bbdev PMDs.
This set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental).
I plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test.
* bbdev: add device info on queue topology
https://patches.dpdk.org/project/dpdk/list/?series=22076
Addressing an historical concern that the device info struct only
imperfectly captured what queues are available on the device
(number of operation and priority). This ended up being an iterative
process for application to find each queue could be configured.
ie. the gap was captured as technical debt previously in comments
/* This isn't ideal because it reports the maximum number of queues but
* does not provide info on how many can be uplink/downlink or different
* priorities
*/
This is now being exposed explictly based on the what the device actually
supports using the existing info_get api
* bbdev: allow operation type enum for growth
https://patches.dpdk.org/project/dpdk/list/?series=23509
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Nicolas Chautru (5):
bbdev: allow operation type enum for growth
bbdev: add device status info
bbdev: add device info on queue topology
drivers/baseband: update PMDs to expose queue per operation
bbdev: add new operation for FFT processing
app/test-bbdev/test_bbdev.c | 2 +-
app/test-bbdev/test_bbdev_perf.c | 4 +-
doc/guides/prog_guide/bbdev.rst | 130 ++++++++++++++++++
drivers/baseband/acc100/rte_acc100_pmd.c | 30 ++--
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 9 ++
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 9 ++
drivers/baseband/la12xx/bbdev_la12xx.c | 10 +-
drivers/baseband/null/bbdev_null.c | 1 +
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 12 ++
examples/bbdev_app/main.c | 2 +-
lib/bbdev/rte_bbdev.c | 37 ++++-
lib/bbdev/rte_bbdev.h | 115 +++++++++++++++-
lib/bbdev/rte_bbdev_op.h | 151 ++++++++++++++++++++-
lib/bbdev/version.map | 10 ++
14 files changed, 499 insertions(+), 23 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* RE: [PATCH v1] bbdev: allow operation type enum for growth
2022-06-17 8:21 3% ` Thomas Monjalon
@ 2022-06-17 16:12 0% ` Chautru, Nicolas
2022-06-23 16:09 0% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-06-17 16:12 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, maxime.coquelin, trix, mdr, Richardson, Bruce,
hemant.agrawal, david.marchand, stephen, techboard
> From: Thomas Monjalon <thomas@monjalon.net>
>
> This solution is what I proposed to the techboard some years ago, but the
> preference was to completely remove the MAX values.
>
Thanks, good to see you had similar thought! I don't believe there is an actual recommendation captured in term of how to remove completely MAX values in that case below. I believe that this option is still compatible with the spirit of keeping AB future proof.
>
> 13/06/2022 20:24, Nicolas Chautru:
> > Updating the last enum for rte_bbdev_op_type to allow for enum
> > insertion.
>
> Please explain that the reason is to keep ABI compatible, and you want to keep
> the MAX value for array needs.
>
> > --- a/lib/bbdev/rte_bbdev.c
> > +++ b/lib/bbdev/rte_bbdev.c
> > @@ -1122,7 +1122,10 @@ struct rte_mempool *
> > "RTE_BBDEV_OP_TURBO_DEC",
> > "RTE_BBDEV_OP_TURBO_ENC",
> > "RTE_BBDEV_OP_LDPC_DEC",
> > - "RTE_BBDEV_OP_LDPC_ENC",
> > + "RTE_BBDEV_OP_RESERVED_1",
> > + "RTE_BBDEV_OP_RESERVED_2",
> > + "RTE_BBDEV_OP_RESERVED_3",
> > + "RTE_BBDEV_OP_RESERVED_4",
>
> As Stephen said, you should make sure that using these values with the API
> functions will lead to a clear and expected error.
Yes will do this.
>
> > @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
> > RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
> > RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
> > RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
> > - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
> > + RTE_BBDEV_OP_TYPE_COUNT = 8, /**< Count of different op types */
>
> You must update the comment to explain there may be a padding, it is not
> exactly the count.
> Maybe "MAX" is a better fit than "COUNT" in this case.
>
OK
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 7:53 0% ` Maxime Coquelin
@ 2022-06-17 16:13 0% ` Chautru, Nicolas
2022-06-27 20:47 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2022-06-17 16:13 UTC (permalink / raw)
To: dev, thomas
Cc: trix, Kinsella, Ray, Richardson, Bruce, hemant.agrawal,
david.marchand, stephen, Maxime Coquelin, gakhil
Hi Thomas,
Can this one be applied based on your review?
Thanks
Nic
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Thursday, June 9, 2022 12:54 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> gakhil@marvell.com; thomas@monjalon.net
> Cc: trix@redhat.com; Kinsella, Ray <ray.kinsella@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; hemant.agrawal@nxp.com;
> david.marchand@redhat.com; stephen@networkplumber.org
> Subject: Re: [PATCH v4] doc: announce changes in bbdev related to enum
> extension
>
> Hi Nicolas,
>
> On 6/9/22 02:34, Nicolas Chautru wrote:
> > Intent to resolve in DPDK 22.11 historical usage which prevents
> > graceful extension of enum and API without troublesome ABI breakage as
> > well as extending API RTE_BBDEV_OP_FFT for new operation type in bbdev
> > as well as other new members in existing structures.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 4e5b23c..c8ab1ec 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -112,6 +112,17 @@ Deprecation Notices
> > session and the private data of session. An opaque pointer can be exposed
> > directly to application which can be attached to the ``rte_crypto_op``.
> >
> > +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the
> > +``rte_bbdev_op_type``
> > + enum will be deprecated and instead use fixed array size when
> > +required to allow for
> > + future enum extension.
> > + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT``
> > +as per this
> > + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
> > + New members will be added in ``rte_bbdev_driver_info`` to expose
> > +PMD queue topology inspired
> > + by this RFC
> > +https://patches.dpdk.org/project/dpdk/list/?series=22076
> > + New member will be added in ``rte_bbdev_driver_info`` to expose the
> > +device status as per
> > + this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
> > + This should be updated in DPDK 22.11.
> > +
> > * security: Hide structure ``rte_security_session`` and expose an opaque
> > pointer for the private data to the application which can be attached
> > to the packet while enqueuing.
>
> Thanks for rewording the notice.
>
> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>
> Maxime
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] sched: enable CMAN at runtime
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
@ 2022-06-17 11:48 0% ` Dumitrescu, Cristian
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
1 sibling, 0 replies; 200+ results
From: Dumitrescu, Cristian @ 2022-06-17 11:48 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Monday, June 13, 2022 10:09 AM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v4] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> Log: v2 change in rte_sched.h to avoid ABI breakage.
> v3 changes from comments
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 11 +-
> examples/qos_sched/cfg_file.h | 2 -
> examples/qos_sched/init.c | 4 -
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 130 ++++++++++-----------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 47 +-------
> 11 files changed, 359 insertions(+), 141 deletions(-)
> create mode 100644 examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
Marcin,
Code changes look good to me, but still not able to cleanly apply this patch on top of DPDK latest with git am, can you please make sure this gets fixed?
Applying: sched: enable CMAN at runtime
error: patch failed: config/rte_config.h:88
error: config/rte_config.h: patch does not apply
Patch failed at 0001 sched: enable CMAN at runtime
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Regards,
Cristian
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 0/6] Vhost checksum offload improvements
2022-06-08 12:49 3% [PATCH v2 0/6] Vhost checksum offload improvements Maxime Coquelin
@ 2022-06-17 14:06 0% ` Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2022-06-17 14:06 UTC (permalink / raw)
To: dev, jasowang, chenbo.xia, david.marchand, olivier.matz,
wenwux.ma, yuying.zhang, aman.deep.singh
On 6/8/22 14:49, Maxime Coquelin wrote:
> This series aims at improving Vhost checksum offloading
> support.
>
> The first patch reverts overwritting MAC address in
> testpmd CSUM forward mode. This is required to be able to
> test checksum offloading with real traffic. MAC forwarding
> mode should be used if the MAC addresses need to be
> changed.
>
> Second patch is a Vhost library fix to be compliant with
> the Virtio specification, which requires that the
> pseudo-header checksum is being set by the device when
> offloading the checksum to the guest.
>
> Third patch enables the compliant offloading mode of Vhost
> library in Vhost PMD by default, since the legacy mode
> violates the mbuf API by setting Tx flags in the receive
> path. A new devarg is introduced for application willing
> to use the legacy mode.
>
> Fourth patch is just a small cleanup to represent a boolean
> value as a boolean.
>
> The two last patches introduces compatibility layers
> that performs checksum in SW when the ethdev and Virtio
> features are not aligned.
>
> Note that the two last patches are not tagged as fixes
> because they rely on the new compliant offload mode of
> Vhost library, and so would casue an ABI breakage if
> backported.
>
> With this series, it is now possible to perform IO
> forwarding between a vhost-user port and a Vitio-user
> with kernel backend port even if the guest has negotiated
> VIRTIO_NET_F_CSUM.
>
> With csum forward mode, it now works whathever the
> offloading configuration set either on Virtio or Ethdev
> sides.
>
> Changes in v2:
> ==============
> - Add the new devarg to validation array (Wenwu)
> - Fix typos in commit messages (Chenbo, checkpatch, Yuying)
>
> Maxime Coquelin (6):
> Revert "app/testpmd: modify mac in csum forwarding"
> vhost: fix missing enqueue pseudo-header calculation
> net/vhost: enable compliant offloading mode
> net/vhost: make VLAN stripping flag a boolean
> net/vhost: perform SW checksum in Rx path
> net/vhost: perform SW checksum in Tx path
>
> app/test-pmd/csumonly.c | 4 -
> doc/guides/nics/features/vhost.ini | 1 +
> doc/guides/nics/vhost.rst | 6 ++
> drivers/net/vhost/rte_eth_vhost.c | 167 ++++++++++++++++++++++++++++-
> lib/vhost/virtio_net.c | 10 ++
> 5 files changed, 180 insertions(+), 8 deletions(-)
>
Applied to dpdk-next-virtio/main.
Thanks,
Maxime
^ permalink raw reply [relevance 0%]
* [PATCH v3 07/13] net/nfp: support firmware with NFDk
@ 2022-06-17 9:34 5% ` Jin Liu
1 sibling, 0 replies; 200+ results
From: Jin Liu @ 2022-06-17 9:34 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
doc/guides/nics/nfp.rst | 7 ++--
doc/guides/rel_notes/release_22_07.rst | 1 +
drivers/net/nfp/nfp_ctrl.h | 2 +
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++-----
drivers/net/nfp/nfp_ethdev_vf.c | 53 +++++++++++++++++++-------
5 files changed, 85 insertions(+), 27 deletions(-)
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index dcefac3ef6..55539accc2 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -100,9 +100,10 @@ more than one SmartNIC, same type of SmartNIC or different ones, and to upload a
different firmware to each SmartNIC.
.. Note::
- Currently the NFP PMD supports using the PF with Agilio Basic Firmware. See
- https://help.netronome.com/support/solutions for more information on the
- various firmwares supported by the Netronome Agilio CX smartNIC.
+ Currently the NFP PMD supports using the PF with Agilio Firmware with NFD3
+ and Agilio Firmware with NFDk. See https://help.netronome.com/support/solutions
+ for more information on the various firmwares supported by the Netronome
+ Agilio CX smartNIC.
PF multiport support
--------------------
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index d5d8c735b1..64308e6c1a 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -111,6 +111,7 @@ New Features
* **Updated Netronome nfp driver.**
* Added support for NFP3800 NIC.
+ * Added support for firmware with NFDk.
* **Updated VMware vmxnet3 networking driver.**
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index cb84dc3188..1bbba9187e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -402,11 +428,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -441,6 +462,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -473,7 +499,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -939,6 +964,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -988,11 +1014,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"secondary process attach failed, ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index c46ee0f913..0b4660aba6 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -265,6 +265,32 @@ static const struct eth_dev_ops nfp_netvf_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_netvf_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_netvf_init(struct rte_eth_dev *eth_dev)
{
@@ -292,10 +318,19 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
- eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_netvf_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -313,15 +348,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -354,7 +380,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
--
2.27.0
^ permalink raw reply [relevance 5%]
* Re: [PATCH v1] bbdev: allow operation type enum for growth
@ 2022-06-17 8:21 3% ` Thomas Monjalon
2022-06-17 16:12 0% ` Chautru, Nicolas
2022-06-23 16:09 0% ` Ray Kinsella
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2022-06-17 8:21 UTC (permalink / raw)
To: Nicolas Chautru
Cc: dev, maxime.coquelin, trix, mdr, bruce.richardson,
hemant.agrawal, david.marchand, stephen, techboard
This solution is what I proposed to the techboard some years ago,
but the preference was to completely remove the MAX values.
13/06/2022 20:24, Nicolas Chautru:
> Updating the last enum for rte_bbdev_op_type
> to allow for enum insertion.
Please explain that the reason is to keep ABI compatible,
and you want to keep the MAX value for array needs.
> --- a/lib/bbdev/rte_bbdev.c
> +++ b/lib/bbdev/rte_bbdev.c
> @@ -1122,7 +1122,10 @@ struct rte_mempool *
> "RTE_BBDEV_OP_TURBO_DEC",
> "RTE_BBDEV_OP_TURBO_ENC",
> "RTE_BBDEV_OP_LDPC_DEC",
> - "RTE_BBDEV_OP_LDPC_ENC",
> + "RTE_BBDEV_OP_RESERVED_1",
> + "RTE_BBDEV_OP_RESERVED_2",
> + "RTE_BBDEV_OP_RESERVED_3",
> + "RTE_BBDEV_OP_RESERVED_4",
As Stephen said, you should make sure that using these values
with the API functions will lead to a clear and expected error.
> @@ -748,7 +748,7 @@ enum rte_bbdev_op_type {
> RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
> RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
> RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
> - RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
> + RTE_BBDEV_OP_TYPE_COUNT = 8, /**< Count of different op types */
You must update the comment to explain there may be a padding,
it is not exactly the count.
Maybe "MAX" is a better fit than "COUNT" in this case.
^ permalink raw reply [relevance 3%]
* [PATCH v2 09/15] net/nfp: support firmware with NFDk
@ 2022-06-16 2:39 5% ` Jin Liu
1 sibling, 0 replies; 200+ results
From: Jin Liu @ 2022-06-16 2:39 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
drivers/net/nfp/nfp_ctrl.h | 2 ++
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++++++-------
drivers/net/nfp/nfp_ethdev_vf.c | 53 ++++++++++++++++++++++++---------
3 files changed, 80 insertions(+), 24 deletions(-)
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index cb84dc3188..1bbba9187e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -402,11 +428,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -441,6 +462,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -473,7 +499,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -939,6 +964,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -988,11 +1014,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"secondary process attach failed, ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index c46ee0f913..0b4660aba6 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -265,6 +265,32 @@ static const struct eth_dev_ops nfp_netvf_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_netvf_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_netvf_init(struct rte_eth_dev *eth_dev)
{
@@ -292,10 +318,19 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
- eth_dev->dev_ops = &nfp_netvf_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_netvf_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -313,15 +348,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -354,7 +380,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
--
2.27.0
^ permalink raw reply [relevance 5%]
* RE: [PATCH 1/5] usertools: use non-strict when json-loads in telemetry
2022-06-15 18:01 3% ` Morten Brørup
@ 2022-06-15 20:09 0% ` Morten Brørup
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-15 20:09 UTC (permalink / raw)
To: Bruce Richardson, Ciara Power, Chengwen Feng
Cc: thomas, ferruh.yigit, kevin.laatz, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
> From: Morten Brørup
> Sent: Wednesday, 15 June 2022 20.01
>
> +CC Ciara Power, Telemetry lib maintainer
>
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 15 June 2022 18.55
> >
> > On Wed, Jun 15, 2022 at 03:54:57PM +0200, Morten Brørup wrote:
> > > > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > > Sent: Wednesday, 15 June 2022 09.39
> > > >
> > > > Use 'strict=False' in json-loads, it will ignore control
> characters
> > > > (e.g. '\n\t'), this patch is prepared for the support of
> telemetry
> > dump
> > > > in the future.
> > > >
> > > > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > > ---
> > > > usertools/dpdk-telemetry.py | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/usertools/dpdk-telemetry.py b/usertools/dpdk-
> > telemetry.py
> > > > index a81868a547..63f8004566 100755
> > > > --- a/usertools/dpdk-telemetry.py
> > > > +++ b/usertools/dpdk-telemetry.py
> > > > @@ -27,7 +27,7 @@ def read_socket(sock, buf_len, echo=True):
> > > > """ Read data from socket and return it in JSON format """
> > > > reply = sock.recv(buf_len).decode()
> > > > try:
> > > > - ret = json.loads(reply)
> > > > + ret = json.loads(reply, strict=False)
> > > > except json.JSONDecodeError:
> > > > print("Error in reply: ", reply)
> > > > sock.close()
> > > > --
> > > > 2.33.0
> > > >
> > >
> > > As I understand this patch, it accepts non-JSON data from the
> > telemetry socket.
> > >
> > > Isn't it is a major protocol violation if the telemetry socket
> > produces output requiring this modification? Doing that would break
> > other applications expecting strictly JSON formatted output from the
> > telemetry socket.
> > >
> >
> > I would tend to agree.
> >
> > As an alternative, I think you should add to the telemetry library an
> > "escape string" function which can then be used by the telemetry
> > functions
> > to properly json encode the strings back from the dump functions
> before
> > sending them out.
>
> Instead of adding a separate JSON encode function, the
> rte_tel_data_string() and rte_tel_data_add_array_string() functions
> should simply JSON encode the provided strings if required. Their
> descriptions do not mention any requirements to the strings provided,
> and being control plane functions, I would certainly expect them to
> JSON encode.
>
> Warning: Although I consider such a change a bugfix, others might
> consider it an ABI breakage. :-(
>
> @Ciara, what is your opinion about my suggestion here?
>
> For minimal changes, RTE_TEL_MAX_STRING_LEN and
> RTE_TEL_MAX_SINGLE_STRING_LEN should keep their meaning, i.e. define
> the maximum length of the string after any JSON encoding.
>
> And optionally, new rte_tel_data_[array_]string_raw() performance
> optimized functions could be provided for strings known not to require
> any encoding.
Forget my suggestion above!!! It would mess up the telemetry database, which could be used for SNMP too, and thus should not be JSON formatted.
Any JSON encoding needs to happen in the presentation layer, which seems to reside in /lib/telemetry/telemetry.c, and it looks like it already does JSON encode strings, except the rte_tel_json_str() function and friends in /lib/telemetry/telemetry_json.h don't implement it.
So the bug is in the JSON string functions in /lib/telemetry/telemetry_json.h: Their descriptions say that they take a string and copy it into a buffer in JSON format, which I interpret as JSON encoding. But they don't JSON encode the string. I have filed a bug in Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1037
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/5] usertools: use non-strict when json-loads in telemetry
@ 2022-06-15 18:01 3% ` Morten Brørup
2022-06-15 20:09 0% ` Morten Brørup
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-15 18:01 UTC (permalink / raw)
To: Bruce Richardson, Ciara Power, Chengwen Feng
Cc: thomas, ferruh.yigit, kevin.laatz, andrew.rybchenko, jerinj,
sachin.saxena, hemant.agrawal, dev
+CC Ciara Power, Telemetry lib maintainer
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 15 June 2022 18.55
>
> On Wed, Jun 15, 2022 at 03:54:57PM +0200, Morten Brørup wrote:
> > > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > > Sent: Wednesday, 15 June 2022 09.39
> > >
> > > Use 'strict=False' in json-loads, it will ignore control characters
> > > (e.g. '\n\t'), this patch is prepared for the support of telemetry
> dump
> > > in the future.
> > >
> > > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > ---
> > > usertools/dpdk-telemetry.py | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/usertools/dpdk-telemetry.py b/usertools/dpdk-
> telemetry.py
> > > index a81868a547..63f8004566 100755
> > > --- a/usertools/dpdk-telemetry.py
> > > +++ b/usertools/dpdk-telemetry.py
> > > @@ -27,7 +27,7 @@ def read_socket(sock, buf_len, echo=True):
> > > """ Read data from socket and return it in JSON format """
> > > reply = sock.recv(buf_len).decode()
> > > try:
> > > - ret = json.loads(reply)
> > > + ret = json.loads(reply, strict=False)
> > > except json.JSONDecodeError:
> > > print("Error in reply: ", reply)
> > > sock.close()
> > > --
> > > 2.33.0
> > >
> >
> > As I understand this patch, it accepts non-JSON data from the
> telemetry socket.
> >
> > Isn't it is a major protocol violation if the telemetry socket
> produces output requiring this modification? Doing that would break
> other applications expecting strictly JSON formatted output from the
> telemetry socket.
> >
>
> I would tend to agree.
>
> As an alternative, I think you should add to the telemetry library an
> "escape string" function which can then be used by the telemetry
> functions
> to properly json encode the strings back from the dump functions before
> sending them out.
Instead of adding a separate JSON encode function, the rte_tel_data_string() and rte_tel_data_add_array_string() functions should simply JSON encode the provided strings if required. Their descriptions do not mention any requirements to the strings provided, and being control plane functions, I would certainly expect them to JSON encode.
Warning: Although I consider such a change a bugfix, others might consider it an ABI breakage. :-(
@Ciara, what is your opinion about my suggestion here?
For minimal changes, RTE_TEL_MAX_STRING_LEN and RTE_TEL_MAX_SINGLE_STRING_LEN should keep their meaning, i.e. define the maximum length of the string after any JSON encoding.
And optionally, new rte_tel_data_[array_]string_raw() performance optimized functions could be provided for strings known not to require any encoding.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] build: ccache support for cross build
2022-06-08 17:13 3% ` [dpdk-dev] [PATCH v2] " jerinj
@ 2022-06-14 16:01 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-14 16:01 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, Jan Viktorin, Ruifeng Wang, Bruce Richardson,
David Christensen, Stanislaw Kardach, Konstantin Ananyev,
david.marchand, juraj.linkes, fengchengwen
08/06/2022 19:13, jerinj@marvell.com:
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -160,7 +160,8 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
> if [ -n "$crossfile" ] ; then
> cross="--cross-file $crossfile"
> targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
> - $crossfile | tr -d "'" | tr -d '"')
> + $crossfile | cut -d ',' -f 2 | \
> + tr -d "'" | tr -d '"' | tr -d ']' | tr -d ' ')
The last line can be shortened to
tr -d "'"'"] '
I'll change while merging.
^ permalink raw reply [relevance 0%]
* RE: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-14 9:21 0% ` Ferruh Yigit
@ 2022-06-14 9:30 0% ` Kevin Liu
0 siblings, 0 replies; 200+ results
From: Kevin Liu @ 2022-06-14 9:30 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: Niklas Soderlund, Diana Wang, Nole Zhang, Chaoyong He
Now, I modify logic, just keep 'nfp_net_tx_queue_release()', delete 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'
>>> My comment was to extract the logic into its own function as it is done is PF, so to have something like 'nfp_netvf_ethdev_ops_mount()'.
the logic I just use once in nfp_ethdev_vf.c, so not create a function. I will create 'nfp_netvf_ethdev_ops_mount()' in nfp_ethdev_vf.c later
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
Sent: Tuesday, June 14, 2022 17:22
To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
On 6/14/2022 9:49 AM, Kevin Liu wrote:
> We also want to just use one function 'nfp_net_tx_queue_release()' to service both NFD3 and NFDk, But we can not get the version of NFD in function 'nfp_net_tx_queue_release()', now get NFD version through 'hw->ver'
>
Again, it is up to you, but it should be possible to add 'dev' or 'hw'
reference to the queue struct, to be able to access the version information.
And it can be possible to have something like 'struct fw_ops', set it during initialization and use in rest of the dev_ops.
> For the function 'nfp_net_ethdev_ops_mount()', the logic below is in two different C files, nfp_ethdev.c and nfp_ethdev_vf.c And the variable of struct eth_dev_ops is defined as static, if we want to use function both in nfp_ethdev.c and nfp_ethdev_vf.c We need to change the eth_dev_ops variable as non-static, this is not we want.
>
> > + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> > + case NFP_NET_CFG_VERSION_DP_NFD3:
> > + break;
> > + case NFP_NET_CFG_VERSION_DP_NFDK:
> > + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> > + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> > + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> > + return -EINVAL;
> > + }
> > + break;
> > + default:
> > + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> > + return -EINVAL;
>
My comment was to extract the logic into its own function as it is done is PF, so to have something like 'nfp_netvf_ethdev_ops_mount()'.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> Sent: Friday, June 3, 2022 06:54
> To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
> Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
> Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
>
> On 6/2/2022 2:52 AM, Jin Liu wrote:
>> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment,
>> will according to the firmware version, mount different driver functions.
>>
>
> Creating a new set of dev_ops for new FW is a way and it works, but it looks like it creates some duplication of the code, and maintaining multiple dev_ops can be difficult (driver already has different ones for PF & VF).
>
> Another option can be keeping ethdev interface same, but manage different FWs closer to FW, where directly interacted with FW.
> Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing different FW within this function, instead of having two dev_ops, 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
> If difference is small, this can be better to reduce duplication.
>
> What is the difference between two FWs, as far as I can see Tx descriptor is different and queue setup is affected, is it only diff?
>
>> Signed-off-by: Jin Liu <jin.liu@corigine.com>
>> Signed-off-by: Diana Wang <na.wang@corigine.com>
>> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>
> <...>
>
>> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
>> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
>> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>>
>> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
>> + if (hw->ctrl_bar == NULL) {
>> + PMD_DRV_LOG(ERR,
>> + "hw->ctrl_bar is NULL. BAR0 not configured");
>> + return -ENODEV;
>> + }
>> +
>> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
>> +
>> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
>> +
>> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
>> + case NFP_NET_CFG_VERSION_DP_NFD3:
>> + break;
>> + case NFP_NET_CFG_VERSION_DP_NFDK:
>> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
>> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
>> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
>> + return -EINVAL;
>> + }
>> + break;
>> + default:
>> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
>> + return -EINVAL;
>> + }
>> +
>
> This part seems extracted to its own function for PF ('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same logic between them.
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-14 8:49 3% ` Kevin Liu
@ 2022-06-14 9:21 0% ` Ferruh Yigit
2022-06-14 9:30 0% ` Kevin Liu
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-06-14 9:21 UTC (permalink / raw)
To: Kevin Liu, dev; +Cc: Niklas Soderlund, Diana Wang, Nole Zhang, Chaoyong He
On 6/14/2022 9:49 AM, Kevin Liu wrote:
> We also want to just use one function 'nfp_net_tx_queue_release()' to service both NFD3 and NFDk, But we can not get the version of NFD in function 'nfp_net_tx_queue_release()', now get NFD version through 'hw->ver'
>
Again, it is up to you, but it should be possible to add 'dev' or 'hw'
reference to the queue struct, to be able to access the version information.
And it can be possible to have something like 'struct fw_ops', set it
during initialization and use in rest of the dev_ops.
> For the function 'nfp_net_ethdev_ops_mount()', the logic below is in two different C files, nfp_ethdev.c and nfp_ethdev_vf.c And the variable of struct eth_dev_ops is defined as static, if we want to use function both in nfp_ethdev.c and nfp_ethdev_vf.c We need to change the eth_dev_ops variable as non-static, this is not we want.
>
> > + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> > + case NFP_NET_CFG_VERSION_DP_NFD3:
> > + break;
> > + case NFP_NET_CFG_VERSION_DP_NFDK:
> > + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> > + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> > + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> > + return -EINVAL;
> > + }
> > + break;
> > + default:
> > + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> > + return -EINVAL;
>
My comment was to extract the logic into its own function as it is done
is PF, so to have something like 'nfp_netvf_ethdev_ops_mount()'.
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> Sent: Friday, June 3, 2022 06:54
> To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
> Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
> Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
>
> On 6/2/2022 2:52 AM, Jin Liu wrote:
>> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment,
>> will according to the firmware version, mount different driver functions.
>>
>
> Creating a new set of dev_ops for new FW is a way and it works, but it looks like it creates some duplication of the code, and maintaining multiple dev_ops can be difficult (driver already has different ones for PF & VF).
>
> Another option can be keeping ethdev interface same, but manage different FWs closer to FW, where directly interacted with FW.
> Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing different FW within this function, instead of having two dev_ops, 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
> If difference is small, this can be better to reduce duplication.
>
> What is the difference between two FWs, as far as I can see Tx descriptor is different and queue setup is affected, is it only diff?
>
>> Signed-off-by: Jin Liu <jin.liu@corigine.com>
>> Signed-off-by: Diana Wang <na.wang@corigine.com>
>> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>
> <...>
>
>> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
>> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
>> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>>
>> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
>> + if (hw->ctrl_bar == NULL) {
>> + PMD_DRV_LOG(ERR,
>> + "hw->ctrl_bar is NULL. BAR0 not configured");
>> + return -ENODEV;
>> + }
>> +
>> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
>> +
>> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
>> +
>> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
>> + case NFP_NET_CFG_VERSION_DP_NFD3:
>> + break;
>> + case NFP_NET_CFG_VERSION_DP_NFDK:
>> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
>> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
>> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
>> + return -EINVAL;
>> + }
>> + break;
>> + default:
>> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
>> + return -EINVAL;
>> + }
>> +
>
> This part seems extracted to its own function for PF ('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same logic between them.
>
>
^ permalink raw reply [relevance 0%]
* RE: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-02 22:53 0% ` Ferruh Yigit
@ 2022-06-14 8:49 3% ` Kevin Liu
2022-06-14 9:21 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Kevin Liu @ 2022-06-14 8:49 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: Niklas Soderlund, Diana Wang, Nole Zhang, Chaoyong He
We also want to just use one function 'nfp_net_tx_queue_release()' to service both NFD3 and NFDk, But we can not get the version of NFD in function 'nfp_net_tx_queue_release()', now get NFD version through 'hw->ver'
For the function 'nfp_net_ethdev_ops_mount()', the logic below is in two different C files, nfp_ethdev.c and nfp_ethdev_vf.c And the variable of struct eth_dev_ops is defined as static, if we want to use function both in nfp_ethdev.c and nfp_ethdev_vf.c We need to change the eth_dev_ops variable as non-static, this is not we want.
> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> + case NFP_NET_CFG_VERSION_DP_NFD3:
> + break;
> + case NFP_NET_CFG_VERSION_DP_NFDK:
> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> + return -EINVAL;
> + }
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> + return -EINVAL;
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
Sent: Friday, June 3, 2022 06:54
To: Kevin Liu <jin.liu@corigine.com>; dev@dpdk.org
Cc: Niklas Soderlund <niklas.soderlund@corigine.com>; Diana Wang <na.wang@corigine.com>; Nole Zhang <peng.zhang@corigine.com>; Chaoyong He <chaoyong.he@corigine.com>
Subject: Re: [PATCH 07/14] net/nfp: support NFDK firmware
On 6/2/2022 2:52 AM, Jin Liu wrote:
> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment,
> will according to the firmware version, mount different driver functions.
>
Creating a new set of dev_ops for new FW is a way and it works, but it looks like it creates some duplication of the code, and maintaining multiple dev_ops can be difficult (driver already has different ones for PF & VF).
Another option can be keeping ethdev interface same, but manage different FWs closer to FW, where directly interacted with FW.
Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing different FW within this function, instead of having two dev_ops, 'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
If difference is small, this can be better to reduce duplication.
What is the difference between two FWs, as far as I can see Tx descriptor is different and queue setup is affected, is it only diff?
> Signed-off-by: Jin Liu <jin.liu@corigine.com>
> Signed-off-by: Diana Wang <na.wang@corigine.com>
> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
<...>
> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>
> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
> + if (hw->ctrl_bar == NULL) {
> + PMD_DRV_LOG(ERR,
> + "hw->ctrl_bar is NULL. BAR0 not configured");
> + return -ENODEV;
> + }
> +
> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
> +
> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
> +
> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> + case NFP_NET_CFG_VERSION_DP_NFD3:
> + break;
> + case NFP_NET_CFG_VERSION_DP_NFDK:
> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> + return -EINVAL;
> + }
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> + return -EINVAL;
> + }
> +
This part seems extracted to its own function for PF ('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same logic between them.
^ permalink raw reply [relevance 3%]
* [PATCH v1] bbdev: allow operation type enum for growth
@ 2022-06-13 18:24 4% Nicolas Chautru
0 siblings, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-13 18:24 UTC (permalink / raw)
To: dev, thomas
Cc: maxime.coquelin, trix, mdr, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
Hi Thomas,
I would like to get your view on this topic and best recommendation moving forward.
This is related to the general intent to remove using MAX value for enums. There is consensus that we should avoid this for a while notably for future-proofed ABI concerns https://patches.dpdk.org/project/dpdk/patch/20200130142003.2645765-1-ferruh.yigit@intel.com/.
But still there is arguably not yet an explicit best recommendation to handle this especially when we actualy need to expose array whose index is such an enum.
As a specific example here I am refering to RTE_BBDEV_OP_TYPE_COUNT in enum rte_bbdev_op_type which is being extended for new operation type being support in bbdev (such as https://patches.dpdk.org/project/dpdk/patch/1646956157-245769-2-git-send-email-nicolas.chautru@intel.com/ adding new FFT operation)
There is also the intent to be able to expose information for each operation type through the bbdev api such as dynamically configured queues information per such operation type https://patches.dpdk.org/project/dpdk/patch/1646785355-168133-2-git-send-email-nicolas.chautru@intel.com/
Basically we are considering best way to accomodate for this, notably based on discussions with Ray Kinsella and Bruce Richardson, to handle such a case moving forward: specifically for the example with RTE_BBDEV_OP_TYPE_COUNT and also more generally.
One possible option is captured in that patchset and is basically based on the simple principle to allow for growth and prevent ABI breakage. Ie. the last value of the enum is set with a higher value than required so that to allow insertion of new enum outside of the major ABI versions.
In that case the RTE_BBDEV_OP_TYPE_COUNT is still present and can be exposed and used while still allowing for addition thanks to the implicit padding-like room. As an alternate variant, instead of using that last enum value, that extended size could be exposed as an #define outside of the enum but would be fundamentally the same (public).
Another option would be to avoid array alltogether and use each time this a new dedicated API function (operation type enum being an input argument instead of an index to an array in an existing structure so that to get access to structure related to a given operation type enum) but that is arguably not well scalable within DPDK to use such a scheme for each enums and keep an uncluttered and clean API. In that very example that would be very odd indeed not to get this simply from info_get().
Some pros and cons, arguably the simple option in that patchset is a valid compromise option and a step in the right direction but we would like to know your view wrt best recommendation, or any other thought.
Note: Such a change is aimed for 22.11.
Thanks and regards,
Nic
Nicolas Chautru (1):
bbdev: allow operation type enum for growth
lib/bbdev/rte_bbdev.c | 5 ++++-
lib/bbdev/rte_bbdev_op.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [PATCH v7] eal: add bus cleanup to eal cleanup
2022-06-07 15:12 3% ` David Marchand
@ 2022-06-13 15:58 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-06-13 15:58 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, Kevin Laatz, dev, Morten Brørup, Li Zhang,
Matan Azrad, Stephen Hemminger, lihuisong
On Tue, Jun 07, 2022 at 05:12:02PM +0200, David Marchand wrote:
> On Tue, Jun 7, 2022 at 1:09 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 03/06/2022 16:36, Kevin Laatz:
> > > During EAL init, all buses are probed and the devices found are
> > > initialized. On eal_cleanup(), the inverse does not happen, meaning any
> > > allocated memory and other configuration will not be cleaned up
> > > appropriately on exit.
> > [...]
> > > --- a/devtools/libabigail.abignore
> > > +++ b/devtools/libabigail.abignore
> > > @@ -56,3 +56,12 @@
> > > ; Ignore libabigail false-positive in clang builds, after moving code.
> > > [suppress_function]
> > > name = rte_eal_remote_launch
> > > +
> > > +; Ignore field inserted to rte_bus, adding cleanup function
> > > +[suppress_type]
> > > + name = rte_bus
> > > + has_data_member_inserted_at = end
> > > +
> > > +; Ignore changes to internally used structs containing rte_bus
> > > +[suppress_type]
> > > + name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus
>
> (This change is strange as there is no rte_vdev_bus type, but I won't
> investigate the relevance of this rule for now).
>
> >
> > I'm not sure we can safely consider these structs as internal.
> > The right process is to send a deprecation notice,
> > and then remove them from the public API.
>
> Same for me, I don't think we can safely ignore.
>
> A rte_bus struct is embedded in rte_pci_bus (resp. rte_vmbus_bus).
> If we make it grow, any inlined access (like walk in device_list or
> driver_list) after the rte_bus object is broken for code accessing it
> out of DPDK.
> Such code might exist out there, since we expose
> FOREACH_DEVICE_ON_PCIBUS, for example.
>
>
> >
> > For info, Li has sent a patch for the bus cleanup
> > which is not updating the bus code:
> > https://patches.dpdk.org/project/dpdk/patch/20220606114650.209612-3-lizh@nvidia.com/
> > It may be a temporary solution before the deprecation.
>
> On the principle, that's probably the best, there is no question about
> unclear frontier of the ABI.
> (In practice though, the mentionned patch is triggering segfaults in
> two CI, for pdump).
>
> Hiding rte_bus object should be straightforward in v22.11, I had some
> patches, but never finished the work.
>
> It would be great too, to look into rte_driver and rte_device which
> are exposed important types, but that's another story.
>
Agreed, we need to look into all this for 22.11 release, let's defer this
patch until we get proper deprecation process. Temporary patch looks fine
as a fix too.
/Bruce
^ permalink raw reply [relevance 0%]
* [PATCH v4] sched: enable CMAN at runtime
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2022-06-08 11:59 0% ` Dumitrescu, Cristian
@ 2022-06-13 9:09 1% ` Marcin Danilewicz
2022-06-17 11:48 0% ` Dumitrescu, Cristian
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
1 sibling, 2 replies; 200+ results
From: Marcin Danilewicz @ 2022-06-13 9:09 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 8eb29c1525..1740a1d053 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-#undef RTE_SCHED_CMAN
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 599c7e9536..c5fa9e4582 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1084,7 +1080,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1166,7 +1161,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
@@ -1285,7 +1279,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
/* TC oversubscription is enabled by default */
s->tc_ov_enabled = 1;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1297,7 +1290,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1823,7 +1815,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1849,21 +1841,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1908,13 +1896,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1933,29 +1919,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events
2022-05-24 15:11 0% ` Ray Kinsella
@ 2022-06-10 0:16 0% ` fengchengwen
0 siblings, 0 replies; 200+ results
From: fengchengwen @ 2022-06-10 0:16 UTC (permalink / raw)
To: Ray Kinsella
Cc: Thomas Monjalon, Ferruh Yigit, Kalesh A P, dev, ajit.khaparde,
asafp, David Marchand, Andrew Rybchenko, lizhenyi1,
shuliubin 00419723
On 2022/5/24 23:11, Ray Kinsella wrote:
>
> fengchengwen <fengchengwen@huawei.com> writes:
>
>> Hi all,
>>
>> This patch lasts for a long time. Are we waiting for 22.11 to deal with it?
>
> That was my read, as can't reliably change the value of _MAX at this
> stage without it having impact elsewhere.
>
>
>> We have the same requirements for the reset or recovery mechanism, but there are differences:
>>
>> APP PMD
>> | |
>> | detect error
>> | <---report error event--- |
>> | |
>> do error stats |
>> and report |
>> | ---start recover--> |
>> | do recover
>> | <---report recover result |
>> | |
>> if succ just log
>> else may migrate
>> service
>>
>> Can we generalize these processes(means that the implementation is at the framework layer)? or only at PMD API?
>>
>>
>> On 2022/2/15 0:06, Ray Kinsella wrote:
>>>
>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>
>>>> 14/02/2022 11:16, Ray Kinsella:
>>>>> Ray Kinsella <mdr@ashroe.eu> writes:
>>>>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>>>>> 02/02/2022 12:44, Ray Kinsella:
>>>>>>>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>>>>>>>> On 1/28/2022 12:48 PM, Kalesh A P wrote:
>>>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>>>> @@ -3818,6 +3818,24 @@ enum rte_eth_event_type {
>>>>>>>>>> RTE_ETH_EVENT_DESTROY, /**< port is released */
>>>>>>>>>> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */
>>>>>>>>>> RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
>>>>>>>>>> + RTE_ETH_EVENT_ERR_RECOVERING,
>>>>>>>>>> + /**< port recovering from an error
>>>>>>>>>> + *
>>>>>>>>>> + * PMD detected a FW reset or error condition.
>>>>>>>>>> + * PMD will try to recover from the error.
>>>>>>>>>> + * Data path may be quiesced and Control path operations
>>>>>>>>>> + * may fail at this time.
>>>>>>>>>> + */
I think we should standard error reason which could pass to application, so that
application know the really reason. the error reason could as the ret_param of
rte_eth_dev_callback_process().
But I think it could be done later.
>>>>>>>>>> + RTE_ETH_EVENT_RECOVERED,
>>>>>>>>>> + /**< port recovered from an error
>>>>>>>>>> + *
>>>>>>>>>> + * PMD has recovered from the error condition.
>>>>>>>>>> + * Control path and Data path are up now.
>>>>>>>>>> + * PMD re-configures the port to the state prior to the error.
>>>>>>>>>> + * Since the device has undergone a reset, flow rules
>>>>>>>>>> + * offloaded prior to reset may be lost and
>>>>>>>>>> + * the application should recreate the rules again.
>>>>>>>>>> + */
please add RTE_ETH_EVENT_RECOVER_FAIL event, the RTE_ETH_EVENT_INTR_RMV event is
a big event, it has its own usecase. So please add the RECOVER_FAIL event to let
application decide remove or keep it.
>>>>>>>>>> RTE_ETH_EVENT_MAX /**< max value of this enum */
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also ABI check complains about 'RTE_ETH_EVENT_MAX' value check, cc'ed more people
>>>>>>>>> to evaluate if it is a false positive:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1 function with some indirect sub-type change:
>>>>>>>>> [C] 'function int rte_eth_dev_callback_register(uint16_t, rte_eth_event_type, rte_eth_dev_cb_fn, void*)' at rte_ethdev.c:4637:1 has some indirect sub-type changes:
>>>>>>>>> parameter 3 of type 'typedef rte_eth_dev_cb_fn' has sub-type changes:
>>>>>>>>> underlying type 'int (typedef uint16_t, enum rte_eth_event_type, void*, void*)*' changed:
>>>>>>>>> in pointed to type 'function type int (typedef uint16_t, enum rte_eth_event_type, void*, void*)':
>>>>>>>>> parameter 2 of type 'enum rte_eth_event_type' has sub-type changes:
>>>>>>>>> type size hasn't changed
>>>>>>>>> 2 enumerator insertions:
>>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_ERR_RECOVERING' value '11'
>>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_RECOVERED' value '12'
>>>>>>>>> 1 enumerator change:
>>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_MAX' from value '11' to '13' at rte_ethdev.h:3807:1
>>>>>>>>
>>>>>>>> I don't immediately see the problem that this would cause.
>>>>>>>> There are no array sizes etc dependent on the value of MAX for instance.
>>>>>>>>
>>>>>>>> Looks safe?
>>>>>>>
>>>>>>> We never know how this enum will be used by the application.
>>>>>>> The max value may be used for the size of an event array.
>>>>>>> It looks a real ABI issue unfortunately.
>>>>>>
>>>>>> Right - but we only really care about it when an array size based on MAX
>>>>>> is likely to be passed to DPDK, which doesn't apply in this case.
>>>>
>>>> I don't completely agree.
>>>> A developer may assume an event will never exceed MAX value.
>>>> However, after an upgrade of DPDK without app rebuild,
>>>> a higher event value may be received in the app,
>>>> breaking the assumption.
>>>> Should we consider this case as an ABI breakage?
>>>
>>> Nope - I think we should explicitly exclude MAX values from any
>>> ABI guarantee, as being able to change them is key to our be able to
>>> evolve DPDK while maintaining ABI stability.
>>>
>>> Consider what it means applying the ABI policy to a MAX value, you are
>>> in effect saying that that no value can be added to this enumeration
>>> until the next ABI version, for me this is very restrictive without a
>>> solid reason.
>>>
>>>>
>>>>>> I noted that some Linux folks explicitly mark similar MAX values as not
>>>>>> part of the ABI.
>>>>>>
>>>>>> /usr/include/linux/perf_event.h
>>>>>> 37: PERF_TYPE_MAX, /* non-ABI */
>>>>>> 60: PERF_COUNT_HW_MAX, /* non-ABI */
>>>>>> 79: PERF_COUNT_HW_CACHE_MAX, /* non-ABI */
>>>>>> 87: PERF_COUNT_HW_CACHE_OP_MAX, /* non-ABI */
>>>>>> 94: PERF_COUNT_HW_CACHE_RESULT_MAX, /* non-ABI */
>>>>>> 116: PERF_COUNT_SW_MAX, /* non-ABI */
>>>>>> 149: PERF_SAMPLE_MAX = 1U << 24, /* non-ABI */
>>>>>> 151: __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /*
>>>>>> non-ABI; internal use */
>>>>>> 189: PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */
>>>>>> 267: PERF_TXN_MAX = (1 << 8), /* non-ABI */
>>>>>> 301: PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
>>>>>> 1067: PERF_RECORD_MAX, /* non-ABI */
>>>>>> 1078: PERF_RECORD_KSYMBOL_TYPE_MAX /* non-ABI */
>>>>>> 1087: PERF_BPF_EVENT_MAX, /* non-ABI */
>>>>>
>>>>> Any thoughts on similarly annotating all our _MAX enums in the same way?
>>>>> We could also add a section in the ABI Policy to make it explicit _MAX
>>>>> enum values are not part of the ABI - what do folks think?
>>>>
>>>> Interesting. I am not sure it is always ABI-safe though.
>>>
>>>
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
2022-06-09 7:05 0% ` Thomas Monjalon
@ 2022-06-10 0:01 3% ` fengchengwen
0 siblings, 0 replies; 200+ results
From: fengchengwen @ 2022-06-10 0:01 UTC (permalink / raw)
To: Thomas Monjalon, Kalesh A P
Cc: Andrew Rybchenko, Spike Du, dev, Xiaoyun Li, Aman Singh,
Yuying Zhang, Ferruh Yigit, Ray Kinsella
Hi Thomas,
On 2022/6/9 15:05, Thomas Monjalon wrote:
> 09/06/2022 02:17, fengchengwen:
>> Hi Thomas,
>>
>> Could it possible accept the patch ' [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events'
>> which was delayed by ABI exceptions like this patch ?
>
> I suppose you refer to this explanation:
Yes
>
> +; Ignore ethdev event enum update
> +; because new event cannot be received if not registered
>
> That's true we discussed in the past that it should have no effect
> on applications compiled with an old version of DPDK.
>
>> PS: I noticed RC-1 was released just now and there may be no window left, but I think since this patch can be an
>> exception, why not that patch ?
>
> As far as I remember, the reset and recovery events patch
> have other comments to address before it can be accepted.
Yes, but the ABI exceptions is the primary cause of blockage.
There's two weeks left to fully discuss I think.
We have product requirements for this feature ("device reset and recovery events"), So:
Hi kalesh-anakkur,
Could you please send a new version about it ? If not, do you mind if I re-develop over it ?
>
>
>
> .
>
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
@ 2022-06-09 7:53 0% ` Maxime Coquelin
2022-06-17 16:13 0% ` Chautru, Nicolas
2022-07-05 15:45 0% ` Bruce Richardson
2 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-09 7:53 UTC (permalink / raw)
To: Nicolas Chautru, dev, gakhil, thomas
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen
Hi Nicolas,
On 6/9/22 02:34, Nicolas Chautru wrote:
> Intent to resolve in DPDK 22.11 historical usage which prevents
> graceful extension of enum and API without troublesome ABI breakage
> as well as extending API RTE_BBDEV_OP_FFT for new operation type
> in bbdev as well as other new members in existing structures.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..c8ab1ec 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -112,6 +112,17 @@ Deprecation Notices
> session and the private data of session. An opaque pointer can be exposed
> directly to application which can be attached to the ``rte_crypto_op``.
>
> +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
> + enum will be deprecated and instead use fixed array size when required to allow for
> + future enum extension.
> + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
> + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
> + New members will be added in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired
> + by this RFC https://patches.dpdk.org/project/dpdk/list/?series=22076
> + New member will be added in ``rte_bbdev_driver_info`` to expose the device status as per
> + this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
> + This should be updated in DPDK 22.11.
> +
> * security: Hide structure ``rte_security_session`` and expose an opaque
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
Thanks for rewording the notice.
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
2022-06-09 0:17 3% ` fengchengwen
@ 2022-06-09 7:05 0% ` Thomas Monjalon
2022-06-10 0:01 3% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-09 7:05 UTC (permalink / raw)
To: fengchengwen
Cc: Andrew Rybchenko, Spike Du, dev, Xiaoyun Li, Aman Singh,
Yuying Zhang, Ferruh Yigit, Ray Kinsella, mdr
09/06/2022 02:17, fengchengwen:
> Hi Thomas,
>
> Could it possible accept the patch ' [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events'
> which was delayed by ABI exceptions like this patch ?
I suppose you refer to this explanation:
+; Ignore ethdev event enum update
+; because new event cannot be received if not registered
That's true we discussed in the past that it should have no effect
on applications compiled with an old version of DPDK.
> PS: I noticed RC-1 was released just now and there may be no window left, but I think since this patch can be an
> exception, why not that patch ?
As far as I remember, the reset and recovery events patch
have other comments to address before it can be accepted.
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` Nicolas Chautru
@ 2022-06-09 5:14 0% ` Hemant Agrawal
2022-06-09 7:53 0% ` Maxime Coquelin
2022-07-05 15:45 0% ` Bruce Richardson
2 siblings, 0 replies; 200+ results
From: Hemant Agrawal @ 2022-06-09 5:14 UTC (permalink / raw)
To: Nicolas Chautru, dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, david.marchand, stephen
> -----Original Message-----
> From: Nicolas Chautru <nicolas.chautru@intel.com>
> Sent: Thursday, June 9, 2022 6:05 AM
> To: dev@dpdk.org; gakhil@marvell.com; thomas@monjalon.net;
> maxime.coquelin@redhat.com
> Cc: trix@redhat.com; ray.kinsella@intel.com; bruce.richardson@intel.com;
> Hemant Agrawal <hemant.agrawal@nxp.com>;
> david.marchand@redhat.com; stephen@networkplumber.org; Nicolas
> Chautru <nicolas.chautru@intel.com>
> Subject: [PATCH v4] doc: announce changes in bbdev related to enum
> extension
> Importance: High
>
> Intent to resolve in DPDK 22.11 historical usage which prevents graceful
> extension of enum and API without troublesome ABI breakage as well as
> extending API RTE_BBDEV_OP_FFT for new operation type in bbdev as well
> as other new members in existing structures.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..c8ab1ec 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -112,6 +112,17 @@ Deprecation Notices
> session and the private data of session. An opaque pointer can be exposed
> directly to application which can be attached to the ``rte_crypto_op``.
>
> +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the
> +``rte_bbdev_op_type``
> + enum will be deprecated and instead use fixed array size when
> +required to allow for
> + future enum extension.
> + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as
> +per this
> + RFC
> +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> h
> +work.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D22111&da
> ta=05%7
> +C01%7Chemant.agrawal%40nxp.com%7Ce8c1b946f9ba4152d02d08da49b1
> 5297%7C686
> +ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637903323196944926%7C
> Unknown%7C
> +TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI
> +6Mn0%3D%7C3000%7C%7C%7C&sdata=zDwsoIF4tF0eP2py43nwUHUz
> pS3XlDTQDiRMd
> +JxBqwg%3D&reserved=0
> + New members will be added in ``rte_bbdev_driver_info`` to expose PMD
> +queue topology inspired
> + by this RFC
> +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> h
> +es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D22076&data=
> 05%7C0
> +1%7Chemant.agrawal%40nxp.com%7Ce8c1b946f9ba4152d02d08da49b152
> 97%7C686ea
> +1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637903323196944926%7CUn
> known%7CTW
> +FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6M
> +n0%3D%7C3000%7C%7C%7C&sdata=tx8iueWoLEbbCyFQFQHKsvs9nkib
> c0ANem5dyai
> +mspQ%3D&reserved=0
> + New member will be added in ``rte_bbdev_driver_info`` to expose the
> +device status as per
> + this RFC
> +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> h
> +es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D23367&data=
> 05%7C0
> +1%7Chemant.agrawal%40nxp.com%7Ce8c1b946f9ba4152d02d08da49b152
> 97%7C686ea
> +1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637903323196944926%7CUn
> known%7CTW
> +FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6M
> +n0%3D%7C3000%7C%7C%7C&sdata=rHnuL7B63SoFIIo1M4kdRnnDm0
> xqmCwML8CEo%2
> +BsxDBA%3D&reserved=0
> + This should be updated in DPDK 22.11.
> +
> * security: Hide structure ``rte_security_session`` and expose an opaque
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply [relevance 0%]
* [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:34 3% ` [PATCH v4] " Nicolas Chautru
@ 2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:34 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
Intent to resolve in DPDK 22.11 historical usage which prevents
graceful extension of enum and API without troublesome ABI breakage
as well as extending API RTE_BBDEV_OP_FFT for new operation type
in bbdev as well as other new members in existing structures.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c..c8ab1ec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -112,6 +112,17 @@ Deprecation Notices
session and the private data of session. An opaque pointer can be exposed
directly to application which can be attached to the ``rte_crypto_op``.
+* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
+ enum will be deprecated and instead use fixed array size when required to allow for
+ future enum extension.
+ Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
+ RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
+ New members will be added in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired
+ by this RFC https://patches.dpdk.org/project/dpdk/list/?series=22076
+ New member will be added in ``rte_bbdev_driver_info`` to expose the device status as per
+ this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
+ This should be updated in DPDK 22.11.
+
* security: Hide structure ``rte_security_session`` and expose an opaque
pointer for the private data to the application which can be attached
to the packet while enqueuing.
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v4] doc: announce changes in bbdev related to enum extension
2022-06-09 0:20 3% ` [PATCH v3] " Nicolas Chautru
@ 2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 0:34 3% ` Nicolas Chautru
1 sibling, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:34 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
v4: correcting typo. Hemant, Maxime kindly review/ack.
v3: being more explicit wrt the list of intended changes for 22.11
v2: indentation fix
Realizing when submitting new bbdev operation in this patch
(https://patchwork.dpdk.org/project/dpdk/list/?series=22111) that this is not workable in practice to extend this API into 22.07 without fundamental ABI breakage even by using existing versionning framework.
Some existing learnings to be applied here to prevent extension being blocked, hence accouncing changes in bbdev intended for 22.11 to make this more future-proof, including dropping max value from enum, as well as deferring extension of the API for FFT operation into DPDK 22.11.
Let me know if any comments or in case this should be captured differently.
Thanks
Nic
Nicolas Chautru (1):
doc: announce changes in bbdev related to enum extension
doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v3] doc: announce changes in bbdev related to enum extension
2022-06-09 0:20 3% ` [PATCH v3] " Nicolas Chautru
@ 2022-06-09 0:20 3% ` Nicolas Chautru
0 siblings, 0 replies; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:20 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
Intent to resolve in DPDK 22.11 historical usage which prevents
graceful extension of enum and API without troublesome ABI breakage
as well as extending API RTE_BBDEV_OP_FFT for new operation type
in bbdev as well as other new members in existing structures.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c..c75f43e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -112,6 +112,16 @@ Deprecation Notices
session and the private data of session. An opaque pointer can be exposed
directly to application which can be attached to the ``rte_crypto_op``.
+* bbdev: Will be deprecating ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
+ and use fixed array size when required to allow for future enum extension.
+ Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
+ RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
+ Will be adding new members in ``rte_bbdev_driver_info`` to expose PMD queue topology inspired
+ by this RFC https://patches.dpdk.org/project/dpdk/list/?series=22076
+ Will be adding new member in ``rte_bbdev_driver_info`` to expose the device status as per
+ this RFC https://patches.dpdk.org/project/dpdk/list/?series=23367
+ This should be updated in DPDK 22.11.
+
* security: Hide structure ``rte_security_session`` and expose an opaque
pointer for the private data to the application which can be attached
to the packet while enqueuing.
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [PATCH v3] doc: announce changes in bbdev related to enum extension
@ 2022-06-09 0:20 3% ` Nicolas Chautru
2022-06-09 0:20 3% ` Nicolas Chautru
2022-06-09 0:34 3% ` [PATCH v4] " Nicolas Chautru
1 sibling, 1 reply; 200+ results
From: Nicolas Chautru @ 2022-06-09 0:20 UTC (permalink / raw)
To: dev, gakhil, thomas, maxime.coquelin
Cc: trix, ray.kinsella, bruce.richardson, hemant.agrawal,
david.marchand, stephen, Nicolas Chautru
v3: being more explicit wrt the list of intended changes for 22.11
v2: indentation fix
Realizing when submitting new bbdev operation in this patch
(https://patchwork.dpdk.org/project/dpdk/list/?series=22111) that this is not workable in practice to extend this API into 22.07 without fundamental ABI breakage even by using existing versionning framework.
Some existing learnings to be applied here to prevent extension being blocked, hence accouncing changes in bbdev intended for 22.11 to make this more future-proof, including dropping max value from enum, as well as deferring extension of the API for FFT operation into DPDK 22.11.
Let me know if any comments or in case this should be captured differently.
Thanks
Nic
Nicolas Chautru (1):
doc: announce changes in bbdev related to enum extension
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
2022-06-08 17:46 3% ` Thomas Monjalon
@ 2022-06-09 0:17 3% ` fengchengwen
2022-06-09 7:05 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: fengchengwen @ 2022-06-09 0:17 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko, Spike Du
Cc: dev, Xiaoyun Li, Aman Singh, Yuying Zhang, Ferruh Yigit,
Ray Kinsella, mdr
Hi Thomas,
Could it possible accept the patch ' [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events'
which was delayed by ABI exceptions like this patch ?
PS: I noticed RC-1 was released just now and there may be no window left, but I think since this patch can be an
exception, why not that patch ?
Thanks.
On 2022/6/9 1:46, Thomas Monjalon wrote:
> 08/06/2022 19:22, Thomas Monjalon:
>> 08/06/2022 18:35, Andrew Rybchenko:
>>> From: Spike Du <spiked@nvidia.com>
>>>
>>> A new event RTE_ETH_EVENT_RX_AVAIL_THRESH should be generated by HW
>>> when number of available descriptors in Rx queue goes below the
>>> threshold.
>>>
>>> The threshold is defined as a percentage of an Rx queue size with valid
>>> values from 0 to 99 (inclusive). Zero (default) value disables it.
>>>
>>> There is no capability reporting for the feature. Application should
>>> simply try to set required threshold value and handle result.
>>>
>>> Add testpmd commands to control the threshold:
>>> set port <port_id> rxq <rxq_id> avail_thresh <avail_thresh_num>
>>>
>>> Signed-off-by: Spike Du <spiked@nvidia.com>
>>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>> ---
>>> v6:
>>> - try to make descriptor shorter and more useful
>>> - refine terminology to use "available descriptors threshold"
>>> everywhere (plural "descriptors")
>>> - fix ethdev API documenation
>>> - define negative return values
>>> - define rules to convert percentage to descriptors number
>>> in drivers
>>> - avoid extra checks in testpmd helper to allow ethdev API
>>> to do its job
>>> - minor fixes in testpmd variables naming
>>> - fix testpmd help to be human oriented
>>> - update testpmd users guide
>>> - add release notes
>>
>> What a (more than) review work, thanks a lot for this v6!
>>
>> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>>
>> With a few minor arrangements,
>> applied, thanks.
>
> PS: some ABI exceptions have to be added as discussed in the thread:
>
> +; Ignore ethdev event enum update
> +; because new event cannot be received if not registered
> +[suppress_type]
> + type_kind = enum
> + changed_enumerators = RTE_ETH_EVENT_MAX
> +
> +; Ignore fields inserted in cacheline boundary of rte_eth_rxq_info
> +; because the struct size is unchanged
> +[suppress_type]
> + name = rte_eth_rxq_info
> + has_data_member_inserted_between = {offset_of(rx_buf_size), end}
>
>
>
>
>
> .
>
^ permalink raw reply [relevance 3%]
* RE: [PATCH v1] bbdev: add device status info
2022-06-07 16:42 0% ` Stephen Hemminger
@ 2022-06-08 22:44 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2022-06-08 22:44 UTC (permalink / raw)
To: Stephen Hemminger, Maxime Coquelin
Cc: dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
Hi Stephen,
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, June 7, 2022 9:43 AM
> To: Maxime Coquelin <maxime.coquelin@redhat.com>
> Cc: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> gakhil@marvell.com; trix@redhat.com; hemant.agrawal@nxp.com; Vargas,
> Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v1] bbdev: add device status info
>
> On Tue, 7 Jun 2022 18:20:38 +0200
> Maxime Coquelin <maxime.coquelin@redhat.com> wrote:
>
> > Hi Nicolas,
> >
> > On 6/7/22 17:44, Chautru, Nicolas wrote:
> > > Hi Maxime,
> > >
> > >> -----Original Message-----
> > >> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> > >> Sent: Tuesday, June 7, 2022 5:43 AM
> > >> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru,
> > >> Nicolas <nicolas.chautru@intel.com>
> > >> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
> > >> hemant.agrawal@nxp.com; Vargas, Hernan
> <hernan.vargas@intel.com>
> > >> Subject: Re: [PATCH v1] bbdev: add device status info
> > >>
> > >> Hi Stephen,
> > >>
> > >> On 6/7/22 02:09, Stephen Hemminger wrote:
> > >>> On Mon, 6 Jun 2022 15:50:08 -0700 Nicolas Chautru
> > >>> <nicolas.chautru@intel.com> wrote:
> > >>>
> > >>>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> > >>>> const struct rte_bbdev_op_cap *capabilities;
> > >>>> /** Device cpu_flag requirements */
> > >>>> const enum rte_cpu_flag_t *cpu_flag_reqs;
> > >>>> + /** Device Status */
> > >>>> + enum rte_bbdev_device_status device_status;
> > >>>> };
> > >>>>
> > >>>
> > >>> This ends up being an ABI breakage, can't change a struct like
> > >>> that until 22.11 release.
> > >>>
> > >>
> > >> Indeed, but Nicolas mentioned in the cover-letter that the patch
> > >> targets v22.11; not this release.
> > >>
> > >> However, a deprecation notice should be sent for v22.07 if it
> > >> hasn't been done yet.
> > >
> > > I have sent this deprecation Maxime:
> > > https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-s
> > > end-email-nicolas.chautru@intel.com/
> > > Do you believe this needs to be extended to cover more details the
> > > change and including this device status info explicitly? I can
> > > update the verbiage in more details if required
> >
> > Thanks for the pointer, I missed it.
> > Reading the deprecation notice, it is not clear to me it is about the
> > device status info enum.
> >
> > Maybe rewording it a bit to be more specific would help.
>
> You might want to use one the existing empty padding slots (holes) in that
> structure. It appears to have been laid out haphazardly.
>
I don't see such one single hole to fill that enum but I can shuffle a bit that structure. In that case total size would no longer change but a few offsets would differ and padding would be reduced.
Thanks
Nic
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6] ethdev: introduce available Rx descriptors threshold
@ 2022-06-08 17:46 3% ` Thomas Monjalon
2022-06-09 0:17 3% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-08 17:46 UTC (permalink / raw)
To: Andrew Rybchenko, Spike Du
Cc: dev, Xiaoyun Li, Aman Singh, Yuying Zhang, Ferruh Yigit,
Ray Kinsella, dev
08/06/2022 19:22, Thomas Monjalon:
> 08/06/2022 18:35, Andrew Rybchenko:
> > From: Spike Du <spiked@nvidia.com>
> >
> > A new event RTE_ETH_EVENT_RX_AVAIL_THRESH should be generated by HW
> > when number of available descriptors in Rx queue goes below the
> > threshold.
> >
> > The threshold is defined as a percentage of an Rx queue size with valid
> > values from 0 to 99 (inclusive). Zero (default) value disables it.
> >
> > There is no capability reporting for the feature. Application should
> > simply try to set required threshold value and handle result.
> >
> > Add testpmd commands to control the threshold:
> > set port <port_id> rxq <rxq_id> avail_thresh <avail_thresh_num>
> >
> > Signed-off-by: Spike Du <spiked@nvidia.com>
> > Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > ---
> > v6:
> > - try to make descriptor shorter and more useful
> > - refine terminology to use "available descriptors threshold"
> > everywhere (plural "descriptors")
> > - fix ethdev API documenation
> > - define negative return values
> > - define rules to convert percentage to descriptors number
> > in drivers
> > - avoid extra checks in testpmd helper to allow ethdev API
> > to do its job
> > - minor fixes in testpmd variables naming
> > - fix testpmd help to be human oriented
> > - update testpmd users guide
> > - add release notes
>
> What a (more than) review work, thanks a lot for this v6!
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>
> With a few minor arrangements,
> applied, thanks.
PS: some ABI exceptions have to be added as discussed in the thread:
+; Ignore ethdev event enum update
+; because new event cannot be received if not registered
+[suppress_type]
+ type_kind = enum
+ changed_enumerators = RTE_ETH_EVENT_MAX
+
+; Ignore fields inserted in cacheline boundary of rte_eth_rxq_info
+; because the struct size is unchanged
+[suppress_type]
+ name = rte_eth_rxq_info
+ has_data_member_inserted_between = {offset_of(rx_buf_size), end}
^ permalink raw reply [relevance 3%]
* Re: [PATCH] devtools: unify cross-compilation tests
2022-06-08 16:34 4% ` David Marchand
@ 2022-06-08 17:20 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-08 17:20 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Bruce Richardson
08/06/2022 18:34, David Marchand:
> On Wed, Jun 8, 2022 at 5:50 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > Reduce the number of Arm builds from 3 to 1:
> > only generic armv8 with GCC.
> > The specific PPC builds on Ubuntu are skipped.
> >
> > The build directories for PPC and RISC-V
> > are also renamed for consistency:
> > - build-arm64-generic-gcc
> > - build-ppc64-power8-gcc
> > - build-riscv64-generic-gcc
> >
> > The cross file is always saved in variable "f" for readability.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>
> Thanks, this reduction is something I already had locally (via some
> configuration).
>
> I like the renaming, though this change will trigger ABI reference
> regeneration for people who do test ABI.
>
> Otherwise the change lgtm.
> Acked-by: David Marchand <david.marchand@redhat.com>
Applied quickly before -rc1.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] build: ccache support for cross build
@ 2022-06-08 17:13 3% ` jerinj
2022-06-14 16:01 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: jerinj @ 2022-06-08 17:13 UTC (permalink / raw)
To: dev, Jan Viktorin, Ruifeng Wang, Bruce Richardson,
David Christensen, Stanislaw Kardach, Konstantin Ananyev
Cc: thomas, david.marchand, juraj.linkes, fengchengwen, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
By default, ccache is not used for cross build[1].
Update all cross files to use ccache if it is available
in build machine.
Also, updated devtools/test-meson-builds.sh
script to find the correct DPDK_TARGET due to
change in cross file syntax.
[1]
https://mesonbuild.com/Machine-files.html
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
v2:
- Rebased with master, therefore added update riscv64 cross files
- Fixed DPDK_TARGET detection with devtools/test-meson-builds.sh
due to cross file synatx update.
config/arm/arm32_armv8_linux_gcc | 4 ++--
config/arm/arm64_armada_linux_gcc | 4 ++--
config/arm/arm64_armv8_linux_clang_ubuntu | 4 ++--
config/arm/arm64_armv8_linux_gcc | 4 ++--
config/arm/arm64_bluefield_linux_gcc | 4 ++--
config/arm/arm64_centriq2400_linux_gcc | 4 ++--
config/arm/arm64_cn10k_linux_gcc | 4 ++--
config/arm/arm64_cn9k_linux_gcc | 4 ++--
config/arm/arm64_dpaa_linux_gcc | 4 ++--
config/arm/arm64_emag_linux_gcc | 4 ++--
config/arm/arm64_graviton2_linux_gcc | 4 ++--
config/arm/arm64_kunpeng920_linux_gcc | 4 ++--
config/arm/arm64_kunpeng930_linux_gcc | 4 ++--
config/arm/arm64_n1sdp_linux_gcc | 4 ++--
config/arm/arm64_n2_linux_gcc | 4 ++--
config/arm/arm64_stingray_linux_gcc | 4 ++--
config/arm/arm64_thunderx2_linux_gcc | 4 ++--
config/arm/arm64_thunderxt83_linux_gcc | 4 ++--
config/arm/arm64_thunderxt88_linux_gcc | 4 ++--
config/ppc/ppc64le-power8-linux-gcc | 4 ++--
config/ppc/ppc64le-power8-linux-gcc-ubuntu | 4 ++--
config/riscv/riscv64_linux_gcc | 4 ++--
config/riscv/riscv64_sifive_u740_linux_gcc | 4 ++--
config/x86/cross-mingw | 4 ++--
devtools/test-meson-builds.sh | 3 ++-
25 files changed, 50 insertions(+), 49 deletions(-)
diff --git a/config/arm/arm32_armv8_linux_gcc b/config/arm/arm32_armv8_linux_gcc
index 89f8a12881..7f2977e49d 100644
--- a/config/arm/arm32_armv8_linux_gcc
+++ b/config/arm/arm32_armv8_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'arm-linux-gnueabihf-gcc'
-cpp = 'arm-linux-gnueabihf-cpp'
+c = ['ccache', 'arm-linux-gnueabihf-gcc']
+cpp = ['ccache', 'arm-linux-gnueabihf-cpp']
ar = 'arm-linux-gnueabihf-gcc-ar'
strip = 'arm-linux-gnueabihf-strip'
pkgconfig = 'arm-linux-gnueabihf-pkg-config'
diff --git a/config/arm/arm64_armada_linux_gcc b/config/arm/arm64_armada_linux_gcc
index 301418949b..1566999101 100644
--- a/config/arm/arm64_armada_linux_gcc
+++ b/config/arm/arm64_armada_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-ar'
as = 'aarch64-linux-gnu-as'
strip = 'aarch64-linux-gnu-strip'
diff --git a/config/arm/arm64_armv8_linux_clang_ubuntu b/config/arm/arm64_armv8_linux_clang_ubuntu
index db488d75f4..86ae43937b 100644
--- a/config/arm/arm64_armv8_linux_clang_ubuntu
+++ b/config/arm/arm64_armv8_linux_clang_ubuntu
@@ -1,6 +1,6 @@
[binaries]
-c = 'clang'
-cpp = 'clang++'
+c = ['ccache', 'clang']
+cpp = ['ccache', 'clang++']
ar = 'llvm-ar'
strip = 'llvm-strip'
llvm-config = 'llvm-config'
diff --git a/config/arm/arm64_armv8_linux_gcc b/config/arm/arm64_armv8_linux_gcc
index 5391d35389..048c2d9f29 100644
--- a/config/arm/arm64_armv8_linux_gcc
+++ b/config/arm/arm64_armv8_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_bluefield_linux_gcc b/config/arm/arm64_bluefield_linux_gcc
index 248a9f031a..38df3c198b 100644
--- a/config/arm/arm64_bluefield_linux_gcc
+++ b/config/arm/arm64_bluefield_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_centriq2400_linux_gcc b/config/arm/arm64_centriq2400_linux_gcc
index dfe9110331..0966eef2c5 100644
--- a/config/arm/arm64_centriq2400_linux_gcc
+++ b/config/arm/arm64_centriq2400_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_cn10k_linux_gcc b/config/arm/arm64_cn10k_linux_gcc
index a3578c03a1..201e0ccd59 100644
--- a/config/arm/arm64_cn10k_linux_gcc
+++ b/config/arm/arm64_cn10k_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_cn9k_linux_gcc b/config/arm/arm64_cn9k_linux_gcc
index a94b44a551..a9b4d51958 100644
--- a/config/arm/arm64_cn9k_linux_gcc
+++ b/config/arm/arm64_cn9k_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_dpaa_linux_gcc b/config/arm/arm64_dpaa_linux_gcc
index e9d5fd31fc..0d5761bd72 100644
--- a/config/arm/arm64_dpaa_linux_gcc
+++ b/config/arm/arm64_dpaa_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-ar'
as = 'aarch64-linux-gnu-as'
strip = 'aarch64-linux-gnu-strip'
diff --git a/config/arm/arm64_emag_linux_gcc b/config/arm/arm64_emag_linux_gcc
index 9cdd931180..16ec49fc32 100644
--- a/config/arm/arm64_emag_linux_gcc
+++ b/config/arm/arm64_emag_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_graviton2_linux_gcc b/config/arm/arm64_graviton2_linux_gcc
index 8016fd236c..094c540f50 100644
--- a/config/arm/arm64_graviton2_linux_gcc
+++ b/config/arm/arm64_graviton2_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_kunpeng920_linux_gcc b/config/arm/arm64_kunpeng920_linux_gcc
index c4685b2458..fc057c9063 100644
--- a/config/arm/arm64_kunpeng920_linux_gcc
+++ b/config/arm/arm64_kunpeng920_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_kunpeng930_linux_gcc b/config/arm/arm64_kunpeng930_linux_gcc
index fb85d2d710..5f43941fae 100644
--- a/config/arm/arm64_kunpeng930_linux_gcc
+++ b/config/arm/arm64_kunpeng930_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_n1sdp_linux_gcc b/config/arm/arm64_n1sdp_linux_gcc
index 0df283e2f4..fc123ab53f 100644
--- a/config/arm/arm64_n1sdp_linux_gcc
+++ b/config/arm/arm64_n1sdp_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_n2_linux_gcc b/config/arm/arm64_n2_linux_gcc
index 036aee2b0a..930bd5c236 100644
--- a/config/arm/arm64_n2_linux_gcc
+++ b/config/arm/arm64_n2_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_stingray_linux_gcc b/config/arm/arm64_stingray_linux_gcc
index 319a4a151d..5dfcd974fd 100644
--- a/config/arm/arm64_stingray_linux_gcc
+++ b/config/arm/arm64_stingray_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_thunderx2_linux_gcc b/config/arm/arm64_thunderx2_linux_gcc
index 69c71cbc82..c1f5995d93 100644
--- a/config/arm/arm64_thunderx2_linux_gcc
+++ b/config/arm/arm64_thunderx2_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_thunderxt83_linux_gcc b/config/arm/arm64_thunderxt83_linux_gcc
index 47102c900b..52746e2e59 100644
--- a/config/arm/arm64_thunderxt83_linux_gcc
+++ b/config/arm/arm64_thunderxt83_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/arm/arm64_thunderxt88_linux_gcc b/config/arm/arm64_thunderxt88_linux_gcc
index 372097ba01..fed7eb791e 100644
--- a/config/arm/arm64_thunderxt88_linux_gcc
+++ b/config/arm/arm64_thunderxt88_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'aarch64-linux-gnu-gcc'
-cpp = 'aarch64-linux-gnu-cpp'
+c = ['ccache', 'aarch64-linux-gnu-gcc']
+cpp = ['ccache', 'aarch64-linux-gnu-cpp']
ar = 'aarch64-linux-gnu-gcc-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'
diff --git a/config/ppc/ppc64le-power8-linux-gcc b/config/ppc/ppc64le-power8-linux-gcc
index 51f7ceebf3..465044e427 100644
--- a/config/ppc/ppc64le-power8-linux-gcc
+++ b/config/ppc/ppc64le-power8-linux-gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'powerpc64le-linux-gcc'
-cpp = 'powerpc64le-linux-cpp'
+c = ['ccache', 'powerpc64le-linux-gcc']
+cpp = ['ccache', 'powerpc64le-linux-cpp']
ar = 'powerpc64le-linux-gcc-ar'
strip = 'powerpc64le-linux-strip'
diff --git a/config/ppc/ppc64le-power8-linux-gcc-ubuntu b/config/ppc/ppc64le-power8-linux-gcc-ubuntu
index 803c612cbc..44d7e0100a 100644
--- a/config/ppc/ppc64le-power8-linux-gcc-ubuntu
+++ b/config/ppc/ppc64le-power8-linux-gcc-ubuntu
@@ -1,6 +1,6 @@
[binaries]
-c = 'powerpc64le-linux-gnu-gcc'
-cpp = 'powerpc64le-linux-gnu-cpp'
+c = ['ccache', 'powerpc64le-linux-gnu-gcc']
+cpp = ['ccache', 'powerpc64le-linux-gnu-cpp']
ar = 'powerpc64le-linux-gnu-ar'
strip = 'powerpc64le-linux-gnu-strip'
diff --git a/config/riscv/riscv64_linux_gcc b/config/riscv/riscv64_linux_gcc
index ed4d3ce7fb..5e58781193 100644
--- a/config/riscv/riscv64_linux_gcc
+++ b/config/riscv/riscv64_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'riscv64-linux-gnu-gcc'
-cpp = 'riscv64-linux-gnu-g++'
+c = ['ccache', 'riscv64-linux-gnu-gcc']
+cpp = ['ccache', 'riscv64-linux-gnu-g++']
ar = 'riscv64-linux-gnu-ar'
strip = 'riscv64-linux-gnu-strip'
pcap-config = ''
diff --git a/config/riscv/riscv64_sifive_u740_linux_gcc b/config/riscv/riscv64_sifive_u740_linux_gcc
index 3d1905c434..58d2c92f8c 100644
--- a/config/riscv/riscv64_sifive_u740_linux_gcc
+++ b/config/riscv/riscv64_sifive_u740_linux_gcc
@@ -1,6 +1,6 @@
[binaries]
-c = 'riscv64-unknown-linux-gnu-gcc'
-cpp = 'riscv64-unknown-linux-gnu-g++'
+c = ['ccache', 'riscv64-unknown-linux-gnu-gcc']
+cpp = ['ccache', 'riscv64-unknown-linux-gnu-g++']
ar = 'riscv64-unknown-linux-gnu-ar'
strip = 'riscv64-unknown-linux-gnu-strip'
pcap-config = ''
diff --git a/config/x86/cross-mingw b/config/x86/cross-mingw
index 09f7af0928..cddebda5b5 100644
--- a/config/x86/cross-mingw
+++ b/config/x86/cross-mingw
@@ -1,6 +1,6 @@
[binaries]
-c = 'x86_64-w64-mingw32-gcc'
-cpp = 'x86_64-w64-mingw32-g++'
+c = ['ccache', 'x86_64-w64-mingw32-gcc']
+cpp = ['ccache', 'x86_64-w64-mingw32-g++']
ld = 'x86_64-w64-mingw32-ld'
ar = 'x86_64-w64-mingw32-ar'
strip = 'x86_64-w64-mingw32-strip'
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index f732dccf6c..e44a2b1995 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -160,7 +160,8 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
if [ -n "$crossfile" ] ; then
cross="--cross-file $crossfile"
targetcc=$(sed -n 's,^c[[:space:]]*=[[:space:]]*,,p' \
- $crossfile | tr -d "'" | tr -d '"')
+ $crossfile | cut -d ',' -f 2 | \
+ tr -d "'" | tr -d '"' | tr -d ']' | tr -d ' ')
else
cross=
fi
--
2.36.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH] devtools: unify cross-compilation tests
2022-06-08 15:50 15% [PATCH] devtools: unify cross-compilation tests Thomas Monjalon
@ 2022-06-08 16:34 4% ` David Marchand
2022-06-08 17:20 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-06-08 16:34 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bruce Richardson
On Wed, Jun 8, 2022 at 5:50 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Reduce the number of Arm builds from 3 to 1:
> only generic armv8 with GCC.
> The specific PPC builds on Ubuntu are skipped.
>
> The build directories for PPC and RISC-V
> are also renamed for consistency:
> - build-arm64-generic-gcc
> - build-ppc64-power8-gcc
> - build-riscv64-generic-gcc
>
> The cross file is always saved in variable "f" for readability.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Thanks, this reduction is something I already had locally (via some
configuration).
I like the renaming, though this change will trigger ABI reference
regeneration for people who do test ABI.
Otherwise the change lgtm.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 4%]
* [PATCH v6] pcap: support MTU set for linux interafces
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
@ 2022-06-08 16:04 3% ` Ido Goshen
0 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-08 16:04 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v6:
Fixes for v5 approach
1. freebsd compilation fix
2. checkpatch warning fix
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 42 ++++++++++++++++++++++++++
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 +++++
drivers/net/pcap/pcap_osdep_linux.c | 21 +++++++++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 +++++
6 files changed, 81 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 0ed4f92820..b90cfefc55 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -95,6 +95,9 @@ New Features
* Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
* Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
+* **Updated pcap driver.**
+
+ * Added support for MTU on Linux network interfaces
Removed Items
-------------
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..2221c53051 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -807,6 +807,47 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ unsigned int i;
+ struct pmd_internals *internals = dev->data->dev_private;
+ int is_supported = 0;
+ int is_err = 0;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ struct pcap_rx_queue *queue = &internals->rx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_IN_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ struct pcap_tx_queue *queue = &internals->tx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_TX_IFACE_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ if (!is_supported)
+ return -ENOTSUP;
+
+ if (is_err)
+ return -1;
+
+ PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1045,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
diff --git a/drivers/net/pcap/pcap_osdep.h b/drivers/net/pcap/pcap_osdep.h
index bf41cba982..ef8be7543c 100644
--- a/drivers/net/pcap/pcap_osdep.h
+++ b/drivers/net/pcap/pcap_osdep.h
@@ -14,5 +14,6 @@ extern int eth_pcap_logtype;
int osdep_iface_index_get(const char *name);
int osdep_iface_mac_get(const char *name, struct rte_ether_addr *mac);
+int osdep_iface_mtu_set(const char *if_name, uint16_t mtu);
#endif
diff --git a/drivers/net/pcap/pcap_osdep_freebsd.c b/drivers/net/pcap/pcap_osdep_freebsd.c
index 20556b3e92..a9961ba3e3 100644
--- a/drivers/net/pcap/pcap_osdep_freebsd.c
+++ b/drivers/net/pcap/pcap_osdep_freebsd.c
@@ -57,3 +57,10 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
rte_free(buf);
return 0;
}
+
+int
+osdep_iface_mtu_set(__rte_unused const char *if_name, __rte_unused uint16_t mtu)
+{
+ PMD_LOG(ERR, "mtu set not supported on freebsd\n");
+ return -ENOTSUP;
+}
diff --git a/drivers/net/pcap/pcap_osdep_linux.c b/drivers/net/pcap/pcap_osdep_linux.c
index 97033f57c5..b0b4a716fe 100644
--- a/drivers/net/pcap/pcap_osdep_linux.c
+++ b/drivers/net/pcap/pcap_osdep_linux.c
@@ -40,3 +40,24 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
close(if_fd);
return 0;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ struct ifreq ifr;
+ int if_fd = socket(AF_INET, SOCK_DGRAM, 0);
+
+ if (if_fd == -1)
+ return -1;
+
+ rte_strscpy(ifr.ifr_name, if_name, sizeof(ifr.ifr_name));
+ ifr.ifr_mtu = mtu;
+ if (ioctl(if_fd, SIOCSIFMTU, &ifr)) {
+ PMD_LOG(ERR, "%s mtu set to %d failed\n", if_name, mtu);
+ close(if_fd);
+ return -1;
+ }
+
+ close(if_fd);
+ return 0;
+}
diff --git a/drivers/net/pcap/pcap_osdep_windows.c b/drivers/net/pcap/pcap_osdep_windows.c
index 1d398dc7ed..69cf052e6d 100644
--- a/drivers/net/pcap/pcap_osdep_windows.c
+++ b/drivers/net/pcap/pcap_osdep_windows.c
@@ -116,3 +116,10 @@ osdep_iface_mac_get(const char *device_name, struct rte_ether_addr *mac)
free(info);
return ret;
}
+
+int
+osdep_iface_mtu_set(__rte_unused const char *if_name, __rte_unused uint16_t mtu)
+{
+ PMD_LOG(ERR, "mtu set not supported on Windows\n");
+ return -ENOTSUP;
+}
--
2.17.1
^ permalink raw reply [relevance 3%]
* [PATCH] devtools: unify cross-compilation tests
@ 2022-06-08 15:50 15% Thomas Monjalon
2022-06-08 16:34 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-08 15:50 UTC (permalink / raw)
To: dev; +Cc: david.marchand, Bruce Richardson
Reduce the number of Arm builds from 3 to 1:
only generic armv8 with GCC.
The specific PPC builds on Ubuntu are skipped.
The build directories for PPC and RISC-V
are also renamed for consistency:
- build-arm64-generic-gcc
- build-ppc64-power8-gcc
- build-riscv64-generic-gcc
The cross file is always saved in variable "f" for readability.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
devtools/test-meson-builds.sh | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index f732dccf6c..2cdc2d813d 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -253,31 +253,20 @@ if check_cc_flags '-m32' ; then
fi
# x86 MinGW
-build build-x86-mingw $srcdir/config/x86/cross-mingw skipABI \
- -Dexamples=helloworld
+f=$srcdir/config/x86/cross-mingw
+build build-x86-mingw $f skipABI -Dexamples=helloworld
-# generic armv8a with clang as host compiler
+# generic armv8
f=$srcdir/config/arm/arm64_armv8_linux_gcc
-export CC="clang"
-build build-arm64-host-clang $f ABI $use_shared
-unset CC
-# some gcc/arm configurations
-for f in $srcdir/config/arm/arm64_[bdo]*gcc ; do
- export CC="$CCACHE gcc"
- targetdir=build-$(basename $f | tr '_' '-' | cut -d'-' -f-2)
- build $targetdir $f skipABI $use_shared
- unset CC
-done
+build build-arm64-generic-gcc $f ABI $use_shared
-# ppc configurations
-for f in $srcdir/config/ppc/ppc* ; do
- targetdir=build-$(basename $f | cut -d'-' -f-2)
- build $targetdir $f ABI $use_shared
-done
+# IBM POWER
+f=$srcdir/config/ppc/ppc64le-power8-linux-gcc
+build build-ppc64-power8-gcc $f ABI $use_shared
-# RISC-V configuration
-build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
- $use_shared
+# generic RISC-V
+f=$srcdir/config/riscv/riscv64_linux_gcc
+build build-riscv64-generic-gcc $f ABI $use_shared
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
--
2.36.0
^ permalink raw reply [relevance 15%]
* RE: [PATCH v3] sched: enable CMAN at runtime
2022-06-08 11:59 0% ` Dumitrescu, Cristian
@ 2022-06-08 15:29 0% ` Danilewicz, MarcinX
0 siblings, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-06-08 15:29 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
Hi Cristian,
Ok, let me check.
BR,
/Marcin
> -----Original Message-----
> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Sent: Wednesday, June 8, 2022 1:59 PM
> To: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>; dev@dpdk.org;
> Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>; Liu, Yu Y
> <yu.y.liu@intel.com>
> Subject: RE: [PATCH v3] sched: enable CMAN at runtime
>
>
>
> > -----Original Message-----
> > From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> > Sent: Wednesday, June 8, 2022 10:42 AM
> > To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> > Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> > Cc: Ajmera, Megha <megha.ajmera@intel.com>
> > Subject: [PATCH v3] sched: enable CMAN at runtime
> >
> > Added changes to enable CMAN (RED or PIE) at init from profile
> > configuration file.
> >
> > By default CMAN code is enable but not in use, when there is no RED or
> > PIE profile configured.
> >
> > Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> > ---
> > Log: v2 change in rte_sched.h to avoid ABI breakage.
> > v3 changes from comments
> > ---
>
> Marcin,
>
> Your patch does not apply cleanly on top of DPDK main latest, can you please
> fix.
>
> Regards,
> Cristian
^ permalink raw reply [relevance 0%]
* [PATCH v2 0/6] Vhost checksum offload improvements
@ 2022-06-08 12:49 3% Maxime Coquelin
2022-06-17 14:06 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-08 12:49 UTC (permalink / raw)
To: dev, jasowang, chenbo.xia, david.marchand, olivier.matz,
wenwux.ma, yuying.zhang, aman.deep.singh
Cc: Maxime Coquelin
This series aims at improving Vhost checksum offloading
support.
The first patch reverts overwritting MAC address in
testpmd CSUM forward mode. This is required to be able to
test checksum offloading with real traffic. MAC forwarding
mode should be used if the MAC addresses need to be
changed.
Second patch is a Vhost library fix to be compliant with
the Virtio specification, which requires that the
pseudo-header checksum is being set by the device when
offloading the checksum to the guest.
Third patch enables the compliant offloading mode of Vhost
library in Vhost PMD by default, since the legacy mode
violates the mbuf API by setting Tx flags in the receive
path. A new devarg is introduced for application willing
to use the legacy mode.
Fourth patch is just a small cleanup to represent a boolean
value as a boolean.
The two last patches introduces compatibility layers
that performs checksum in SW when the ethdev and Virtio
features are not aligned.
Note that the two last patches are not tagged as fixes
because they rely on the new compliant offload mode of
Vhost library, and so would casue an ABI breakage if
backported.
With this series, it is now possible to perform IO
forwarding between a vhost-user port and a Vitio-user
with kernel backend port even if the guest has negotiated
VIRTIO_NET_F_CSUM.
With csum forward mode, it now works whathever the
offloading configuration set either on Virtio or Ethdev
sides.
Changes in v2:
==============
- Add the new devarg to validation array (Wenwu)
- Fix typos in commit messages (Chenbo, checkpatch, Yuying)
Maxime Coquelin (6):
Revert "app/testpmd: modify mac in csum forwarding"
vhost: fix missing enqueue pseudo-header calculation
net/vhost: enable compliant offloading mode
net/vhost: make VLAN stripping flag a boolean
net/vhost: perform SW checksum in Rx path
net/vhost: perform SW checksum in Tx path
app/test-pmd/csumonly.c | 4 -
doc/guides/nics/features/vhost.ini | 1 +
doc/guides/nics/vhost.rst | 6 ++
drivers/net/vhost/rte_eth_vhost.c | 167 ++++++++++++++++++++++++++++-
lib/vhost/virtio_net.c | 10 ++
5 files changed, 180 insertions(+), 8 deletions(-)
--
2.35.3
^ permalink raw reply [relevance 3%]
* RE: [PATCH v3] sched: enable CMAN at runtime
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
@ 2022-06-08 11:59 0% ` Dumitrescu, Cristian
2022-06-08 15:29 0% ` Danilewicz, MarcinX
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
1 sibling, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2022-06-08 11:59 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Wednesday, June 8, 2022 10:42 AM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v3] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> Log: v2 change in rte_sched.h to avoid ABI breakage.
> v3 changes from comments
> ---
Marcin,
Your patch does not apply cleanly on top of DPDK main latest, can you please fix.
Regards,
Cristian
^ permalink raw reply [relevance 0%]
* [PATCH v3] sched: enable CMAN at runtime
2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 11:35 0% ` Dumitrescu, Cristian
@ 2022-06-08 9:42 1% ` Marcin Danilewicz
2022-06-08 11:59 0% ` Dumitrescu, Cristian
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
2 siblings, 2 replies; 200+ results
From: Marcin Danilewicz @ 2022-06-08 9:42 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enable but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
---
Log: v2 change in rte_sched.h to avoid ABI breakage.
v3 changes from comments
---
config/rte_config.h | 3 -
drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
examples/ip_pipeline/tmgr.c | 4 -
examples/qos_sched/cfg_file.c | 11 +-
examples/qos_sched/cfg_file.h | 2 -
examples/qos_sched/init.c | 4 -
examples/qos_sched/main.h | 2 -
examples/qos_sched/profile.cfg | 130 ++++++++++-----------
examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
lib/sched/rte_sched.c | 47 +-------
11 files changed, 359 insertions(+), 141 deletions(-)
create mode 100644 examples/qos_sched/profile_pie.cfg
create mode 100644 examples/qos_sched/profile_red.cfg
diff --git a/config/rte_config.h b/config/rte_config.h
index 8eb29c1525..1740a1d053 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,9 +88,6 @@
/* rte_power defines */
#define RTE_MAX_LCORE_FREQS 64
-/* rte_sched defines */
-#undef RTE_SCHED_CMAN
-
/* rte_graph defines */
#define RTE_GRAPH_BURST_SIZE 256
#define RTE_LIBRTE_GRAPH_STATS 1
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index 6a7766ba1c..3a5fd676e9 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -420,11 +420,7 @@ pmd_tm_node_type_get(struct rte_eth_dev *dev,
return 0;
}
-#ifdef RTE_SCHED_CMAN
#define WRED_SUPPORTED 1
-#else
-#define WRED_SUPPORTED 0
-#endif
#define STATS_MASK_DEFAULT \
(RTE_TM_STATS_N_PKTS | \
@@ -2300,8 +2296,6 @@ tm_tc_wred_profile_get(struct rte_eth_dev *dev, uint32_t tc_id)
return NULL;
}
-#ifdef RTE_SCHED_CMAN
-
static void
wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
{
@@ -2325,12 +2319,6 @@ wred_profiles_set(struct rte_eth_dev *dev, uint32_t subport_id)
}
}
-#else
-
-#define wred_profiles_set(dev, subport_id)
-
-#endif
-
static struct tm_shared_shaper *
tm_tc_shared_shaper_get(struct rte_eth_dev *dev, struct tm_node *tc_node)
{
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index b138e885cf..e68e9961be 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -17,7 +17,6 @@ static uint32_t n_subport_profiles;
static struct rte_sched_pipe_params
pipe_profile[TMGR_PIPE_PROFILE_MAX];
-#ifdef RTE_SCHED_CMAN
static struct rte_sched_cman_params cman_params = {
.red_params = {
/* Traffic Class 0 Colors Green / Yellow / Red */
@@ -86,7 +85,6 @@ static struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
static uint32_t n_pipe_profiles;
@@ -96,9 +94,7 @@ static const struct rte_sched_subport_params subport_params_default = {
.pipe_profiles = pipe_profile,
.n_pipe_profiles = 0, /* filled at run time */
.n_max_pipe_profiles = RTE_DIM(pipe_profile),
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
};
static struct tmgr_port_list tmgr_port_list;
diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index 450482f07d..3284b4d252 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -229,11 +229,14 @@ cfg_load_subport_profile(struct rte_cfgfile *cfg,
return 0;
}
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p)
{
int j, k;
+
+ if (subport_p->cman_params != NULL)
+ return;
+
subport_p->cman_params->cman_mode = cman_p.cman_mode;
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
@@ -261,7 +264,6 @@ void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
}
}
}
-#endif
int
cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport_params)
@@ -276,9 +278,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
memset(active_queues, 0, sizeof(active_queues));
n_active_queues = 0;
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
- .cman_mode = RTE_SCHED_CMAN_RED,
.red_params = { },
};
@@ -387,7 +387,6 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
-#endif /* RTE_SCHED_CMAN */
for (i = 0; i < MAX_SCHED_SUBPORTS; i++) {
char sec_name[CFG_NAME_LEN];
@@ -465,9 +464,7 @@ cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subpo
}
}
}
-#ifdef RTE_SCHED_CMAN
set_subport_cman_params(subport_params+i, cman_params);
-#endif
}
}
diff --git a/examples/qos_sched/cfg_file.h b/examples/qos_sched/cfg_file.h
index 1a9dce9db5..19df91e7ba 100644
--- a/examples/qos_sched/cfg_file.h
+++ b/examples/qos_sched/cfg_file.h
@@ -12,10 +12,8 @@ int cfg_load_port(struct rte_cfgfile *cfg, struct rte_sched_port_params *port);
int cfg_load_pipe(struct rte_cfgfile *cfg, struct rte_sched_pipe_params *pipe);
-#ifdef RTE_SCHED_CMAN
void set_subport_cman_params(struct rte_sched_subport_params *subport_p,
struct rte_sched_cman_params cman_p);
-#endif
int cfg_load_subport(struct rte_cfgfile *cfg, struct rte_sched_subport_params *subport);
diff --git a/examples/qos_sched/init.c b/examples/qos_sched/init.c
index 8a0fb8a374..0afd553283 100644
--- a/examples/qos_sched/init.c
+++ b/examples/qos_sched/init.c
@@ -201,7 +201,6 @@ static struct rte_sched_subport_profile_params
},
};
-#ifdef RTE_SCHED_CMAN
struct rte_sched_cman_params cman_params = {
.cman_mode = RTE_SCHED_CMAN_RED,
.red_params = {
@@ -271,7 +270,6 @@ struct rte_sched_cman_params cman_params = {
[12][2] = {.min_th = 32, .max_th = 64, .maxp_inv = 10, .wq_log2 = 9},
},
};
-#endif /* RTE_SCHED_CMAN */
struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
{
@@ -281,9 +279,7 @@ struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS] = {
.n_pipe_profiles = sizeof(pipe_profiles) /
sizeof(struct rte_sched_pipe_params),
.n_max_pipe_profiles = MAX_SCHED_PIPE_PROFILES,
-#ifdef RTE_SCHED_CMAN
.cman_params = &cman_params,
-#endif /* RTE_SCHED_CMAN */
},
};
diff --git a/examples/qos_sched/main.h b/examples/qos_sched/main.h
index 915311bac8..76a68f585f 100644
--- a/examples/qos_sched/main.h
+++ b/examples/qos_sched/main.h
@@ -153,9 +153,7 @@ extern uint32_t active_queues[RTE_SCHED_QUEUES_PER_PIPE];
extern uint32_t n_active_queues;
extern struct rte_sched_port_params port_params;
-#ifdef RTE_SCHED_CMAN
extern struct rte_sched_cman_params cman_params;
-#endif
extern struct rte_sched_subport_params subport_params[MAX_SCHED_SUBPORTS];
int app_parse_args(int argc, char **argv);
diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg
index d4b21c0170..db65b0ed01 100644
--- a/examples/qos_sched/profile.cfg
+++ b/examples/qos_sched/profile.cfg
@@ -142,68 +142,68 @@ tc 12 wrr weights = 1 1 1 1
;tc 12 wred inv prob = 10 10 10
;tc 12 wred weight = 9 9 9
-[pie]
-tc 0 qdelay ref = 15
-tc 0 max burst = 150
-tc 0 update interval = 15
-tc 0 tailq th = 64
-
-tc 1 qdelay ref = 15
-tc 1 max burst = 150
-tc 1 update interval = 15
-tc 1 tailq th = 64
-
-tc 2 qdelay ref = 15
-tc 2 max burst = 150
-tc 2 update interval = 15
-tc 2 tailq th = 64
-
-tc 3 qdelay ref = 15
-tc 3 max burst = 150
-tc 3 update interval = 15
-tc 3 tailq th = 64
-
-tc 4 qdelay ref = 15
-tc 4 max burst = 150
-tc 4 update interval = 15
-tc 4 tailq th = 64
-
-tc 5 qdelay ref = 15
-tc 5 max burst = 150
-tc 5 update interval = 15
-tc 5 tailq th = 64
-
-tc 6 qdelay ref = 15
-tc 6 max burst = 150
-tc 6 update interval = 15
-tc 6 tailq th = 64
-
-tc 7 qdelay ref = 15
-tc 7 max burst = 150
-tc 7 update interval = 15
-tc 7 tailq th = 64
-
-tc 8 qdelay ref = 15
-tc 8 max burst = 150
-tc 8 update interval = 15
-tc 8 tailq th = 64
-
-tc 9 qdelay ref = 15
-tc 9 max burst = 150
-tc 9 update interval = 15
-tc 9 tailq th = 64
-
-tc 10 qdelay ref = 15
-tc 10 max burst = 150
-tc 10 update interval = 15
-tc 10 tailq th = 64
-
-tc 11 qdelay ref = 15
-tc 11 max burst = 150
-tc 11 update interval = 15
-tc 11 tailq th = 64
-
-tc 12 qdelay ref = 15
-tc 12 max burst = 150
-tc 12 update interval = 15
-tc 12 tailq th = 64
+;[pie]
+;tc 0 qdelay ref = 15
+;tc 0 max burst = 150
+;tc 0 update interval = 15
+;tc 0 tailq th = 64
+
+;tc 1 qdelay ref = 15
+;tc 1 max burst = 150
+;tc 1 update interval = 15
+;tc 1 tailq th = 64
+
+;tc 2 qdelay ref = 15
+;tc 2 max burst = 150
+;tc 2 update interval = 15
+;tc 2 tailq th = 64
+
+;tc 3 qdelay ref = 15
+;tc 3 max burst = 150
+;tc 3 update interval = 15
+;tc 3 tailq th = 64
+
+;tc 4 qdelay ref = 15
+;tc 4 max burst = 150
+;tc 4 update interval = 15
+;tc 4 tailq th = 64
+
+;tc 5 qdelay ref = 15
+;tc 5 max burst = 150
+;tc 5 update interval = 15
+;tc 5 tailq th = 64
+
+;tc 6 qdelay ref = 15
+;tc 6 max burst = 150
+;tc 6 update interval = 15
+;tc 6 tailq th = 64
+
+;tc 7 qdelay ref = 15
+;tc 7 max burst = 150
+;tc 7 update interval = 15
+;tc 7 tailq th = 64
+
+;tc 8 qdelay ref = 15
+;tc 8 max burst = 150
+;tc 8 update interval = 15
+;tc 8 tailq th = 64
+
+;tc 9 qdelay ref = 15
+;tc 9 max burst = 150
+;tc 9 update interval = 15
+;tc 9 tailq th = 64
+
+;tc 10 qdelay ref = 15
+;tc 10 max burst = 150
+;tc 10 update interval = 15
+;tc 10 tailq th = 64
+
+;tc 11 qdelay ref = 15
+;tc 11 max burst = 150
+;tc 11 update interval = 15
+;tc 11 tailq th = 64
+
+;tc 12 qdelay ref = 15
+;tc 12 max burst = 150
+;tc 12 update interval = 15
+;tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_pie.cfg b/examples/qos_sched/profile_pie.cfg
new file mode 100644
index 0000000000..241f748b33
--- /dev/null
+++ b/examples/qos_sched/profile_pie.cfg
@@ -0,0 +1,142 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+[pie]
+tc 0 qdelay ref = 15
+tc 0 max burst = 150
+tc 0 update interval = 15
+tc 0 tailq th = 64
+
+tc 1 qdelay ref = 15
+tc 1 max burst = 150
+tc 1 update interval = 15
+tc 1 tailq th = 64
+
+tc 2 qdelay ref = 15
+tc 2 max burst = 150
+tc 2 update interval = 15
+tc 2 tailq th = 64
+
+tc 3 qdelay ref = 15
+tc 3 max burst = 150
+tc 3 update interval = 15
+tc 3 tailq th = 64
+
+tc 4 qdelay ref = 15
+tc 4 max burst = 150
+tc 4 update interval = 15
+tc 4 tailq th = 64
+
+tc 5 qdelay ref = 15
+tc 5 max burst = 150
+tc 5 update interval = 15
+tc 5 tailq th = 64
+
+tc 6 qdelay ref = 15
+tc 6 max burst = 150
+tc 6 update interval = 15
+tc 6 tailq th = 64
+
+tc 7 qdelay ref = 15
+tc 7 max burst = 150
+tc 7 update interval = 15
+tc 7 tailq th = 64
+
+tc 8 qdelay ref = 15
+tc 8 max burst = 150
+tc 8 update interval = 15
+tc 8 tailq th = 64
+
+tc 9 qdelay ref = 15
+tc 9 max burst = 150
+tc 9 update interval = 15
+tc 9 tailq th = 64
+
+tc 10 qdelay ref = 15
+tc 10 max burst = 150
+tc 10 update interval = 15
+tc 10 tailq th = 64
+
+tc 11 qdelay ref = 15
+tc 11 max burst = 150
+tc 11 update interval = 15
+tc 11 tailq th = 64
+
+tc 12 qdelay ref = 15
+tc 12 max burst = 150
+tc 12 update interval = 15
+tc 12 tailq th = 64
diff --git a/examples/qos_sched/profile_red.cfg b/examples/qos_sched/profile_red.cfg
new file mode 100644
index 0000000000..4486d2799e
--- /dev/null
+++ b/examples/qos_sched/profile_red.cfg
@@ -0,0 +1,143 @@
+; SPDX-License-Identifier: BSD-3-Clause
+; Copyright(c) 2010-2019 Intel Corporation.
+
+; This file enables the following hierarchical scheduler configuration for each
+; 10GbE output port:
+; * Single subport (subport 0):
+; - Subport rate set to 100% of port rate
+; - Each of the 13 traffic classes has rate set to 100% of port rate
+; * 4K pipes per subport 0 (pipes 0 .. 4095) with identical configuration:
+; - Pipe rate set to 1/4K of port rate
+; - Each of the 13 traffic classes has rate set to 100% of pipe rate
+; - Within lowest priority traffic class (best-effort), the byte-level
+; WRR weights for the 4 queues of best effort traffic class are set
+; to 1:1:1:1
+;
+; For more details, please refer to chapter "Quality of Service (QoS) Framework"
+; of Data Plane Development Kit (DPDK) Programmer's Guide.
+
+; Port configuration
+[port]
+frame overhead = 24
+number of subports per port = 1
+
+; Subport configuration
+[subport 0]
+number of pipes per subport = 4096
+queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64
+
+subport 0-8 = 0 ; These subports are configured with subport profile 0
+
+[subport profile 0]
+tb rate = 1250000000 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 1250000000 ; Bytes per second
+tc 1 rate = 1250000000 ; Bytes per second
+tc 2 rate = 1250000000 ; Bytes per second
+tc 3 rate = 1250000000 ; Bytes per second
+tc 4 rate = 1250000000 ; Bytes per second
+tc 5 rate = 1250000000 ; Bytes per second
+tc 6 rate = 1250000000 ; Bytes per second
+tc 7 rate = 1250000000 ; Bytes per second
+tc 8 rate = 1250000000 ; Bytes per second
+tc 9 rate = 1250000000 ; Bytes per second
+tc 10 rate = 1250000000 ; Bytes per second
+tc 11 rate = 1250000000 ; Bytes per second
+tc 12 rate = 1250000000 ; Bytes per second
+
+tc period = 10 ; Milliseconds
+
+pipe 0-4095 = 0 ; These pipes are configured with pipe profile 0
+
+; Pipe configuration
+[pipe profile 0]
+tb rate = 305175 ; Bytes per second
+tb size = 1000000 ; Bytes
+
+tc 0 rate = 305175 ; Bytes per second
+tc 1 rate = 305175 ; Bytes per second
+tc 2 rate = 305175 ; Bytes per second
+tc 3 rate = 305175 ; Bytes per second
+tc 4 rate = 305175 ; Bytes per second
+tc 5 rate = 305175 ; Bytes per second
+tc 6 rate = 305175 ; Bytes per second
+tc 7 rate = 305175 ; Bytes per second
+tc 8 rate = 305175 ; Bytes per second
+tc 9 rate = 305175 ; Bytes per second
+tc 10 rate = 305175 ; Bytes per second
+tc 11 rate = 305175 ; Bytes per second
+tc 12 rate = 305175 ; Bytes per second
+
+tc period = 40 ; Milliseconds
+
+tc 12 oversubscription weight = 1
+
+tc 12 wrr weights = 1 1 1 1
+
+; RED params per traffic class and color (Green / Yellow / Red)
+[red]
+tc 0 wred min = 48 40 32
+tc 0 wred max = 64 64 64
+tc 0 wred inv prob = 10 10 10
+tc 0 wred weight = 9 9 9
+
+tc 1 wred min = 48 40 32
+tc 1 wred max = 64 64 64
+tc 1 wred inv prob = 10 10 10
+tc 1 wred weight = 9 9 9
+
+tc 2 wred min = 48 40 32
+tc 2 wred max = 64 64 64
+tc 2 wred inv prob = 10 10 10
+tc 2 wred weight = 9 9 9
+
+tc 3 wred min = 48 40 32
+tc 3 wred max = 64 64 64
+tc 3 wred inv prob = 10 10 10
+tc 3 wred weight = 9 9 9
+
+tc 4 wred min = 48 40 32
+tc 4 wred max = 64 64 64
+tc 4 wred inv prob = 10 10 10
+tc 4 wred weight = 9 9 9
+
+tc 5 wred min = 48 40 32
+tc 5 wred max = 64 64 64
+tc 5 wred inv prob = 10 10 10
+tc 5 wred weight = 9 9 9
+
+tc 6 wred min = 48 40 32
+tc 6 wred max = 64 64 64
+tc 6 wred inv prob = 10 10 10
+tc 6 wred weight = 9 9 9
+
+tc 7 wred min = 48 40 32
+tc 7 wred max = 64 64 64
+tc 7 wred inv prob = 10 10 10
+tc 7 wred weight = 9 9 9
+
+tc 8 wred min = 48 40 32
+tc 8 wred max = 64 64 64
+tc 8 wred inv prob = 10 10 10
+tc 8 wred weight = 9 9 9
+
+tc 9 wred min = 48 40 32
+tc 9 wred max = 64 64 64
+tc 9 wred inv prob = 10 10 10
+tc 9 wred weight = 9 9 9
+
+tc 10 wred min = 48 40 32
+tc 10 wred max = 64 64 64
+tc 10 wred inv prob = 10 10 10
+tc 10 wred weight = 9 9 9
+
+tc 11 wred min = 48 40 32
+tc 11 wred max = 64 64 64
+tc 11 wred inv prob = 10 10 10
+tc 11 wred weight = 9 9 9
+
+tc 12 wred min = 48 40 32
+tc 12 wred max = 64 64 64
+tc 12 wred inv prob = 10 10 10
+tc 12 wred weight = 9 9 9
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index ec74bee939..84c5e315c3 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -81,13 +81,11 @@ struct rte_sched_queue {
struct rte_sched_queue_extra {
struct rte_sched_queue_stats stats;
-#ifdef RTE_SCHED_CMAN
RTE_STD_C11
union {
struct rte_red red;
struct rte_pie pie;
};
-#endif
};
enum grinder_state {
@@ -179,7 +177,6 @@ struct rte_sched_subport {
/* Pipe queues size */
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-#ifdef RTE_SCHED_CMAN
bool cman_enabled;
enum rte_sched_cman_mode cman;
@@ -188,7 +185,6 @@ struct rte_sched_subport {
struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
struct rte_pie_config pie_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
};
-#endif
/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -1081,7 +1077,6 @@ rte_sched_free_memory(struct rte_sched_port *port, uint32_t n_subports)
rte_free(port);
}
-#ifdef RTE_SCHED_CMAN
static int
rte_sched_red_config(struct rte_sched_port *port,
struct rte_sched_subport *s,
@@ -1163,7 +1158,6 @@ rte_sched_cman_config(struct rte_sched_port *port,
return -EINVAL;
}
-#endif
int
rte_sched_subport_config(struct rte_sched_port *port,
@@ -1254,7 +1248,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
s->n_pipe_profiles = params->n_pipe_profiles;
s->n_max_pipe_profiles = params->n_max_pipe_profiles;
-#ifdef RTE_SCHED_CMAN
if (params->cman_params != NULL) {
s->cman_enabled = true;
status = rte_sched_cman_config(port, s, params, n_subports);
@@ -1266,7 +1259,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
} else {
s->cman_enabled = false;
}
-#endif
/* Scheduling loop detection */
s->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -1792,7 +1784,7 @@ rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
uint32_t tc_index = rte_sched_port_pipe_tc(port, qindex);
uint32_t pkt_len = pkt->pkt_len;
@@ -1818,21 +1810,17 @@ static inline void
rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport *subport,
uint32_t qindex,
struct rte_mbuf *pkt,
- __rte_unused uint32_t n_pkts_cman_dropped)
+ uint32_t n_pkts_cman_dropped)
{
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;
qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
-#ifdef RTE_SCHED_CMAN
if (subport->cman_enabled)
qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
-#endif
}
-#ifdef RTE_SCHED_CMAN
-
static inline int
rte_sched_port_cman_drop(struct rte_sched_port *port,
struct rte_sched_subport *subport,
@@ -1877,13 +1865,11 @@ static inline void
rte_sched_port_red_set_queue_empty_timestamp(struct rte_sched_port *port,
struct rte_sched_subport *subport, uint32_t qindex)
{
- if (subport->cman_enabled) {
+ if (subport->cman_enabled && subport->cman == RTE_SCHED_CMAN_RED) {
struct rte_sched_queue_extra *qe = subport->queue_extra + qindex;
- if (subport->cman == RTE_SCHED_CMAN_RED) {
- struct rte_red *red = &qe->red;
+ struct rte_red *red = &qe->red;
- rte_red_mark_queue_empty(red, port->time);
- }
+ rte_red_mark_queue_empty(red, port->time);
}
}
@@ -1902,29 +1888,6 @@ uint32_t qindex, uint32_t pkt_len, uint64_t time) {
}
}
-#else
-
-static inline int rte_sched_port_cman_drop(struct rte_sched_port *port __rte_unused,
- struct rte_sched_subport *subport __rte_unused,
- struct rte_mbuf *pkt __rte_unused,
- uint32_t qindex __rte_unused,
- uint16_t qlen __rte_unused)
-{
- return 0;
-}
-
-#define rte_sched_port_red_set_queue_empty_timestamp(port, subport, qindex)
-
-static inline void
-rte_sched_port_pie_dequeue(struct rte_sched_subport *subport __rte_unused,
- uint32_t qindex __rte_unused,
- uint32_t pkt_len __rte_unused,
- uint64_t time __rte_unused) {
- /* do-nothing when RTE_SCHED_CMAN not defined */
-}
-
-#endif /* RTE_SCHED_CMAN */
-
#ifdef RTE_SCHED_DEBUG
static inline void
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [PATCH v1] bbdev: add device status info
2022-06-07 16:20 0% ` Maxime Coquelin
@ 2022-06-07 16:42 0% ` Stephen Hemminger
2022-06-08 22:44 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-07 16:42 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Chautru, Nicolas, dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
On Tue, 7 Jun 2022 18:20:38 +0200
Maxime Coquelin <maxime.coquelin@redhat.com> wrote:
> Hi Nicolas,
>
> On 6/7/22 17:44, Chautru, Nicolas wrote:
> > Hi Maxime,
> >
> >> -----Original Message-----
> >> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> >> Sent: Tuesday, June 7, 2022 5:43 AM
> >> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
> >> <nicolas.chautru@intel.com>
> >> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
> >> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> >> Subject: Re: [PATCH v1] bbdev: add device status info
> >>
> >> Hi Stephen,
> >>
> >> On 6/7/22 02:09, Stephen Hemminger wrote:
> >>> On Mon, 6 Jun 2022 15:50:08 -0700
> >>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> >>>
> >>>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> >>>> const struct rte_bbdev_op_cap *capabilities;
> >>>> /** Device cpu_flag requirements */
> >>>> const enum rte_cpu_flag_t *cpu_flag_reqs;
> >>>> + /** Device Status */
> >>>> + enum rte_bbdev_device_status device_status;
> >>>> };
> >>>>
> >>>
> >>> This ends up being an ABI breakage, can't change a struct like that
> >>> until 22.11 release.
> >>>
> >>
> >> Indeed, but Nicolas mentioned in the cover-letter that the patch targets
> >> v22.11; not this release.
> >>
> >> However, a deprecation notice should be sent for v22.07 if it hasn't been
> >> done yet.
> >
> > I have sent this deprecation Maxime:
> > https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
> > Do you believe this needs to be extended to cover more details the change and including this device status info explicitly? I can update the verbiage in more details if required
>
> Thanks for the pointer, I missed it.
> Reading the deprecation notice, it is not clear to me it is about the
> device status info enum.
>
> Maybe rewording it a bit to be more specific would help.
You might want to use one the existing empty padding slots (holes) in
that structure. It appears to have been laid out haphazardly.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v1] bbdev: add device status info
2022-06-07 15:44 0% ` Chautru, Nicolas
@ 2022-06-07 16:20 0% ` Maxime Coquelin
2022-06-07 16:42 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-07 16:20 UTC (permalink / raw)
To: Chautru, Nicolas, Stephen Hemminger
Cc: dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
Hi Nicolas,
On 6/7/22 17:44, Chautru, Nicolas wrote:
> Hi Maxime,
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Tuesday, June 7, 2022 5:43 AM
>> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
>> <nicolas.chautru@intel.com>
>> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
>> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
>> Subject: Re: [PATCH v1] bbdev: add device status info
>>
>> Hi Stephen,
>>
>> On 6/7/22 02:09, Stephen Hemminger wrote:
>>> On Mon, 6 Jun 2022 15:50:08 -0700
>>> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>>>
>>>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
>>>> const struct rte_bbdev_op_cap *capabilities;
>>>> /** Device cpu_flag requirements */
>>>> const enum rte_cpu_flag_t *cpu_flag_reqs;
>>>> + /** Device Status */
>>>> + enum rte_bbdev_device_status device_status;
>>>> };
>>>>
>>>
>>> This ends up being an ABI breakage, can't change a struct like that
>>> until 22.11 release.
>>>
>>
>> Indeed, but Nicolas mentioned in the cover-letter that the patch targets
>> v22.11; not this release.
>>
>> However, a deprecation notice should be sent for v22.07 if it hasn't been
>> done yet.
>
> I have sent this deprecation Maxime:
> https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
> Do you believe this needs to be extended to cover more details the change and including this device status info explicitly? I can update the verbiage in more details if required
Thanks for the pointer, I missed it.
Reading the deprecation notice, it is not clear to me it is about the
device status info enum.
Maybe rewording it a bit to be more specific would help.
Thanks,
Maxime
>
>>
>> Maxime
>
^ permalink raw reply [relevance 0%]
* RE: [PATCH v1] bbdev: add device status info
2022-06-07 12:42 0% ` Maxime Coquelin
@ 2022-06-07 15:44 0% ` Chautru, Nicolas
2022-06-07 16:20 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2022-06-07 15:44 UTC (permalink / raw)
To: Maxime Coquelin, Stephen Hemminger
Cc: dev, gakhil, trix, hemant.agrawal, Vargas, Hernan
Hi Maxime,
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, June 7, 2022 5:43 AM
> To: Stephen Hemminger <stephen@networkplumber.org>; Chautru, Nicolas
> <nicolas.chautru@intel.com>
> Cc: dev@dpdk.org; gakhil@marvell.com; trix@redhat.com;
> hemant.agrawal@nxp.com; Vargas, Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v1] bbdev: add device status info
>
> Hi Stephen,
>
> On 6/7/22 02:09, Stephen Hemminger wrote:
> > On Mon, 6 Jun 2022 15:50:08 -0700
> > Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> >
> >> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> >> const struct rte_bbdev_op_cap *capabilities;
> >> /** Device cpu_flag requirements */
> >> const enum rte_cpu_flag_t *cpu_flag_reqs;
> >> + /** Device Status */
> >> + enum rte_bbdev_device_status device_status;
> >> };
> >>
> >
> > This ends up being an ABI breakage, can't change a struct like that
> > until 22.11 release.
> >
>
> Indeed, but Nicolas mentioned in the cover-letter that the patch targets
> v22.11; not this release.
>
> However, a deprecation notice should be sent for v22.07 if it hasn't been
> done yet.
I have sent this deprecation Maxime:
https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
Do you believe this needs to be extended to cover more details the change and including this device status info explicitly? I can update the verbiage in more details if required
>
> Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH v7] eal: add bus cleanup to eal cleanup
@ 2022-06-07 15:12 3% ` David Marchand
2022-06-13 15:58 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-06-07 15:12 UTC (permalink / raw)
To: Thomas Monjalon, Kevin Laatz
Cc: dev, Morten Brørup, Bruce Richardson, Li Zhang, Matan Azrad,
Stephen Hemminger, lihuisong
On Tue, Jun 7, 2022 at 1:09 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 03/06/2022 16:36, Kevin Laatz:
> > During EAL init, all buses are probed and the devices found are
> > initialized. On eal_cleanup(), the inverse does not happen, meaning any
> > allocated memory and other configuration will not be cleaned up
> > appropriately on exit.
> [...]
> > --- a/devtools/libabigail.abignore
> > +++ b/devtools/libabigail.abignore
> > @@ -56,3 +56,12 @@
> > ; Ignore libabigail false-positive in clang builds, after moving code.
> > [suppress_function]
> > name = rte_eal_remote_launch
> > +
> > +; Ignore field inserted to rte_bus, adding cleanup function
> > +[suppress_type]
> > + name = rte_bus
> > + has_data_member_inserted_at = end
> > +
> > +; Ignore changes to internally used structs containing rte_bus
> > +[suppress_type]
> > + name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus
(This change is strange as there is no rte_vdev_bus type, but I won't
investigate the relevance of this rule for now).
>
> I'm not sure we can safely consider these structs as internal.
> The right process is to send a deprecation notice,
> and then remove them from the public API.
Same for me, I don't think we can safely ignore.
A rte_bus struct is embedded in rte_pci_bus (resp. rte_vmbus_bus).
If we make it grow, any inlined access (like walk in device_list or
driver_list) after the rte_bus object is broken for code accessing it
out of DPDK.
Such code might exist out there, since we expose
FOREACH_DEVICE_ON_PCIBUS, for example.
>
> For info, Li has sent a patch for the bus cleanup
> which is not updating the bus code:
> https://patches.dpdk.org/project/dpdk/patch/20220606114650.209612-3-lizh@nvidia.com/
> It may be a temporary solution before the deprecation.
On the principle, that's probably the best, there is no question about
unclear frontier of the ABI.
(In practice though, the mentionned patch is triggering segfaults in
two CI, for pdump).
Hiding rte_bus object should be straightforward in v22.11, I had some
patches, but never finished the work.
It would be great too, to look into rte_driver and rte_device which
are exposed important types, but that's another story.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Minutes of Technical Board Meeting, 2022-06-01
@ 2022-06-07 13:48 4% Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2022-06-07 13:48 UTC (permalink / raw)
To: dev
Members Attending
=================
9/11
- Aaron
- Bruce
- Hemant
- Jerin
- Kevin
- Maxime
- Olivier (chair)
- Stephen
- Thomas
NOTE: The technical board meetings are on every second Wednesday at
https://meet.jit.si/DPDK at 3 pm UTC. Meetings are public, and DPDK
community members are welcome to attend.
NOTE: Next meeting will be on Wednesday 2021-June-15 @3pm UTC, and will
be chaired by Stephen.
Agenda items
============
1) Update on the tech writer hire
---------------------------------
We are in the process of recruiting a tech writer to enhance DPDK
documentation.
The work group is composed of Nathan, Bruce, Stephen, Thomas.
- 5 reasonnable candidates among 17 applicants
- the list of tasks is defined, it has been estimated to ~250h
- the work should be spread over ~6 months to give enough time
to the community for feedback
- after some time, if the community is satisfied, the writer can
suggest new enhancements, reworks, or estimation updates
- in case the community is not satisfied, the contract could end
before the end of the tasks
2) Discussions about alternatives to bug bounty to find bugs
------------------------------------------------------------
These three ideas were mentionned:
- static analysis tools
- fuzz testing
- adding more tests to CI
Projects from Google Project Zero were also mentionned:
https://github.com/orgs/googleprojectzero/repositories
3) Reminder about API/ABI stability
-----------------------------------
Recently, the vector keyword was removed from rte_altivec.h:
http://git.dpdk.org/dpdk/commit/?id=64fcadeac0f
Since it is a minor (accepted) API breakage, it is the opportunity
to do a reminder about the ABI/API process:
- API breakages are announced and can happen in minor versions
- ABI breakages are announced and can only happen in LTS releases
4) Removal of KNI
-----------------
There is no more maintainer for KNI.
A progressive removal proposal was made:
- add a message at runtime and/or compilation to announce deprecation
- remove KNI example after 22.11
- remove lib + kmod from main repo for 23.11
Bruce recently submitted a doc patchset to explain how to replace
it by virtio-user:
https://patchwork.dpdk.org/project/dpdk/list/?series=23218
The status of pending patches is not obvious. Until now, it was not
announced that new patches won't be integrated. Thomas will open the
discussion.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v1] bbdev: add device status info
2022-06-07 0:09 3% ` Stephen Hemminger
@ 2022-06-07 12:42 0% ` Maxime Coquelin
2022-06-07 15:44 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2022-06-07 12:42 UTC (permalink / raw)
To: Stephen Hemminger, Nicolas Chautru
Cc: dev, gakhil, trix, hemant.agrawal, hernan.vargas
Hi Stephen,
On 6/7/22 02:09, Stephen Hemminger wrote:
> On Mon, 6 Jun 2022 15:50:08 -0700
> Nicolas Chautru <nicolas.chautru@intel.com> wrote:
>
>> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
>> const struct rte_bbdev_op_cap *capabilities;
>> /** Device cpu_flag requirements */
>> const enum rte_cpu_flag_t *cpu_flag_reqs;
>> + /** Device Status */
>> + enum rte_bbdev_device_status device_status;
>> };
>>
>
> This ends up being an ABI breakage, can't change a struct like that
> until 22.11 release.
>
Indeed, but Nicolas mentioned in the cover-letter that the patch targets
v22.11; not this release.
However, a deprecation notice should be sent for v22.07 if it hasn't
been done yet.
Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH v1] bbdev: add new operation for FFT processing
@ 2022-06-07 11:29 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-06-07 11:29 UTC (permalink / raw)
To: Hemant Agrawal, Chautru, Nicolas
Cc: thomas, Zhang, Mingshan, dev, gakhil, Vargas, Hernan,
Maxime Coquelin, trix
Hi guys,
On Thu, May 26, 2022 at 8:05 AM Hemant Agrawal
<hemant.agrawal@oss.nxp.com> wrote:
> On 5/26/2022 3:37 AM, Chautru, Nicolas wrote:
> > Hi Hernant,
> > Gentle reminder in case you can find the time. Could please have a look this patch for bbdev api extension. This is targeting 22.11.
> > New operation type for FFT processing (On top of 4 existing operations types). There is no impact to the la12xx PMD but would be good to get review/feedback.
> > This can be used for vanilla FFT and/or chained FFT/iFFT + point-wise multiplication making it applicable for SRS processing.
> > Thanks,
> > Nic
>
> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>
> HI Nicolas,
>
> Yes, I had a look into it. I see no issue in it. This is fairly
> independent feature addition to BBDEV.
>
Hemant,
For this v22.11 change, we will need some acks on the ABI breakage
announce in v22.07:
https://patchwork.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chautru@intel.com/
Could you review it?
Thanks.
--
David Marchand
^ permalink raw reply [relevance 3%]
* [PATCH RESEND v4 7/8] devtools: add RISC-V to test-meson-builds.sh
@ 2022-06-07 10:46 9% ` Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-06-07 10:46 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
devtools/test-meson-builds.sh | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..f732dccf6c 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configuration
+build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
+ $use_shared
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:35 0% ` Dumitrescu, Cristian
@ 2022-06-07 10:40 0% ` Danilewicz, MarcinX
0 siblings, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-06-07 10:40 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
Hi Cristian,
Please find answers inline.
<snip>
> > Log: v2 change in rte_sched.h to avoid ABI breakage.
<snip>
Lessons learned, so I have fixed also positioning of this above.
<snip>
> > diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c index
> > ec74bee939..db14934832 100644
> > --- a/lib/sched/rte_sched.c
> > +++ b/lib/sched/rte_sched.c
>
<snip>
> Same comment here: yes, remove the #ifdef ... #endif, but no need to
> change this code fragment, as it sets correctly the s->cman_enabled flag,
> which is then the only flag used by the rest of the code. Again, no need to
> have a CMAN_NONE in the enumeration, as the same is achieved by setting
> params->cman_params to NULL.
Yes, with that approach this is better.
<snip>
> > qe->stats.n_pkts_dropped += 1;
> > qe->stats.n_bytes_dropped += pkt_len; -#ifdef RTE_SCHED_CMAN
> > if (subport->cman_enabled)
> > qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
> -#endif }
>
> Please don't forget to remove the __rte_unused attribute for the
> n_pkts_cman_dropped in the function parameters, right?
Nice spot. Looks like this was there for some time.
Regards,
Marcin
^ permalink raw reply [relevance 0%]
* [PATCH v5] pcap: support MTU set for linux interafces
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
@ 2022-06-07 6:27 3% ` Ido Goshen
2022-06-08 16:04 3% ` [PATCH v6] " Ido Goshen
2022-06-19 9:30 3% ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-20 8:39 3% ` [PATCH v8 " Ido Goshen
4 siblings, 1 reply; 200+ results
From: Ido Goshen @ 2022-06-07 6:27 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu for pcap ifaces vdevs by
setting the underlying OS network interface's MTU.
Support is for pcap ifaces only and not for pcap files.
Support is for Linux only.
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v5:
Alternative approach
Instead of checking MTU in the pmd set it on the OS interface and
let it do the enforcment.
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 43 ++++++++++++++++++++++++++
drivers/net/pcap/pcap_osdep.h | 1 +
drivers/net/pcap/pcap_osdep_freebsd.c | 7 +++++
drivers/net/pcap/pcap_osdep_linux.c | 21 +++++++++++++
drivers/net/pcap/pcap_osdep_windows.c | 7 +++++
6 files changed, 82 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 0ed4f92820..b90cfefc55 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -95,6 +95,9 @@ New Features
* Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
* Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
+* **Updated pcap driver.**
+
+ * Added support for MTU on Linux network interfaces
Removed Items
-------------
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..3d76d50ef1 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -807,6 +807,48 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ unsigned int i;
+ struct pmd_internals *internals = dev->data->dev_private;
+ int is_supported = 0;
+ int is_err = 0;
+
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ struct pcap_rx_queue* queue = &internals->rx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_RX_IFACE_IN_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ struct pcap_tx_queue* queue = &internals->tx_queue[i];
+
+ if ((strcmp(queue->type, ETH_PCAP_IFACE_ARG) == 0) ||
+ (strcmp(queue->type, ETH_PCAP_TX_IFACE_ARG) == 0)) {
+ is_supported = 1;
+ if (osdep_iface_mtu_set(queue->name, mtu) < 0)
+ is_err = 1;
+ }
+ }
+
+ if (!is_supported)
+ return -ENOTSUP;
+
+ if (is_err)
+ return -1;
+
+ PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1046,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
diff --git a/drivers/net/pcap/pcap_osdep.h b/drivers/net/pcap/pcap_osdep.h
index bf41cba982..ef8be7543c 100644
--- a/drivers/net/pcap/pcap_osdep.h
+++ b/drivers/net/pcap/pcap_osdep.h
@@ -14,5 +14,6 @@ extern int eth_pcap_logtype;
int osdep_iface_index_get(const char *name);
int osdep_iface_mac_get(const char *name, struct rte_ether_addr *mac);
+int osdep_iface_mtu_set(const char *if_name, uint16_t mtu);
#endif
diff --git a/drivers/net/pcap/pcap_osdep_freebsd.c b/drivers/net/pcap/pcap_osdep_freebsd.c
index 20556b3e92..52d4a0e6db 100644
--- a/drivers/net/pcap/pcap_osdep_freebsd.c
+++ b/drivers/net/pcap/pcap_osdep_freebsd.c
@@ -57,3 +57,10 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
rte_free(buf);
return 0;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ PMD_LOG(WARN, "mtu set not supported on freebsd\n");
+ return -ENOTSUP;
+}
diff --git a/drivers/net/pcap/pcap_osdep_linux.c b/drivers/net/pcap/pcap_osdep_linux.c
index 97033f57c5..b0b4a716fe 100644
--- a/drivers/net/pcap/pcap_osdep_linux.c
+++ b/drivers/net/pcap/pcap_osdep_linux.c
@@ -40,3 +40,24 @@ osdep_iface_mac_get(const char *if_name, struct rte_ether_addr *mac)
close(if_fd);
return 0;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ struct ifreq ifr;
+ int if_fd = socket(AF_INET, SOCK_DGRAM, 0);
+
+ if (if_fd == -1)
+ return -1;
+
+ rte_strscpy(ifr.ifr_name, if_name, sizeof(ifr.ifr_name));
+ ifr.ifr_mtu = mtu;
+ if (ioctl(if_fd, SIOCSIFMTU, &ifr)) {
+ PMD_LOG(ERR, "%s mtu set to %d failed\n", if_name, mtu);
+ close(if_fd);
+ return -1;
+ }
+
+ close(if_fd);
+ return 0;
+}
diff --git a/drivers/net/pcap/pcap_osdep_windows.c b/drivers/net/pcap/pcap_osdep_windows.c
index 1d398dc7ed..15205a521e 100644
--- a/drivers/net/pcap/pcap_osdep_windows.c
+++ b/drivers/net/pcap/pcap_osdep_windows.c
@@ -116,3 +116,10 @@ osdep_iface_mac_get(const char *device_name, struct rte_ether_addr *mac)
free(info);
return ret;
}
+
+int
+osdep_iface_mtu_set(const char *if_name, uint16_t mtu)
+{
+ PMD_LOG(WARN, "mtu set not supported on Windows\n", sys_ret);
+ return -ENOTSUP;
+}
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH v1] bbdev: add device status info
@ 2022-06-07 0:09 3% ` Stephen Hemminger
2022-06-07 12:42 0% ` Maxime Coquelin
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-07 0:09 UTC (permalink / raw)
To: Nicolas Chautru
Cc: dev, gakhil, trix, maxime.coquelin, hemant.agrawal, hernan.vargas
On Mon, 6 Jun 2022 15:50:08 -0700
Nicolas Chautru <nicolas.chautru@intel.com> wrote:
> @@ -298,6 +313,8 @@ struct rte_bbdev_driver_info {
> const struct rte_bbdev_op_cap *capabilities;
> /** Device cpu_flag requirements */
> const enum rte_cpu_flag_t *cpu_flag_reqs;
> + /** Device Status */
> + enum rte_bbdev_device_status device_status;
> };
>
This ends up being an ABI breakage, can't change a struct like that
until 22.11 release.
^ permalink raw reply [relevance 3%]
* RE: [PATCH v4] pcap: support MTU set
2022-06-06 17:10 0% ` Stephen Hemminger
@ 2022-06-06 19:07 3% ` Ido Goshen
0 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-06-06 19:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: ferruh.yigit, dev
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Monday, 6 June 2022 20:10
> To: Ido Goshen <Ido@cgstowernetworks.com>
> Cc: ferruh.yigit@xilinx.com; dev@dpdk.org
> Subject: Re: [PATCH v4] pcap: support MTU set
>
> On Mon, 6 Jun 2022 19:21:47 +0300
> Ido Goshen <ido@cgstowernetworks.com> wrote:
>
> > Support rte_eth_dev_set_mtu by pcap vdevs Enforce mtu on rx/tx
> >
> > Bugzilla ID: 961
>
> This is not really a bug, it is an enhancement specific to your test setup. It should
> not be backported to stable.
>
> Since it is change in behavior it might be better to add a vdev argument for this
> rather than overloading meaning of MTU.
[idog] The default behavior stays the same and long packets will continue to pass as used to,
Only if 'rte_eth_dev_set_mtu' is explicitly used it will take effect.
I doubt it'll break anything cause no one could use it so far as it returns -ENOTSUP,
and I assume that would be the expected behavior for anyone who will set it.
Adding it as an argument to vdev (e.g. vdev='net_pcap0,iface=eth0,mtu=9400') seems to me
like a duplication to an existing API.
> Also, this does not behave the same[idog] as virtio or hardware drivers.
[idog] The idea of this patch is to make pcap behave more like HW NICs.
Couple of HW NICs (ixgbe, i40e) I've checked do respect MTU
Please see test outputs in https://bugs.dpdk.org/show_bug.cgi?id=961
Though probably it's done by the HW and not by the driver
Alternative might be to set the network interfaces MTU and not do it in pmd, so
It'll be like the "HW" is doing it, but this will work only for ifaces and not for pcap files.
>
> The mtu is already in dev->data->mtu, why copy it?
>
[idog] That's what I was using so far, but I got a request from ferruh.yigit@xilinx.com
not to use 'dev' but access 'internals' via the 'pcap_rx/tx_queue' struct.
> > + if (unlikely(header.caplen > internals->mtu)) {
> > + pcap_q->rx_stat.err_pkts++;
> > + rte_pktmbuf_free(mbuf);
> > + break;
> > + }
>
> This doesn't account for VLAN header.
[idog] Good point, I'm never sure what overhead should be considered?
Please advice what should I add
e.g. '(RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN + RTE_VLAN_HLEN * 2)'
however caller can always set it a bit higher if needed
> > +
> > + if (unlikely(len > internals->mtu)) {
> > + rte_pktmbuf_free(mbuf);
> > + continue;
> > + }
>
> There needs to be a per queue counter any and all drops.
[idog] It will be counted few lines below by
'dumper_q->tx_stat.err_pkts += nb_pkts - num_tx;'
as this case doesn't increment the 'num_tx'
> >
> > +static int
> > +eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> > + struct pmd_internals *internals = dev->data->dev_private;
> > +
> > + PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
> > + internals->mtu = mtu;
> > + return 0;
> > +}
>
> If you drop internals->mtu (redundant) then this just becomes stub (ie return 0)
>
[idog] Again I'm not sure if it's right to use 'dev->data->mtu' directly where later needed.
ferruh.yigit@xilinx.com ?
Anyway this function is needed even if it does nothing (or just logs) in order for the
eth_dev_ops.mtu_set to be supported
> >
> > static int
> > @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> > .addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
> > };
> > (*internals)->phy_mac = 0;
> > + (*internals)->mtu = RTE_ETH_PCAP_SNAPLEN;
>
>
> Use dev->data->mtu not internal value.
>
[idog] This runs early when the probe creates the device
Later 'dev->data->mtu' will be overwritten later in 'rte_eth_dev_configure'
To hard-coded 1500
if (dev_conf->rxmode.mtu == 0)
dev->data->dev_conf.rxmode.mtu = RTE_ETHER_MTU;
ret = eth_dev_validate_mtu(port_id, &dev_info,
dev->data->dev_conf.rxmode.mtu);
if (ret != 0)
goto rollback;
dev->data->mtu = dev->data->dev_conf.rxmode.mtu;
I tried to overcome it by [PATCH v2] http://mails.dpdk.org/archives/dev/2022-May/241974.html
But this code change spills out of the pcap pmd and changes rte_ethdev abi which I rather avoid
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4] pcap: support MTU set
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
@ 2022-06-06 17:10 0% ` Stephen Hemminger
2022-06-06 19:07 3% ` Ido Goshen
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-06-06 17:10 UTC (permalink / raw)
To: Ido Goshen; +Cc: ferruh.yigit, dev
On Mon, 6 Jun 2022 19:21:47 +0300
Ido Goshen <ido@cgstowernetworks.com> wrote:
> Support rte_eth_dev_set_mtu by pcap vdevs
> Enforce mtu on rx/tx
>
> Bugzilla ID: 961
This is not really a bug, it is an enhancement specific to your
test setup. It should not be backported to stable.
Since it is change in behavior it might be better to add a vdev argument
for this rather than overloading meaning of MTU. Also, this does not behave
the same as virtio or hardware drivers.
> Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
>
> ---
> v4:
> 1. Add release notes comment
> 2. Access pmd internals via queue struct
> 3. eth_mtu_set code convention fixes
>
> v3:
> Preserve pcap behavior to support max size packets by default
> alternative to v2 in order to limit the code change to pcap only and
> avoid abi change.
> Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
>
> v2:
> Preserve pcap behavior to support max size packets by default.
> ---
> doc/guides/rel_notes/release_22_07.rst | 3 ++
> drivers/net/pcap/pcap_ethdev.c | 38 ++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
> index 0ed4f92820..717191d498 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -95,6 +95,9 @@ New Features
> * Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
> * Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
>
> +* **Updated pcap driver.**
> +
> + * Added support for MTU via ``rte_eth_dev_set_mtu``
>
> Removed Items
> -------------
> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index ec29fd6bc5..db1958f20f 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -74,6 +74,7 @@ struct pcap_rx_queue {
>
> /* Contains pre-generated packets to be looped through */
> struct rte_ring *pkts;
> + struct pmd_internals *internals;
> };
>
> struct pcap_tx_queue {
> @@ -82,6 +83,7 @@ struct pcap_tx_queue {
> struct queue_stat tx_stat;
> char name[PATH_MAX];
> char type[ETH_PCAP_ARG_MAXLEN];
> + struct pmd_internals *internals;
> };
>
> struct pmd_internals {
> @@ -93,6 +95,7 @@ struct pmd_internals {
> int single_iface;
> int phy_mac;
> unsigned int infinite_rx;
> + uint16_t mtu;
> };
The mtu is already in dev->data->mtu, why copy it?
> struct pmd_process_private {
> @@ -278,6 +281,7 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> const u_char *packet;
> struct rte_mbuf *mbuf;
> struct pcap_rx_queue *pcap_q = queue;
> + struct pmd_internals *internals = pcap_q->internals;
> uint16_t num_rx = 0;
> uint32_t rx_bytes = 0;
> pcap_t *pcap;
> @@ -303,6 +307,12 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> break;
> }
>
> + if (unlikely(header.caplen > internals->mtu)) {
> + pcap_q->rx_stat.err_pkts++;
> + rte_pktmbuf_free(mbuf);
> + break;
> + }
This doesn't account for VLAN header.
> if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
> /* pcap packet will fit in the mbuf, can copy it */
> rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> @@ -378,6 +388,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *dumper_q = queue;
> + struct pmd_internals *internals = dumper_q->internals;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> struct pcap_pkthdr header;
> @@ -396,6 +407,12 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = caplen = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > internals->mtu)) {
> + rte_pktmbuf_free(mbuf);
> + continue;
> + }
There needs to be a per queue counter any and all drops.
<
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> caplen = sizeof(temp_data);
> @@ -464,6 +481,7 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *tx_queue = queue;
> + struct pmd_internals *internals = tx_queue->internals;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> pcap_t *pcap;
> @@ -479,6 +497,12 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > internals->mtu)) {
> + rte_pktmbuf_free(mbuf);
> + continue;
> + }
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> PMD_LOG(ERR,
> @@ -807,6 +831,16 @@ eth_stats_reset(struct rte_eth_dev *dev)
> return 0;
> }
>
> +static int
> +eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> +
> + PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
> + internals->mtu = mtu;
> + return 0;
> +}
If you drop internals->mtu (redundant) then this just becomes stub (ie return 0)
> +
> static inline void
> infinite_rx_ring_free(struct rte_ring *pkts)
> {
> @@ -878,6 +912,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
> pcap_q->mb_pool = mb_pool;
> pcap_q->port_id = dev->data->port_id;
> pcap_q->queue_id = rx_queue_id;
> + pcap_q->internals = internals;
> dev->data->rx_queues[rx_queue_id] = pcap_q;
>
> if (internals->infinite_rx) {
> @@ -952,6 +987,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev,
>
> pcap_q->port_id = dev->data->port_id;
> pcap_q->queue_id = tx_queue_id;
> + pcap_q->internals = internals;
> dev->data->tx_queues[tx_queue_id] = pcap_q;
>
> return 0;
> @@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
> .link_update = eth_link_update,
> .stats_get = eth_stats_get,
> .stats_reset = eth_stats_reset,
> + .mtu_set = eth_mtu_set,
> };
>
> static int
> @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> .addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
> };
> (*internals)->phy_mac = 0;
> + (*internals)->mtu = RTE_ETH_PCAP_SNAPLEN;
Use dev->data->mtu not internal value.
> data = (*eth_dev)->data;
> data->nb_rx_queues = (uint16_t)nb_rx_queues;
> data->nb_tx_queues = (uint16_t)nb_tx_queues;
^ permalink raw reply [relevance 0%]
* [PATCH v4] pcap: support MTU set
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
@ 2022-06-06 16:21 3% ` Ido Goshen
2022-06-06 17:10 0% ` Stephen Hemminger
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Ido Goshen @ 2022-06-06 16:21 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v4:
1. Add release notes comment
2. Access pmd internals via queue struct
3. eth_mtu_set code convention fixes
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
doc/guides/rel_notes/release_22_07.rst | 3 ++
drivers/net/pcap/pcap_ethdev.c | 38 ++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 0ed4f92820..717191d498 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -95,6 +95,9 @@ New Features
* Added AH mode support in lookaside protocol (IPsec) for CN9K & CN10K.
* Added AES-GMAC support in lookaside protocol (IPsec) for CN9K & CN10K.
+* **Updated pcap driver.**
+
+ * Added support for MTU via ``rte_eth_dev_set_mtu``
Removed Items
-------------
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..db1958f20f 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -74,6 +74,7 @@ struct pcap_rx_queue {
/* Contains pre-generated packets to be looped through */
struct rte_ring *pkts;
+ struct pmd_internals *internals;
};
struct pcap_tx_queue {
@@ -82,6 +83,7 @@ struct pcap_tx_queue {
struct queue_stat tx_stat;
char name[PATH_MAX];
char type[ETH_PCAP_ARG_MAXLEN];
+ struct pmd_internals *internals;
};
struct pmd_internals {
@@ -93,6 +95,7 @@ struct pmd_internals {
int single_iface;
int phy_mac;
unsigned int infinite_rx;
+ uint16_t mtu;
};
struct pmd_process_private {
@@ -278,6 +281,7 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
const u_char *packet;
struct rte_mbuf *mbuf;
struct pcap_rx_queue *pcap_q = queue;
+ struct pmd_internals *internals = pcap_q->internals;
uint16_t num_rx = 0;
uint32_t rx_bytes = 0;
pcap_t *pcap;
@@ -303,6 +307,12 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
break;
}
+ if (unlikely(header.caplen > internals->mtu)) {
+ pcap_q->rx_stat.err_pkts++;
+ rte_pktmbuf_free(mbuf);
+ break;
+ }
+
if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
/* pcap packet will fit in the mbuf, can copy it */
rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
@@ -378,6 +388,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *dumper_q = queue;
+ struct pmd_internals *internals = dumper_q->internals;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
struct pcap_pkthdr header;
@@ -396,6 +407,12 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = caplen = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > internals->mtu)) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
caplen = sizeof(temp_data);
@@ -464,6 +481,7 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *tx_queue = queue;
+ struct pmd_internals *internals = tx_queue->internals;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
pcap_t *pcap;
@@ -479,6 +497,12 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > internals->mtu)) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
PMD_LOG(ERR,
@@ -807,6 +831,16 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+
+ PMD_LOG(INFO, "MTU set %s %u\n", dev->device->name, mtu);
+ internals->mtu = mtu;
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -878,6 +912,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
pcap_q->mb_pool = mb_pool;
pcap_q->port_id = dev->data->port_id;
pcap_q->queue_id = rx_queue_id;
+ pcap_q->internals = internals;
dev->data->rx_queues[rx_queue_id] = pcap_q;
if (internals->infinite_rx) {
@@ -952,6 +987,7 @@ eth_tx_queue_setup(struct rte_eth_dev *dev,
pcap_q->port_id = dev->data->port_id;
pcap_q->queue_id = tx_queue_id;
+ pcap_q->internals = internals;
dev->data->tx_queues[tx_queue_id] = pcap_q;
return 0;
@@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
@@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
.addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
};
(*internals)->phy_mac = 0;
+ (*internals)->mtu = RTE_ETH_PCAP_SNAPLEN;
data = (*eth_dev)->data;
data->nb_rx_queues = (uint16_t)nb_rx_queues;
data->nb_tx_queues = (uint16_t)nb_tx_queues;
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: Optimizations are not features
2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
2022-06-05 16:05 0% ` Stephen Hemminger
@ 2022-06-06 9:35 0% ` Konstantin Ananyev
2022-06-29 20:44 0% ` Honnappa Nagarahalli
2 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-06-06 9:35 UTC (permalink / raw)
To: Andrew Rybchenko, Morten Brørup, Jerin Jacob; +Cc: dpdk-dev, techboard
04/06/2022 13:51, Andrew Rybchenko пишет:
> On 6/4/22 15:19, Morten Brørup wrote:
>>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
>>> Sent: Saturday, 4 June 2022 13.10
>>>
>>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
>>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>>
>>>> On 6/4/22 12:33, Jerin Jacob wrote:
>>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
>>> <mb@smartsharesystems.com> wrote:
>>>>>>
>>>>>> I would like the DPDK community to change its view on compile time
>>> options. Here is why:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Application specific performance micro-optimizations like “fast
>>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
>>> presented as features.
>>>>>>
>>>>>>
>>>>>>
>>>>>> They are not features, but optimizations, and I don’t understand
>>> the need for them to be available at run-time!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Instead of adding a bunch of exotic exceptions to the fast path of
>>> the PMDs, they should be compile time options. This will improve
>>> performance by avoiding branches in the fast path, both for the
>>> applications using them, and for generic applications (where the exotic
>>> code is omitted).
>>>>>
>>>>> Agree. I think, keeping the best of both worlds would be
>>>>>
>>>>> -Enable the feature/optimization as runtime
>>>>> -Have a compile-time option to disable the feature/optimization as
>>> an override.
>>>>
>>>> It is hard to find the right balance, but in general compile
>>>> time options are a nightmare for maintenance. Number of
>>>> required builds will grow as an exponent.
>>
>> Test combinations are exponential for N features, regardless if N are
>> runtime or compile time options.
>
> But since I'm talking about build checks I don't care about exponential
> grows in run time. Yes, testing should care, but it is a separate story.
>
>>
>>>> Of course, we can
>>>> limit number of checked combinations, but it will result in
>>>> flow of patches to fix build in other cases.
>>>
>>> The build breakage can be fixed if we use (2) vs (1)
>>>
>>> 1)
>>> #ifdef ...
>>> My feature
>>> #endif
>>>
>>> 2)
>>> static __rte_always_inline int
>>> rte_has_xyz_feature(void)
>>> {
>>> #ifdef RTE_LIBRTE_XYZ_FEATURE
>>> return RTE_LIBRTE_XYZ_FEATURE;
>>> #else
>>> return 0;
>>> #endif
>>> }
>>>
>>> if(rte_has_xyz_feature())) {
>>> My feature code
>>>
>>> }
>>>
>
> Jerin, thanks, very good example.
>
>> I'm not sure all the features can be covered by that, e.g. added
>> fields in structures.
>
> +1
>
>>
>> Also, I would consider such features "opt in" at compile time only. As
>> such, they could be allowed to break the ABI/API.
>>
>>>
>>>
>>>> Also compile time options tend to make code less readable
>>>> which makes all aspects of the development harder.
>>>>
>>>> Yes, compile time is nice for micro optimizations, but
>>>> I have great concerns that it is a right way to go.
>>>>
>>>>>> Please note that I am only talking about the performance
>>> optimizations that are limited to application specific use cases. I
>>> think it makes sense to require that performance optimizing an
>>> application also requires recompiling the performance critical
>>> libraries used by it.
>>>>>>abandon some of existing functionality to create a 'short-cut'
>>>>>>
>>>>>>
>>>>>> Allowing compile time options for application specific performance
>>> optimizations in DPDK would also open a path for other optimizations,
>>> which can only be achieved at compile time, such as “no fragmented
>>> packets”, “no attached mbufs” and “single mbuf pool”. And even more
>>> exotic optimizations, such as the “indexed mempool cache”, which was
>>> rejected due to ABI violations – they could be marked as “risky and
>>> untested” or similar, but still be part of the DPDK main repository.
>>>>>>
Thanks Morten for bringing it up, it is an interesting topic.
Though I look at it from different angle.
All optimizations you mentioned above introduce new limitations:
MBUF_FAST_FREE - no indirect mbufs and multiple mempools,
mempool object indexes - mempool size is limited to 4GB,
direct rearm - drop ability to stop/reconfigure TX queue,
while RX queue is still running,
etc.
Note that all these limitations are not forced by HW.
All of them are pure SW limitations that developers forced in
(or tried to) to get few extra performance.
That's concerning tendency.
As more and more such 'optimization via limitation' will come in:
- DPDK feature list will become more and more fragmented.
- Would cause more and more confusion for the users.
- Unmet expectations - difference in performance between 'default'
and 'optimized' version of DPDK will become bigger and bigger.
- As Andrew already mentioned, maintaining all these 'sub-flavours'
of DPDK will become more and more difficult.
So, probably instead of making such changes easier,
we need somehow to persuade developers to think more about
optimizations that would be generic and transparent to the user.
I do realize that it is not always possible due to various reasons
(HW limitations, external dependencies, etc.)
but that's another story.
Let's take for example MBUF_FAST_FREE.
In fact, I am not sure that we need it as tx offload flag at all.
PMD TX-path has all necessary information to decide at run-time
can it do fast_free() for not:
At tx_burst() PMD can check are all mbufs satisfy these conditions
(same mempool, refcnt==1) and update some fields and/or counters
inside TXQ to reflect it.
Then, at tx_free() we can use this info to decide
between fast_free() and normal_free().
As at tx_burst() we read mbuf fields anyway, impact for this
extra step I guess would be minimal.
Yes, most likely, it wouldn't be as fast as with current
TX offload flag, or conditional compilation approach.
But it might be still significantly faster then normal_free(),
plus such approach will be generic and transparent to the user.
Konstantin
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
@ 2022-06-05 16:05 0% ` Stephen Hemminger
2022-06-06 9:35 0% ` Konstantin Ananyev
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-06-05 16:05 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: Morten Brørup, Jerin Jacob, dpdk-dev, techboard
On Sat, 4 Jun 2022 15:51:58 +0300
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> wrote:
> On 6/4/22 15:19, Morten Brørup wrote:
> >> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> >> Sent: Saturday, 4 June 2022 13.10
> >>
> >> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> >> <andrew.rybchenko@oktetlabs.ru> wrote:
> >>>
> >>> On 6/4/22 12:33, Jerin Jacob wrote:
> >>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> >> <mb@smartsharesystems.com> wrote:
> >>>>>
> >>>>> I would like the DPDK community to change its view on compile time
> >> options. Here is why:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Application specific performance micro-optimizations like “fast
> >> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> >> presented as features.
> >>>>>
> >>>>>
> >>>>>
> >>>>> They are not features, but optimizations, and I don’t understand
> >> the need for them to be available at run-time!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Instead of adding a bunch of exotic exceptions to the fast path of
> >> the PMDs, they should be compile time options. This will improve
> >> performance by avoiding branches in the fast path, both for the
> >> applications using them, and for generic applications (where the exotic
> >> code is omitted).
> >>>>
> >>>> Agree. I think, keeping the best of both worlds would be
> >>>>
> >>>> -Enable the feature/optimization as runtime
> >>>> -Have a compile-time option to disable the feature/optimization as
> >> an override.
> >>>
> >>> It is hard to find the right balance, but in general compile
> >>> time options are a nightmare for maintenance. Number of
> >>> required builds will grow as an exponent.
> >
> > Test combinations are exponential for N features, regardless if N are runtime or compile time options.
>
> But since I'm talking about build checks I don't care about exponential
> grows in run time. Yes, testing should care, but it is a separate story.
>
> >
> >>> Of course, we can
> >>> limit number of checked combinations, but it will result in
> >>> flow of patches to fix build in other cases.
> >>
> >> The build breakage can be fixed if we use (2) vs (1)
> >>
> >> 1)
> >> #ifdef ...
> >> My feature
> >> #endif
> >>
> >> 2)
> >> static __rte_always_inline int
> >> rte_has_xyz_feature(void)
> >> {
> >> #ifdef RTE_LIBRTE_XYZ_FEATURE
> >> return RTE_LIBRTE_XYZ_FEATURE;
> >> #else
> >> return 0;
> >> #endif
> >> }
> >>
> >> if(rte_has_xyz_feature())) {
> >> My feature code
> >>
> >> }
> >>
>
> Jerin, thanks, very good example.
>
> > I'm not sure all the features can be covered by that, e.g. added fields in structures.
>
> +1
>
> >
> > Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API.
> >
> >>
> >>
> >>> Also compile time options tend to make code less readable
> >>> which makes all aspects of the development harder.
> >>>
> >>> Yes, compile time is nice for micro optimizations, but
> >>> I have great concerns that it is a right way to go.
> >>>
> >>>>> Please note that I am only talking about the performance
> >> optimizations that are limited to application specific use cases. I
> >> think it makes sense to require that performance optimizing an
> >> application also requires recompiling the performance critical
> >> libraries used by it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Allowing compile time options for application specific performance
> >> optimizations in DPDK would also open a path for other optimizations,
> >> which can only be achieved at compile time, such as “no fragmented
> >> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> >> exotic optimizations, such as the “indexed mempool cache”, which was
> >> rejected due to ABI violations – they could be marked as “risky and
> >> untested” or similar, but still be part of the DPDK main repository.
There is a tradeoff that DPDK has had for several years.
1. For ease of use the DPDK should be available in Linux distributions in
pre-built binary format. In that case any changes in behavior need to be
done at runtime.
2. For performance and size, the DPDK should limit conditional branches
and not include dead code. This is what embedded appliance developers want.
3. For flexibilty, the DPDK should allow every option at the smallest granularity
(often per-packet or per-queue). This allows application to use feature if
available but not be limited to only hardware that supports it.
All of these do conflict. The big problem that I see is that when a feature
that changes the semantic of mbuf is used (no-attach, single pool etc).
It is opening other code to bugs. Therefore I am reluctant to use them;
in real life production 1% performance gain is totally offset by the cost
of .1% more bugs in code run by customers.
It would make my life easier if DPDK supported one set of semantics and
they worked everywhere. This is what every OS does (Linux, FreeBSD, Windows).
That would mean either all drivers support the feature in all cases or
the feature is never introduced. What would help this would be a set
of functions that help code do the right thing. Examples in Linux
are skb_linearize(), skb_maypull(), etc.
^ permalink raw reply [relevance 0%]
* RE: Optimizations are not features
2022-06-04 12:51 0% ` Andrew Rybchenko
@ 2022-06-05 8:15 0% ` Morten Brørup
2022-06-05 16:05 0% ` Stephen Hemminger
2022-06-06 9:35 0% ` Konstantin Ananyev
2 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-06-05 8:15 UTC (permalink / raw)
To: Andrew Rybchenko, Jerin Jacob; +Cc: dpdk-dev, techboard
> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Saturday, 4 June 2022 14.52
>
> On 6/4/22 15:19, Morten Brørup wrote:
> >> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> >> Sent: Saturday, 4 June 2022 13.10
> >>
> >> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> >> <andrew.rybchenko@oktetlabs.ru> wrote:
> >>>
> >>> On 6/4/22 12:33, Jerin Jacob wrote:
> >>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> >> <mb@smartsharesystems.com> wrote:
> >>>>>
> >>>>> I would like the DPDK community to change its view on compile
> time
> >> options. Here is why:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Application specific performance micro-optimizations like “fast
> >> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> >> presented as features.
> >>>>>
> >>>>>
> >>>>>
> >>>>> They are not features, but optimizations, and I don’t understand
> >> the need for them to be available at run-time!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Instead of adding a bunch of exotic exceptions to the fast path
> of
> >> the PMDs, they should be compile time options. This will improve
> >> performance by avoiding branches in the fast path, both for the
> >> applications using them, and for generic applications (where the
> exotic
> >> code is omitted).
> >>>>
> >>>> Agree. I think, keeping the best of both worlds would be
> >>>>
> >>>> -Enable the feature/optimization as runtime
> >>>> -Have a compile-time option to disable the feature/optimization as
> >> an override.
> >>>
> >>> It is hard to find the right balance, but in general compile
> >>> time options are a nightmare for maintenance. Number of
> >>> required builds will grow as an exponent.
> >
> > Test combinations are exponential for N features, regardless if N are
> runtime or compile time options.
>
> But since I'm talking about build checks I don't care about exponential
> grows in run time. Yes, testing should care, but it is a separate
> story.
Build checks is just one of many test methods. A very low cost and efficient test method, though.
I acknowledge that build checks will be more complicated with additional compile time options. And build checks are important for code quality, so we should find a solution for that challenge.
The primary scope of my suggestion is application specific performance optimization features only, so let's call them "exotic features". Also, they should be "opt in". Keep in mind: They are not really features, since they don't add anything new, they are only performance optimizations beneficial for specific application use cases.
With this in mind, we could continue ordinary testing with these options disabled. I.e. no additional testing.
Regardless how exotic the features may be, we certainly want some testing of them, so we could do some things to avoid exponential testing:
1. With each ordinary build check (with all options disabled), another build check could be run with a random set of options enabled. Or additional tests could be run on a weekly basis with random combinations of options.
2. Any patch related to one or more of these exotic features could include some magic keywords to indicate which combinations of options must be enabled during build checking and testing.
>
> >
> >>> Of course, we can
> >>> limit number of checked combinations, but it will result in
> >>> flow of patches to fix build in other cases.
> >>
> >> The build breakage can be fixed if we use (2) vs (1)
> >>
> >> 1)
> >> #ifdef ...
> >> My feature
> >> #endif
> >>
> >> 2)
> >> static __rte_always_inline int
> >> rte_has_xyz_feature(void)
> >> {
> >> #ifdef RTE_LIBRTE_XYZ_FEATURE
> >> return RTE_LIBRTE_XYZ_FEATURE;
> >> #else
> >> return 0;
> >> #endif
> >> }
> >>
> >> if(rte_has_xyz_feature())) {
> >> My feature code
> >>
> >> }
> >>
>
> Jerin, thanks, very good example.
>
> > I'm not sure all the features can be covered by that, e.g. added
> fields in structures.
>
> +1
>
> >
> > Also, I would consider such features "opt in" at compile time only.
> As such, they could be allowed to break the ABI/API.
> >
> >>
> >>
> >>> Also compile time options tend to make code less readable
> >>> which makes all aspects of the development harder.
> >>>
> >>> Yes, compile time is nice for micro optimizations, but
> >>> I have great concerns that it is a right way to go.
> >>>
> >>>>> Please note that I am only talking about the performance
> >> optimizations that are limited to application specific use cases. I
> >> think it makes sense to require that performance optimizing an
> >> application also requires recompiling the performance critical
> >> libraries used by it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Allowing compile time options for application specific
> performance
> >> optimizations in DPDK would also open a path for other
> optimizations,
> >> which can only be achieved at compile time, such as “no fragmented
> >> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> >> exotic optimizations, such as the “indexed mempool cache”, which was
> >> rejected due to ABI violations – they could be marked as “risky and
> >> untested” or similar, but still be part of the DPDK main repository.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Med venlig hilsen / Kind regards,
> >>>>>
> >>>>> -Morten Brørup
> >>>>>
> >>>>>
> >>>
> >
>
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 12:19 3% ` Morten Brørup
@ 2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Andrew Rybchenko @ 2022-06-04 12:51 UTC (permalink / raw)
To: Morten Brørup, Jerin Jacob; +Cc: dpdk-dev, techboard
On 6/4/22 15:19, Morten Brørup wrote:
>> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
>> Sent: Saturday, 4 June 2022 13.10
>>
>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>
>>> On 6/4/22 12:33, Jerin Jacob wrote:
>>>> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
>> <mb@smartsharesystems.com> wrote:
>>>>>
>>>>> I would like the DPDK community to change its view on compile time
>> options. Here is why:
>>>>>
>>>>>
>>>>>
>>>>> Application specific performance micro-optimizations like “fast
>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
>> presented as features.
>>>>>
>>>>>
>>>>>
>>>>> They are not features, but optimizations, and I don’t understand
>> the need for them to be available at run-time!
>>>>>
>>>>>
>>>>>
>>>>> Instead of adding a bunch of exotic exceptions to the fast path of
>> the PMDs, they should be compile time options. This will improve
>> performance by avoiding branches in the fast path, both for the
>> applications using them, and for generic applications (where the exotic
>> code is omitted).
>>>>
>>>> Agree. I think, keeping the best of both worlds would be
>>>>
>>>> -Enable the feature/optimization as runtime
>>>> -Have a compile-time option to disable the feature/optimization as
>> an override.
>>>
>>> It is hard to find the right balance, but in general compile
>>> time options are a nightmare for maintenance. Number of
>>> required builds will grow as an exponent.
>
> Test combinations are exponential for N features, regardless if N are runtime or compile time options.
But since I'm talking about build checks I don't care about exponential
grows in run time. Yes, testing should care, but it is a separate story.
>
>>> Of course, we can
>>> limit number of checked combinations, but it will result in
>>> flow of patches to fix build in other cases.
>>
>> The build breakage can be fixed if we use (2) vs (1)
>>
>> 1)
>> #ifdef ...
>> My feature
>> #endif
>>
>> 2)
>> static __rte_always_inline int
>> rte_has_xyz_feature(void)
>> {
>> #ifdef RTE_LIBRTE_XYZ_FEATURE
>> return RTE_LIBRTE_XYZ_FEATURE;
>> #else
>> return 0;
>> #endif
>> }
>>
>> if(rte_has_xyz_feature())) {
>> My feature code
>>
>> }
>>
Jerin, thanks, very good example.
> I'm not sure all the features can be covered by that, e.g. added fields in structures.
+1
>
> Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API.
>
>>
>>
>>> Also compile time options tend to make code less readable
>>> which makes all aspects of the development harder.
>>>
>>> Yes, compile time is nice for micro optimizations, but
>>> I have great concerns that it is a right way to go.
>>>
>>>>> Please note that I am only talking about the performance
>> optimizations that are limited to application specific use cases. I
>> think it makes sense to require that performance optimizing an
>> application also requires recompiling the performance critical
>> libraries used by it.
>>>>>
>>>>>
>>>>>
>>>>> Allowing compile time options for application specific performance
>> optimizations in DPDK would also open a path for other optimizations,
>> which can only be achieved at compile time, such as “no fragmented
>> packets”, “no attached mbufs” and “single mbuf pool”. And even more
>> exotic optimizations, such as the “indexed mempool cache”, which was
>> rejected due to ABI violations – they could be marked as “risky and
>> untested” or similar, but still be part of the DPDK main repository.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Med venlig hilsen / Kind regards,
>>>>>
>>>>> -Morten Brørup
>>>>>
>>>>>
>>>
>
^ permalink raw reply [relevance 0%]
* RE: Optimizations are not features
2022-06-04 11:10 0% ` Jerin Jacob
@ 2022-06-04 12:19 3% ` Morten Brørup
2022-06-04 12:51 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-06-04 12:19 UTC (permalink / raw)
To: Jerin Jacob, Andrew Rybchenko; +Cc: dpdk-dev, techboard
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Saturday, 4 June 2022 13.10
>
> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru> wrote:
> >
> > On 6/4/22 12:33, Jerin Jacob wrote:
> > > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> <mb@smartsharesystems.com> wrote:
> > >>
> > >> I would like the DPDK community to change its view on compile time
> options. Here is why:
> > >>
> > >>
> > >>
> > >> Application specific performance micro-optimizations like “fast
> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> presented as features.
> > >>
> > >>
> > >>
> > >> They are not features, but optimizations, and I don’t understand
> the need for them to be available at run-time!
> > >>
> > >>
> > >>
> > >> Instead of adding a bunch of exotic exceptions to the fast path of
> the PMDs, they should be compile time options. This will improve
> performance by avoiding branches in the fast path, both for the
> applications using them, and for generic applications (where the exotic
> code is omitted).
> > >
> > > Agree. I think, keeping the best of both worlds would be
> > >
> > > -Enable the feature/optimization as runtime
> > > -Have a compile-time option to disable the feature/optimization as
> an override.
> >
> > It is hard to find the right balance, but in general compile
> > time options are a nightmare for maintenance. Number of
> > required builds will grow as an exponent.
Test combinations are exponential for N features, regardless if N are runtime or compile time options.
> > Of course, we can
> > limit number of checked combinations, but it will result in
> > flow of patches to fix build in other cases.
>
> The build breakage can be fixed if we use (2) vs (1)
>
> 1)
> #ifdef ...
> My feature
> #endif
>
> 2)
> static __rte_always_inline int
> rte_has_xyz_feature(void)
> {
> #ifdef RTE_LIBRTE_XYZ_FEATURE
> return RTE_LIBRTE_XYZ_FEATURE;
> #else
> return 0;
> #endif
> }
>
> if(rte_has_xyz_feature())) {
> My feature code
>
> }
>
I'm not sure all the features can be covered by that, e.g. added fields in structures.
Also, I would consider such features "opt in" at compile time only. As such, they could be allowed to break the ABI/API.
>
>
> > Also compile time options tend to make code less readable
> > which makes all aspects of the development harder.
> >
> > Yes, compile time is nice for micro optimizations, but
> > I have great concerns that it is a right way to go.
> >
> > >> Please note that I am only talking about the performance
> optimizations that are limited to application specific use cases. I
> think it makes sense to require that performance optimizing an
> application also requires recompiling the performance critical
> libraries used by it.
> > >>
> > >>
> > >>
> > >> Allowing compile time options for application specific performance
> optimizations in DPDK would also open a path for other optimizations,
> which can only be achieved at compile time, such as “no fragmented
> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> exotic optimizations, such as the “indexed mempool cache”, which was
> rejected due to ABI violations – they could be marked as “risky and
> untested” or similar, but still be part of the DPDK main repository.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Med venlig hilsen / Kind regards,
> > >>
> > >> -Morten Brørup
> > >>
> > >>
> >
^ permalink raw reply [relevance 3%]
* Re: Optimizations are not features
2022-06-04 10:00 0% ` Andrew Rybchenko
@ 2022-06-04 11:10 0% ` Jerin Jacob
2022-06-04 12:19 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-06-04 11:10 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: Morten Brørup, dpdk-dev, techboard
On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
<andrew.rybchenko@oktetlabs.ru> wrote:
>
> On 6/4/22 12:33, Jerin Jacob wrote:
> > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> >>
> >> I would like the DPDK community to change its view on compile time options. Here is why:
> >>
> >>
> >>
> >> Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features.
> >>
> >>
> >>
> >> They are not features, but optimizations, and I don’t understand the need for them to be available at run-time!
> >>
> >>
> >>
> >> Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
> >
> > Agree. I think, keeping the best of both worlds would be
> >
> > -Enable the feature/optimization as runtime
> > -Have a compile-time option to disable the feature/optimization as an override.
>
> It is hard to find the right balance, but in general compile
> time options are a nightmare for maintenance. Number of
> required builds will grow as an exponent. Of course, we can
> limit number of checked combinations, but it will result in
> flow of patches to fix build in other cases.
The build breakage can be fixed if we use (2) vs (1)
1)
#ifdef ...
My feature
#endif
2)
static __rte_always_inline int
rte_has_xyz_feature(void)
{
#ifdef RTE_LIBRTE_XYZ_FEATURE
return RTE_LIBRTE_XYZ_FEATURE;
#else
return 0;
#endif
}
if(rte_has_xyz_feature())) {
My feature code
}
> Also compile time options tend to make code less readable
> which makes all aspects of the development harder.
>
> Yes, compile time is nice for micro optimizations, but
> I have great concerns that it is a right way to go.
>
> >> Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
> >>
> >>
> >>
> >> Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository.
> >>
> >>
> >>
> >>
> >>
> >> Med venlig hilsen / Kind regards,
> >>
> >> -Morten Brørup
> >>
> >>
>
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 9:33 0% ` Jerin Jacob
@ 2022-06-04 10:00 0% ` Andrew Rybchenko
2022-06-04 11:10 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2022-06-04 10:00 UTC (permalink / raw)
To: Jerin Jacob, Morten Brørup; +Cc: dpdk-dev, techboard
On 6/4/22 12:33, Jerin Jacob wrote:
> On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>>
>> I would like the DPDK community to change its view on compile time options. Here is why:
>>
>>
>>
>> Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features.
>>
>>
>>
>> They are not features, but optimizations, and I don’t understand the need for them to be available at run-time!
>>
>>
>>
>> Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
>
> Agree. I think, keeping the best of both worlds would be
>
> -Enable the feature/optimization as runtime
> -Have a compile-time option to disable the feature/optimization as an override.
It is hard to find the right balance, but in general compile
time options are a nightmare for maintenance. Number of
required builds will grow as an exponent. Of course, we can
limit number of checked combinations, but it will result in
flow of patches to fix build in other cases.
Also compile time options tend to make code less readable
which makes all aspects of the development harder.
Yes, compile time is nice for micro optimizations, but
I have great concerns that it is a right way to go.
>> Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
>>
>>
>>
>> Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository.
>>
>>
>>
>>
>>
>> Med venlig hilsen / Kind regards,
>>
>> -Morten Brørup
>>
>>
^ permalink raw reply [relevance 0%]
* Re: Optimizations are not features
2022-06-04 9:09 3% Optimizations are not features Morten Brørup
@ 2022-06-04 9:33 0% ` Jerin Jacob
2022-06-04 10:00 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-06-04 9:33 UTC (permalink / raw)
To: Morten Brørup; +Cc: dpdk-dev, techboard
On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> I would like the DPDK community to change its view on compile time options. Here is why:
>
>
>
> Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features.
>
>
>
> They are not features, but optimizations, and I don’t understand the need for them to be available at run-time!
>
>
>
> Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
Agree. I think, keeping the best of both worlds would be
-Enable the feature/optimization as runtime
-Have a compile-time option to disable the feature/optimization as an override.
>
>
>
> Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
>
>
>
> Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository.
>
>
>
>
>
> Med venlig hilsen / Kind regards,
>
> -Morten Brørup
>
>
^ permalink raw reply [relevance 0%]
* Optimizations are not features
@ 2022-06-04 9:09 3% Morten Brørup
2022-06-04 9:33 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-06-04 9:09 UTC (permalink / raw)
To: dev; +Cc: techboard
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
I would like the DPDK community to change its view on compile time options. Here is why:
Application specific performance micro-optimizations like "fast mbuf free" and "mbuf direct re-arm" are being added to DPDK and presented as features.
They are not features, but optimizations, and I don't understand the need for them to be available at run-time!
Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted).
Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it.
Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as "no fragmented packets", "no attached mbufs" and "single mbuf pool". And even more exotic optimizations, such as the "indexed mempool cache", which was rejected due to ABI violations - they could be marked as "risky and untested" or similar, but still be part of the DPDK main repository.
Med venlig hilsen / Kind regards,
-Morten Brørup
[-- Attachment #2: Type: text/html, Size: 3730 bytes --]
^ permalink raw reply [relevance 3%]
* Re: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
@ 2022-06-03 13:26 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2022-06-03 13:26 UTC (permalink / raw)
To: Kusztal, ArkadiuszX; +Cc: Akhil Goyal, dev, Zhang, Roy Fan
"Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com> writes:
>> -----Original Message-----
>> From: Akhil Goyal <gakhil@marvell.com>
>> Sent: Thursday, June 2, 2022 4:25 PM
>> To: Ray Kinsella <mdr@ashroe.eu>
>> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Zhang,
>> Roy Fan <roy.fan.zhang@intel.com>
>> Subject: RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
>>
>> >
>> > Akhil Goyal <gakhil@marvell.com> writes:
>> >
>> > >> - Added elliptic curve Diffie-Hellman parameters.
>> > >> Point multiplication allows the user to process every phase of
>> > >> ECDH, but for phase 1, user should not really care about the generator.
>> > >> The user does not even need to know what the generator looks like,
>> > >> therefore setting ec xform would make this work.
>> > >>
>> > >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> > >> ---
>> > >> devtools/libabigail.abignore | 3 +++
>> > >> doc/guides/cryptodevs/features/default.ini | 1 +
>> > >> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
>> > >> doc/guides/rel_notes/release_22_07.rst | 2 ++
>> > >> lib/cryptodev/rte_crypto_asym.h | 38
>> > >> ++++++++++++++++++++++++++++++
>> > >> 5 files changed, 48 insertions(+), 3 deletions(-)
>> > >>
>> > >> diff --git a/devtools/libabigail.abignore
>> > >> b/devtools/libabigail.abignore index 79ff15dc4e..6d174b291f 100644
>> > >> --- a/devtools/libabigail.abignore
>> > >> +++ b/devtools/libabigail.abignore
>> > >> @@ -27,6 +27,9 @@
>> > >> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
>> > >> experimental [suppress_type]
>> > >> name = rte_crypto_asym_op
>> > >> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto
>> > >> +API is
>> > >> experimental
>> > >> +[suppress_type]
>> > >> + name = rte_crypto_asym_xform_type
>> > >>
>> > > This exception does not seem to work.
>> > > Thomas and I are getting ABI issues even with this suppress rule.
>> > >
>> > > [C] 'function void rte_cryptodev_info_get(uint8_t,
>> > > rte_cryptodev_info*)' at
>> > rte_cryptodev.c:1582:1 has some indirect sub-type changes:
>> > > parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
>> > > in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'const rte_cryptodev_capabilities* capabilities' changed:
>> > > in pointed to type 'const rte_cryptodev_capabilities':
>> > > in unqualified underlying type 'struct
>> > > rte_cryptodev_capabilities' at
>> > rte_cryptodev.h:198:1:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'anonymous data member union
>> > {rte_cryptodev_symmetric_capability sym;
>> > rte_cryptodev_asymmetric_capability asym;}' changed:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'rte_cryptodev_asymmetric_capability asym' changed:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of
>> > > 'rte_cryptodev_asymmetric_xform_capability
>> > xform_capa' changed:
>> > > type size hasn't changed
>> > > 1 data member change:
>> > > type of 'rte_crypto_asym_xform_type xform_type' changed:
>> > > type size hasn't changed
>> > > 1 enumerator insertion:
>> > >
>> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
>> > > 2 enumerator changes:
>> > >
>> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from
>> value
>> > '8' to '9' at rte_crypto_asym.h:80:1
>> > >
>> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END'
>> > from value '9' to '10' at rte_crypto_asym.h:80:1
>> >
>> > Ok - will take a look see.
>> Thomas has fixed the suppress rule while pulling on main.
>
> For some unknown reason both:
> [suppress_type]
> type_kind = enum
> changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> and
> [suppress_type]
> name = rte_crypto_asym_xform_type
>
> works fine for me with check-abi tool:
> {DPDK_NEW}/devtools/check-abi.sh ${DPDK_REF}/build/ref ${DPDK_NEW}/build/new
>
> Otherwise I get:
>
> 1 function with some indirect sub-type change:
>
> [C]'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
>
> abidiff: 1.2.0 version
So like you with 1.2.0 I didn't see the error, with 2.0.0 I see the
following, so I recommend that you update to 2.0.0 or later. I had
inadvertently reverted versions after a system rebuild.
ninja: Entering directory `./build-gcc-static'
ninja: no work to do.
ninja: Entering directory `./build-gcc-shared'
ninja: no work to do.
Error: ABI issue reported for 'abidiff --suppr /root/src/dpdk/devtools/../devtools/libabigail.abignore --no-added-syms --headers-dir1 /root/src/dpdk/build_ref/v21.11/build-gcc-shared/usr/local/include --headers-dir2 /root/src/dpdk/build-gcc-shared/install/usr/local/include /root/src/dpdk/build_ref/v21.11/build-gcc-shared/dump/librte_cryptodev.dump /root/src/dpdk/build-gcc-shared/install/dump/librte_cryptodev.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Error: ABI issue reported for 'abidiff --suppr /root/src/dpdk/devtools/../devtools/libabigail.abignore --no-added-syms --headers-dir1 /root/src/dpdk/build_ref/v21.11/build-gcc-shared/usr/local/include --headers-dir2 /root/src/dpdk/build-gcc-shared/install/usr/local/include /root/src/dpdk/build_ref/v21.11/build-gcc-shared/dump/librte_security.dump /root/src/dpdk/build-gcc-shared/install/dump/librte_security.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Me thinks, we need to add a check for libabigail version to the build
scripts.
That all said, Thomas's supression rule has better percision than the
original proposed.
> @Akhil - additionally RTE_CRYPTO_ASYM_XFORM_ECDH was supposed to be placed at the end of the enum. My mistake, I have placed it incorrectly.
> Would a fix that swaps these enums be accepted? This could potentially remove changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM.
--
Regards, Ray K
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-06-03 7:29 0% ` Bruce Richardson
@ 2022-06-03 7:43 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-03 7:43 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, Stephen Hemminger, Vladimir Medvedkin, dev,
Frank Zhao, Sam Grove, upstream
03/06/2022 09:29, Bruce Richardson:
> On Thu, Jun 02, 2022 at 10:52:25PM +0200, Thomas Monjalon wrote:
> > 01/06/2022 13:15, Stanislaw Kardach:
> > > All other rte_lpm_lookup* functions take lpm argument as a const. As the
> > > basic rte_lpm_lookup() performs the same function, it should also do
> > > that.
> > >
> > > As this function is inline, no API/ABI change happens.
> >
> > It is an API change and should be noted in the release notes.
> >
> > > static inline int
> > > -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> > > +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> >
> While I've no particular objection to it appearing in the RN doc, I wonder
> whether it really counts as an API change. I can't see any practical
> difference that this change would make to the end user - no source code
> needs updating for example.
Yes you're right, we can skip the release notes here.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-06-02 20:52 0% ` Thomas Monjalon
@ 2022-06-03 7:29 0% ` Bruce Richardson
2022-06-03 7:43 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-06-03 7:29 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Stanislaw Kardach, Stephen Hemminger, Vladimir Medvedkin, dev,
Frank Zhao, Sam Grove, upstream
On Thu, Jun 02, 2022 at 10:52:25PM +0200, Thomas Monjalon wrote:
> 01/06/2022 13:15, Stanislaw Kardach:
> > All other rte_lpm_lookup* functions take lpm argument as a const. As the
> > basic rte_lpm_lookup() performs the same function, it should also do
> > that.
> >
> > As this function is inline, no API/ABI change happens.
>
> It is an API change and should be noted in the release notes.
>
> > static inline int
> > -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> > +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
>
While I've no particular objection to it appearing in the RN doc, I wonder
whether it really counts as an API change. I can't see any practical
difference that this change would make to the end user - no source code
needs updating for example.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH 07/14] net/nfp: support NFDK firmware
2022-06-02 1:52 6% ` [PATCH 07/14] net/nfp: support NFDK firmware Jin Liu
@ 2022-06-02 22:53 0% ` Ferruh Yigit
2022-06-14 8:49 3% ` Kevin Liu
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-06-02 22:53 UTC (permalink / raw)
To: Jin Liu, dev; +Cc: niklas.soderlund, Diana Wang, Peng Zhang, Chaoyong He
On 6/2/2022 2:52 AM, Jin Liu wrote:
> Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
> according to the firmware version, mount different driver functions.
>
Creating a new set of dev_ops for new FW is a way and it works, but it
looks like it creates some duplication of the code, and maintaining
multiple dev_ops can be difficult (driver already has different ones for
PF & VF).
Another option can be keeping ethdev interface same, but manage
different FWs closer to FW, where directly interacted with FW.
Like keeping dev_ops as 'nfp_net_tx_queue_release()' and managing
different FW within this function, instead of having two dev_ops,
'nfp_net_nfdk_tx_queue_release()' & 'nfp_net_nfd3_tx_queue_release()'.
If difference is small, this can be better to reduce duplication.
What is the difference between two FWs, as far as I can see Tx
descriptor is different and queue setup is affected, is it only diff?
> Signed-off-by: Jin Liu <jin.liu@corigine.com>
> Signed-off-by: Diana Wang <na.wang@corigine.com>
> Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
<...>
> @@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
> eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
> eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
>
> + hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
> + if (hw->ctrl_bar == NULL) {
> + PMD_DRV_LOG(ERR,
> + "hw->ctrl_bar is NULL. BAR0 not configured");
> + return -ENODEV;
> + }
> +
> + PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
> +
> + hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
> +
> + switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
> + case NFP_NET_CFG_VERSION_DP_NFD3:
> + break;
> + case NFP_NET_CFG_VERSION_DP_NFDK:
> + if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
> + PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
> + NFD_CFG_MAJOR_VERSION_of(hw->ver));
> + return -EINVAL;
> + }
> + break;
> + default:
> + PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
> + return -EINVAL;
> + }
> +
This part seems extracted to its own function for PF
('nfp_net_ethdev_ops_mount()'), why not do the same for VF, to have same
logic between them.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-06-01 11:15 3% [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
@ 2022-06-02 20:52 0% ` Thomas Monjalon
2022-06-03 7:29 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-06-02 20:52 UTC (permalink / raw)
To: Stanislaw Kardach, Stephen Hemminger
Cc: Vladimir Medvedkin, dev, dev, Frank Zhao, Sam Grove, upstream
01/06/2022 13:15, Stanislaw Kardach:
> All other rte_lpm_lookup* functions take lpm argument as a const. As the
> basic rte_lpm_lookup() performs the same function, it should also do
> that.
>
> As this function is inline, no API/ABI change happens.
It is an API change and should be noted in the release notes.
> static inline int
> -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 14:25 0% ` Akhil Goyal
@ 2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
2022-06-03 13:26 4% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Kusztal, ArkadiuszX @ 2022-06-02 14:46 UTC (permalink / raw)
To: Akhil Goyal, Ray Kinsella; +Cc: dev, Zhang, Roy Fan
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, June 2, 2022 4:25 PM
> To: Ray Kinsella <mdr@ashroe.eu>
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Zhang,
> Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
>
> >
> > Akhil Goyal <gakhil@marvell.com> writes:
> >
> > >> - Added elliptic curve Diffie-Hellman parameters.
> > >> Point multiplication allows the user to process every phase of
> > >> ECDH, but for phase 1, user should not really care about the generator.
> > >> The user does not even need to know what the generator looks like,
> > >> therefore setting ec xform would make this work.
> > >>
> > >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > >> ---
> > >> devtools/libabigail.abignore | 3 +++
> > >> doc/guides/cryptodevs/features/default.ini | 1 +
> > >> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> > >> doc/guides/rel_notes/release_22_07.rst | 2 ++
> > >> lib/cryptodev/rte_crypto_asym.h | 38
> > >> ++++++++++++++++++++++++++++++
> > >> 5 files changed, 48 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/devtools/libabigail.abignore
> > >> b/devtools/libabigail.abignore index 79ff15dc4e..6d174b291f 100644
> > >> --- a/devtools/libabigail.abignore
> > >> +++ b/devtools/libabigail.abignore
> > >> @@ -27,6 +27,9 @@
> > >> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> > >> experimental [suppress_type]
> > >> name = rte_crypto_asym_op
> > >> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto
> > >> +API is
> > >> experimental
> > >> +[suppress_type]
> > >> + name = rte_crypto_asym_xform_type
> > >>
> > > This exception does not seem to work.
> > > Thomas and I are getting ABI issues even with this suppress rule.
> > >
> > > [C] 'function void rte_cryptodev_info_get(uint8_t,
> > > rte_cryptodev_info*)' at
> > rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> > > parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
> > > in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'const rte_cryptodev_capabilities* capabilities' changed:
> > > in pointed to type 'const rte_cryptodev_capabilities':
> > > in unqualified underlying type 'struct
> > > rte_cryptodev_capabilities' at
> > rte_cryptodev.h:198:1:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'anonymous data member union
> > {rte_cryptodev_symmetric_capability sym;
> > rte_cryptodev_asymmetric_capability asym;}' changed:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'rte_cryptodev_asymmetric_capability asym' changed:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of
> > > 'rte_cryptodev_asymmetric_xform_capability
> > xform_capa' changed:
> > > type size hasn't changed
> > > 1 data member change:
> > > type of 'rte_crypto_asym_xform_type xform_type' changed:
> > > type size hasn't changed
> > > 1 enumerator insertion:
> > >
> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
> > > 2 enumerator changes:
> > >
> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from
> value
> > '8' to '9' at rte_crypto_asym.h:80:1
> > >
> > 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END'
> > from value '9' to '10' at rte_crypto_asym.h:80:1
> >
> > Ok - will take a look see.
> Thomas has fixed the suppress rule while pulling on main.
For some unknown reason both:
[suppress_type]
type_kind = enum
changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
and
[suppress_type]
name = rte_crypto_asym_xform_type
works fine for me with check-abi tool:
{DPDK_NEW}/devtools/check-abi.sh ${DPDK_REF}/build/ref ${DPDK_NEW}/build/new
Otherwise I get:
1 function with some indirect sub-type change:
[C]'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
abidiff: 1.2.0 version
@Akhil - additionally RTE_CRYPTO_ASYM_XFORM_ECDH was supposed to be placed at the end of the enum. My mistake, I have placed it incorrectly.
Would a fix that swaps these enums be accepted? This could potentially remove changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM.
^ permalink raw reply [relevance 4%]
* RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 14:21 0% ` Ray Kinsella
@ 2022-06-02 14:25 0% ` Akhil Goyal
2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-06-02 14:25 UTC (permalink / raw)
To: Ray Kinsella; +Cc: Arek Kusztal, dev, roy.fan.zhang
>
> Akhil Goyal <gakhil@marvell.com> writes:
>
> >> - Added elliptic curve Diffie-Hellman parameters.
> >> Point multiplication allows the user to process every phase of
> >> ECDH, but for phase 1, user should not really care about the generator.
> >> The user does not even need to know what the generator looks like,
> >> therefore setting ec xform would make this work.
> >>
> >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >> ---
> >> devtools/libabigail.abignore | 3 +++
> >> doc/guides/cryptodevs/features/default.ini | 1 +
> >> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> >> doc/guides/rel_notes/release_22_07.rst | 2 ++
> >> lib/cryptodev/rte_crypto_asym.h | 38
> >> ++++++++++++++++++++++++++++++
> >> 5 files changed, 48 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> >> index 79ff15dc4e..6d174b291f 100644
> >> --- a/devtools/libabigail.abignore
> >> +++ b/devtools/libabigail.abignore
> >> @@ -27,6 +27,9 @@
> >> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> >> experimental
> >> [suppress_type]
> >> name = rte_crypto_asym_op
> >> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is
> >> experimental
> >> +[suppress_type]
> >> + name = rte_crypto_asym_xform_type
> >>
> > This exception does not seem to work.
> > Thomas and I are getting ABI issues even with this suppress rule.
> >
> > [C] 'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at
> rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> > parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
> > in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
> > type size hasn't changed
> > 1 data member change:
> > type of 'const rte_cryptodev_capabilities* capabilities' changed:
> > in pointed to type 'const rte_cryptodev_capabilities':
> > in unqualified underlying type 'struct rte_cryptodev_capabilities' at
> rte_cryptodev.h:198:1:
> > type size hasn't changed
> > 1 data member change:
> > type of 'anonymous data member union
> {rte_cryptodev_symmetric_capability sym;
> rte_cryptodev_asymmetric_capability asym;}' changed:
> > type size hasn't changed
> > 1 data member change:
> > type of 'rte_cryptodev_asymmetric_capability asym' changed:
> > type size hasn't changed
> > 1 data member change:
> > type of 'rte_cryptodev_asymmetric_xform_capability
> xform_capa' changed:
> > type size hasn't changed
> > 1 data member change:
> > type of 'rte_crypto_asym_xform_type xform_type' changed:
> > type size hasn't changed
> > 1 enumerator insertion:
> >
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
> > 2 enumerator changes:
> >
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from value
> '8' to '9' at rte_crypto_asym.h:80:1
> >
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END'
> from value '9' to '10' at rte_crypto_asym.h:80:1
>
> Ok - will take a look see.
Thomas has fixed the suppress rule while pulling on main.
^ permalink raw reply [relevance 0%]
* Re: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
@ 2022-06-02 14:21 0% ` Ray Kinsella
2022-06-02 14:25 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-06-02 14:21 UTC (permalink / raw)
To: Akhil Goyal; +Cc: Arek Kusztal, dev, roy.fan.zhang
Akhil Goyal <gakhil@marvell.com> writes:
>> - Added elliptic curve Diffie-Hellman parameters.
>> Point multiplication allows the user to process every phase of
>> ECDH, but for phase 1, user should not really care about the generator.
>> The user does not even need to know what the generator looks like,
>> therefore setting ec xform would make this work.
>>
>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> ---
>> devtools/libabigail.abignore | 3 +++
>> doc/guides/cryptodevs/features/default.ini | 1 +
>> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
>> doc/guides/rel_notes/release_22_07.rst | 2 ++
>> lib/cryptodev/rte_crypto_asym.h | 38
>> ++++++++++++++++++++++++++++++
>> 5 files changed, 48 insertions(+), 3 deletions(-)
>>
>> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
>> index 79ff15dc4e..6d174b291f 100644
>> --- a/devtools/libabigail.abignore
>> +++ b/devtools/libabigail.abignore
>> @@ -27,6 +27,9 @@
>> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
>> experimental
>> [suppress_type]
>> name = rte_crypto_asym_op
>> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is
>> experimental
>> +[suppress_type]
>> + name = rte_crypto_asym_xform_type
>>
> This exception does not seem to work.
> Thomas and I are getting ABI issues even with this suppress rule.
>
> [C] 'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
> parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
> in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
> type size hasn't changed
> 1 data member change:
> type of 'const rte_cryptodev_capabilities* capabilities' changed:
> in pointed to type 'const rte_cryptodev_capabilities':
> in unqualified underlying type 'struct rte_cryptodev_capabilities' at rte_cryptodev.h:198:1:
> type size hasn't changed
> 1 data member change:
> type of 'anonymous data member union {rte_cryptodev_symmetric_capability sym; rte_cryptodev_asymmetric_capability asym;}' changed:
> type size hasn't changed
> 1 data member change:
> type of 'rte_cryptodev_asymmetric_capability asym' changed:
> type size hasn't changed
> 1 data member change:
> type of 'rte_cryptodev_asymmetric_xform_capability xform_capa' changed:
> type size hasn't changed
> 1 data member change:
> type of 'rte_crypto_asym_xform_type xform_type' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
> 2 enumerator changes:
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from value '8' to '9' at rte_crypto_asym.h:80:1
> 'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END' from value '9' to '10' at rte_crypto_asym.h:80:1
Ok - will take a look see.
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-01 9:02 4% ` [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
@ 2022-06-02 13:33 3% ` Akhil Goyal
2022-06-02 14:21 0% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2022-06-02 13:33 UTC (permalink / raw)
To: Arek Kusztal, dev, Ray Kinsella; +Cc: roy.fan.zhang
> - Added elliptic curve Diffie-Hellman parameters.
> Point multiplication allows the user to process every phase of
> ECDH, but for phase 1, user should not really care about the generator.
> The user does not even need to know what the generator looks like,
> therefore setting ec xform would make this work.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> devtools/libabigail.abignore | 3 +++
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> doc/guides/rel_notes/release_22_07.rst | 2 ++
> lib/cryptodev/rte_crypto_asym.h | 38
> ++++++++++++++++++++++++++++++
> 5 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 79ff15dc4e..6d174b291f 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -27,6 +27,9 @@
> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> experimental
> [suppress_type]
> name = rte_crypto_asym_op
> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is
> experimental
> +[suppress_type]
> + name = rte_crypto_asym_xform_type
>
This exception does not seem to work.
Thomas and I are getting ABI issues even with this suppress rule.
[C] 'function void rte_cryptodev_info_get(uint8_t, rte_cryptodev_info*)' at rte_cryptodev.c:1582:1 has some indirect sub-type changes:
parameter 2 of type 'rte_cryptodev_info*' has sub-type changes:
in pointed to type 'struct rte_cryptodev_info' at rte_cryptodev.h:503:1:
type size hasn't changed
1 data member change:
type of 'const rte_cryptodev_capabilities* capabilities' changed:
in pointed to type 'const rte_cryptodev_capabilities':
in unqualified underlying type 'struct rte_cryptodev_capabilities' at rte_cryptodev.h:198:1:
type size hasn't changed
1 data member change:
type of 'anonymous data member union {rte_cryptodev_symmetric_capability sym; rte_cryptodev_asymmetric_capability asym;}' changed:
type size hasn't changed
1 data member change:
type of 'rte_cryptodev_asymmetric_capability asym' changed:
type size hasn't changed
1 data member change:
type of 'rte_cryptodev_asymmetric_xform_capability xform_capa' changed:
type size hasn't changed
1 data member change:
type of 'rte_crypto_asym_xform_type xform_type' changed:
type size hasn't changed
1 enumerator insertion:
'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECDH' value '8'
2 enumerator changes:
'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_ECPM' from value '8' to '9' at rte_crypto_asym.h:80:1
'rte_crypto_asym_xform_type::RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END' from value '9' to '10' at rte_crypto_asym.h:80:1
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 14:03 4% ` Danilewicz, MarcinX
@ 2022-06-02 9:57 3% ` Danilewicz, MarcinX
1 sibling, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-06-02 9:57 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
+this time to dpdk.org , to test removal of automatic footer
Hi Cristian,
< snip >
> > +++ b/lib/sched/rte_sched.h
> > @@ -128,6 +128,8 @@ extern "C" {
> > enum rte_sched_cman_mode {
> > RTE_SCHED_CMAN_RED, /**< Random Early Detection (RED) */
> > RTE_SCHED_CMAN_PIE, /**< Proportional Integral Controller
< snip >
> Can you please explain why you need to add the new
> RTE_SCHED_CMAN_NONE value to this enumeration and what is the ABI
> breakage that you are trying to avoid?
>
well, it was third value for cases when no RED or PIE is configured from config file
Initially I have found this error:
1 data member change:
type of 'rte_sched_cman_params* rte_sched_subport_params::cman_params' changed:
in pointed to type 'struct rte_sched_cman_params' at rte_sched.h:166:1:
type size hasn't changed
1 data member change:
type of 'rte_sched_cman_mode rte_sched_cman_params::cman_mode' changed:
type size hasn't changed
1 enumerator insertion:
'rte_sched_cman_mode::RTE_SCHED_CMAN_NONE' value '0'
2 enumerator changes:
'rte_sched_cman_mode::RTE_SCHED_CMAN_RED' from value '0' to '1' at rte_sched.h:128:1
'rte_sched_cman_mode::RTE_SCHED_CMAN_PIE' from value '1' to '2' at rte_sched.h:128:1
Error: ABI issue reported for 'abidiff --suppr devtools/libabigail.abignore --no-added-syms
--headers-dir1 reference/usr/local/include --headers-dir2 install/usr/local/include reference
/dump/librte_sched.dump install/dump/librte_sched.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Then I moved RTE_SCHED_CMAN_NONE to the end of existing enum, as advices. That removed error above.
In that moment, I needed quick fix for discussion about change for showing approach. Not final fix.
< snip >
> The library expects the struct rte_sched_subport_params:: cman_params to
> be NULL when the CMAN is disabled, why is this not enough to detect that
> CMAN is disabled? I suggest to keep the current approach.
Ok, I'll try to use NULL instead.
Kind Regards,
/Marcin
^ permalink raw reply [relevance 3%]
* [PATCH 07/14] net/nfp: support NFDK firmware
@ 2022-06-02 1:52 6% ` Jin Liu
2022-06-02 22:53 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Jin Liu @ 2022-06-02 1:52 UTC (permalink / raw)
To: dev; +Cc: niklas.soderlund, Jin Liu, Diana Wang, Peng Zhang, Chaoyong He
Modify nfp driver logic, add firmware version (NFD3 or NFDK) judgment, will
according to the firmware version, mount different driver functions.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Signed-off-by: Diana Wang <na.wang@corigine.com>
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
drivers/net/nfp/nfp_ctrl.h | 2 ++
drivers/net/nfp/nfp_ethdev.c | 51 ++++++++++++++++++++++++++-------
drivers/net/nfp/nfp_ethdev_vf.c | 37 +++++++++++++++++-------
3 files changed, 69 insertions(+), 21 deletions(-)
diff --git a/drivers/net/nfp/nfp_ctrl.h b/drivers/net/nfp/nfp_ctrl.h
index 4dd62ef194..e73715e2aa 100644
--- a/drivers/net/nfp/nfp_ctrl.h
+++ b/drivers/net/nfp/nfp_ctrl.h
@@ -135,6 +135,8 @@
* - define more STS bits
*/
#define NFP_NET_CFG_VERSION 0x0030
+#define NFP_NET_CFG_VERSION_DP_NFD3 0
+#define NFP_NET_CFG_VERSION_DP_NFDK 1
#define NFP_NET_CFG_VERSION_RESERVED_MASK (0xff << 24)
#define NFP_NET_CFG_VERSION_CLASS_MASK (0xff << 16)
#define NFP_NET_CFG_VERSION_CLASS(x) (((x) & 0xff) << 16)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 4d2cd9b0b3..c09a035323 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -358,6 +358,32 @@ static const struct eth_dev_ops nfp_net_nfd3_eth_dev_ops = {
.rx_queue_intr_disable = nfp_rx_queue_intr_disable,
};
+static inline int
+nfp_net_ethdev_ops_mount(struct nfp_net_hw *hw, struct rte_eth_dev *eth_dev)
+{
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
+ eth_dev->rx_queue_count = nfp_net_rx_queue_count;
+ eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
+ eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
+ return 0;
+}
+
static int
nfp_net_init(struct rte_eth_dev *eth_dev)
{
@@ -384,7 +410,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
RTE_LOG(ERR, PMD, "device %s can not be used: restricted dma "
"mask to 40 bits!\n", pci_dev->device.name);
return -ENODEV;
- };
+ }
port = ((struct nfp_net_hw *)eth_dev->data->dev_private)->idx;
if (port < 0 || port > 7) {
@@ -401,11 +427,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
-
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -440,6 +461,11 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
@@ -472,7 +498,6 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
nfp_net_cfg_queue_setup(hw);
/* Get some of the read-only fields from the config BAR */
- hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
hw->cap = nn_cfg_readl(hw, NFP_NET_CFG_CAP);
hw->max_mtu = nn_cfg_readl(hw, NFP_NET_CFG_MAX_MTU);
hw->mtu = RTE_ETHER_MTU;
@@ -938,6 +963,7 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
int err;
int total_ports;
struct nfp_cpp *cpp;
+ struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -987,11 +1013,14 @@ nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
"ethdev doesn't exist");
return -ENODEV;
}
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
eth_dev->process_private = cpp;
- eth_dev->dev_ops = &nfp_net_nfd3_eth_dev_ops;
- eth_dev->rx_queue_count = nfp_net_rx_queue_count;
- eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
- eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+
rte_eth_dev_probing_finish(eth_dev);
}
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index f5a0406e7d..e83c9dbcaf 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -287,7 +287,7 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
RTE_LOG(ERR, PMD, "device %s can not be used: restricted dma "
"mask to 40 bits!\n", pci_dev->device.name);
return -ENODEV;
- };
+ }
hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
@@ -296,6 +296,32 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = &nfp_net_recv_pkts;
eth_dev->tx_pkt_burst = &nfp_net_nfd3_xmit_pkts;
+ hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
+ if (hw->ctrl_bar == NULL) {
+ PMD_DRV_LOG(ERR,
+ "hw->ctrl_bar is NULL. BAR0 not configured");
+ return -ENODEV;
+ }
+
+ PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
+
+ hw->ver = nn_cfg_readl(hw, NFP_NET_CFG_VERSION);
+
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer,found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
/* For secondary processes, the primary has done all the work */
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -312,15 +338,6 @@ nfp_netvf_init(struct rte_eth_dev *eth_dev)
pci_dev->addr.domain, pci_dev->addr.bus,
pci_dev->addr.devid, pci_dev->addr.function);
- hw->ctrl_bar = (uint8_t *)pci_dev->mem_resource[0].addr;
- if (hw->ctrl_bar == NULL) {
- PMD_DRV_LOG(ERR,
- "hw->ctrl_bar is NULL. BAR0 not configured");
- return -ENODEV;
- }
-
- PMD_INIT_LOG(DEBUG, "ctrl bar: %p", hw->ctrl_bar);
-
hw->max_rx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_RXRINGS);
hw->max_tx_queues = nn_cfg_readl(hw, NFP_NET_CFG_MAX_TXRINGS);
--
2.27.0
^ permalink raw reply [relevance 6%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-26 11:02 0% ` Ray Kinsella
@ 2022-06-01 15:04 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-06-01 15:04 UTC (permalink / raw)
To: dev
Cc: Tyler Retzlaff, david.marchand, techboard, David Christensen,
Ray Kinsella
26/05/2022 13:02, Ray Kinsella:
> Thomas Monjalon <thomas@monjalon.net> writes:
> > 25/05/2022 20:34, Tyler Retzlaff:
> >> On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
> >> > Thomas Monjalon <thomas@monjalon.net> writes:
> >> > > 25/05/2022 13:48, Ray Kinsella:
> >> > >> Thomas Monjalon <thomas@monjalon.net> writes:
> >> > >>
> >> > >> > The AltiVec header file is defining "vector", except in C++ build.
> >> > >> > The keyword "vector" may conflict easily.
> >> > >> > As a rule, it is better to use the alternative keyword "__vector".
> >> > >> >
> >> > >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
> >> > >> > so the applications and dependencies are free to define the name "vector".
> >> > >> >
> >> > >> > This is a compatibility breakage for applications which were using
> >> > >> > the keyword "vector" for its AltiVec meaning.
> >> > >> >
> >> > >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >> > >> > ---
> >> > >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> >> > >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
> >> > >> > 2 files changed, 12 insertions(+)
> >> > >> >
> >> > >>
> >> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> >> > >
> >> > > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> >> > > It means the keyword vector is not available anymore with this #include.
> >> > > Please confirm it is OK to merge in DPDK 22.07.
> >> >
> >> > I did think about it yes ;-).
> >> > I can't see how it would break the ABI in the short term.
> >> > And it makes sense to preclude this keyword in the long term.
> >> >
> >> > So I ack'ed - did I miss something?
> >>
> >> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >>
> >> double ack, impact of break is understood as follows.
> >>
> >> * this is not an issue with abi it is an issue with api.
> >> * the break will cause a compile failure, the action to resolve is to
> >> replace vector with __vector.
> >
> > Exactly
> >
> > I'll wait few days or acks from the techboard, and will apply.
>
> +1
Applied
^ permalink raw reply [relevance 0%]
* [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup
@ 2022-06-01 11:15 3% Stanislaw Kardach
2022-06-02 20:52 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Stanislaw Kardach @ 2022-06-01 11:15 UTC (permalink / raw)
To: Vladimir Medvedkin
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, upstream,
Stephen Hemminger
All other rte_lpm_lookup* functions take lpm argument as a const. As the
basic rte_lpm_lookup() performs the same function, it should also do
that.
As this function is inline, no API/ABI change happens.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/lpm/rte_lpm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index eb91960e81..1cf863a146 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
* -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
*/
static inline int
-rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
+rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
{
unsigned tbl24_index = (ip >> 8);
uint32_t tbl_entry;
--
2.30.2
^ permalink raw reply [relevance 3%]
* RE: [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
2022-06-01 9:02 4% ` [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
@ 2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Kusztal, ArkadiuszX @ 2022-06-01 10:14 UTC (permalink / raw)
To: dev; +Cc: gakhil, Zhang, Roy Fan
Hi Akhil,
I did not put much effort into documentation part. I believe it needs bit more attention in asym area (one bigger patch) + backported fixes about ECDSA and ECPM.
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Wednesday, June 1, 2022 11:03 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
>
> - Added elliptic curve Diffie-Hellman parameters.
> Point multiplication allows the user to process every phase of ECDH, but for
> phase 1, user should not really care about the generator.
> The user does not even need to know what the generator looks like, therefore
> setting ec xform would make this work.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> devtools/libabigail.abignore | 3 +++
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
> doc/guides/rel_notes/release_22_07.rst | 2 ++
> lib/cryptodev/rte_crypto_asym.h | 38
> ++++++++++++++++++++++++++++++
> 5 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore index
> 79ff15dc4e..6d174b291f 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -27,6 +27,9 @@
> ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> experimental [suppress_type]
> name = rte_crypto_asym_op
> +; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API
> +is experimental [suppress_type]
> + name = rte_crypto_asym_xform_type
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ; Temporary exceptions till next major ABI version ; diff --git
> a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 018fe0221e..7371ca6644 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -118,6 +118,7 @@ Modular Inversion =
> Diffie-hellman =
> ECDSA =
> ECPM =
> +ECDH =
>
> ;
> ; Supported Operating systems of a default crypto driver.
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index edd11059bc..9e54683aa1 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -1018,9 +1018,9 @@ Asymmetric Cryptography
> -----------------------
>
> The cryptodev library currently provides support for the following asymmetric -
> Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman -
> public and/or private key generation and shared secret compute, DSA Signature -
> generation and verification.
> +Crypto operations; RSA, Modular exponentiation and inversion,
> +Diffie-Hellman and Elliptic Curve Diffie-Hellman public and/or private
> +key generation and shared secret compute, DSA Signature generation and
> verification.
>
> Session and Session Management
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> @@ -1088,6 +1088,7 @@ Each xform defines specific asymmetric crypto algo.
> Currently supported are:
> * Modular operations (Exponentiation and Inverse)
> * Diffie-Hellman
> * DSA
> +* Elliptic Curve Diffie-Hellman
> * None - special case where PMD may support a passthrough mode. More for
> diagnostic purpose
>
> See *DPDK API Reference* for details on each rte_crypto_xxx_xform struct diff
> --git a/doc/guides/rel_notes/release_22_07.rst
> b/doc/guides/rel_notes/release_22_07.rst
> index 73a2434f86..ef6eaf0ad2 100644
> --- a/doc/guides/rel_notes/release_22_07.rst
> +++ b/doc/guides/rel_notes/release_22_07.rst
> @@ -130,6 +130,8 @@ Removed Items
> API Changes
> -----------
>
> +* cryptodev: Added Elliptic Curve Diffie-Hellman (ECDH) algorithm.
> +
> .. This section should contain API changes. Sample format:
>
> * sample: Add a short 1-2 sentence description of the API change diff --git
> a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h index
> 88bc34dc8c..f61a2ddce8 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
> /**< Elliptic Curve Digital Signature Algorithm
> * Perform Signature Generation and Verification.
> */
> + RTE_CRYPTO_ASYM_XFORM_ECDH,
> + /**< Elliptic Curve Diffie Hellman */
> RTE_CRYPTO_ASYM_XFORM_ECPM,
> /**< Elliptic Curve Point Multiplication */
> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> @@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param { };
>
> /**
> + * Elliptic Curve Diffie-Hellman Operations params.
> + */
> +struct rte_crypto_ecdh_op_param {
> + enum rte_crypto_asym_ke_type ke_type;
> + /**< Key exchange operation type */
> + rte_crypto_uint priv_key;
> + /**<
> + * Output - generated private key when ke_type is
> + * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
> + *
> + * Input - private key when ke_type is one of:
> + * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
> + * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
> + *
> + * In case priv_key.length is 0 and ke_type is set with
> + * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
> + * device will generate private key and use it for public
> + * key generation.
> + */
> + struct rte_crypto_ec_point pub_key;
> + /**<
> + * Output - generated public key when ke_type is
> + * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
> + *
> + * Input - peer's public key when ke_type is
> + * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
> + */
> + struct rte_crypto_ec_point shared_secret;
> + /**<
> + * Output - calculated shared secret when ke_type is
> + * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
> + */
> +};
> +
> +/**
> * DSA Operations params
> *
> */
> @@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
> struct rte_crypto_mod_op_param modex;
> struct rte_crypto_mod_op_param modinv;
> struct rte_crypto_dh_op_param dh;
> + struct rte_crypto_ecdh_op_param ecdh;
> struct rte_crypto_dsa_op_param dsa;
> struct rte_crypto_ecdsa_op_param ecdsa;
> struct rte_crypto_ecpm_op_param ecpm;
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman
@ 2022-06-01 9:02 4% ` Arek Kusztal
2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
0 siblings, 2 replies; 200+ results
From: Arek Kusztal @ 2022-06-01 9:02 UTC (permalink / raw)
To: dev; +Cc: gakhil, roy.fan.zhang, Arek Kusztal
- Added elliptic curve Diffie-Hellman parameters.
Point multiplication allows the user to process every phase of
ECDH, but for phase 1, user should not really care about the generator.
The user does not even need to know what the generator looks like,
therefore setting ec xform would make this work.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
devtools/libabigail.abignore | 3 +++
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/prog_guide/cryptodev_lib.rst | 7 +++---
doc/guides/rel_notes/release_22_07.rst | 2 ++
lib/cryptodev/rte_crypto_asym.h | 38 ++++++++++++++++++++++++++++++
5 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..6d174b291f 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,9 @@
; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
[suppress_type]
name = rte_crypto_asym_op
+; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is experimental
+[suppress_type]
+ name = rte_crypto_asym_xform_type
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 018fe0221e..7371ca6644 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -118,6 +118,7 @@ Modular Inversion =
Diffie-hellman =
ECDSA =
ECPM =
+ECDH =
;
; Supported Operating systems of a default crypto driver.
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index edd11059bc..9e54683aa1 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -1018,9 +1018,9 @@ Asymmetric Cryptography
-----------------------
The cryptodev library currently provides support for the following asymmetric
-Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman
-public and/or private key generation and shared secret compute, DSA Signature
-generation and verification.
+Crypto operations; RSA, Modular exponentiation and inversion, Diffie-Hellman and
+Elliptic Curve Diffie-Hellman public and/or private key generation and shared
+secret compute, DSA Signature generation and verification.
Session and Session Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1088,6 +1088,7 @@ Each xform defines specific asymmetric crypto algo. Currently supported are:
* Modular operations (Exponentiation and Inverse)
* Diffie-Hellman
* DSA
+* Elliptic Curve Diffie-Hellman
* None - special case where PMD may support a passthrough mode. More for diagnostic purpose
See *DPDK API Reference* for details on each rte_crypto_xxx_xform struct
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index 73a2434f86..ef6eaf0ad2 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -130,6 +130,8 @@ Removed Items
API Changes
-----------
+* cryptodev: Added Elliptic Curve Diffie-Hellman (ECDH) algorithm.
+
.. This section should contain API changes. Sample format:
* sample: Add a short 1-2 sentence description of the API change
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 88bc34dc8c..f61a2ddce8 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm
* Perform Signature Generation and Verification.
*/
+ RTE_CRYPTO_ASYM_XFORM_ECDH,
+ /**< Elliptic Curve Diffie Hellman */
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
@@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param {
};
/**
+ * Elliptic Curve Diffie-Hellman Operations params.
+ */
+struct rte_crypto_ecdh_op_param {
+ enum rte_crypto_asym_ke_type ke_type;
+ /**< Key exchange operation type */
+ rte_crypto_uint priv_key;
+ /**<
+ * Output - generated private key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
+ *
+ * Input - private key when ke_type is one of:
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ *
+ * In case priv_key.length is 0 and ke_type is set with
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+ * device will generate private key and use it for public
+ * key generation.
+ */
+ struct rte_crypto_ec_point pub_key;
+ /**<
+ * Output - generated public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
+ *
+ * Input - peer's public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+ struct rte_crypto_ec_point shared_secret;
+ /**<
+ * Output - calculated shared secret when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+};
+
+/**
* DSA Operations params
*
*/
@@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_mod_op_param modex;
struct rte_crypto_mod_op_param modinv;
struct rte_crypto_dh_op_param dh;
+ struct rte_crypto_ecdh_op_param ecdh;
struct rte_crypto_dsa_op_param dsa;
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
--
2.13.6
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
2022-05-30 20:38 0% ` Stephen Hemminger
@ 2022-06-01 9:35 0% ` Medvedkin, Vladimir
1 sibling, 0 replies; 200+ results
From: Medvedkin, Vladimir @ 2022-06-01 9:35 UTC (permalink / raw)
To: Stanislaw Kardach; +Cc: dev, Frank Zhao, Sam Grove, mw, upstream
On 30/05/2022 19:24, Stanislaw Kardach wrote:
> All other rte_lpm_lookup* functions take lpm argument as a const. As the
> basic rte_lpm_lookup() performs the same function, it should also do
> that.
>
> As this function is inline, no API/ABI change happens.
>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
> ---
> lib/lpm/rte_lpm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
> index eb91960e81..1cf863a146 100644
> --- a/lib/lpm/rte_lpm.h
> +++ b/lib/lpm/rte_lpm.h
> @@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
> * -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
> */
> static inline int
> -rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> +rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
> {
> unsigned tbl24_index = (ip >> 8);
> uint32_t tbl_entry;
Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
--
Regards,
Vladimir
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
2022-05-31 1:09 0% ` Min Hu (Connor)
@ 2022-05-31 16:09 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-05-31 16:09 UTC (permalink / raw)
To: jerinj
Cc: dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko,
ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, cristian.dumitrescu
On Mon, 30 May 2022 18:45:26 +0530
<jerinj@marvell.com> wrote:
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
The concept of supporting hardware queue management is good, but would like
to make some suggestions:
The hardware support of QOS should ideally be part of the existing DPDK
traffic management. For example, in Linux there are devices that can offload
traffic control (TC) to hardware and this is done via flags to existing
software infrastructure.
Your implementation makes HW and SW QoS diverge. This will require each application
to get even more dependent on a particular hardware device.
Which brings up the bigger picture problem. Don't want to repeat the problems
with rte_flow here. Any hardware support needs to have a matching set of software
implementation, and test cases. The problem with rte_flow is the semantics are
poorly defined and each vendor does it differently; and the SW flow classifier
is incomplete and does not match what the HW does.
In an ideal world, there would be:
- an abstract API for defining ingress and egress queue management
- a software implementation of that API
- multiple hardware implementations
- ability to transparently use both SW and HW queue management from application
- complete test suite for that API.
Yes, that is asking a lot. But as trailblazer in this area, you have to do the
hard work.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 0/6] move DPAA2 QDMA driver freom raw to dma
@ 2022-05-31 15:29 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-05-31 15:29 UTC (permalink / raw)
To: nipun.gupta, hemant.agrawal; +Cc: dev, G.Singh, gakhil
26/05/2022 08:00, Hemant Agrawal:
> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>
> On 5/5/2022 2:35 PM, nipun.gupta@nxp.com wrote:
> > From: Nipun Gupta <nipun.gupta@nxp.com>
> >
> > This change removes the DPAA2 QDMA raw driver and adds the
> > QDMA driver in dma set of drivers. The underlying I/O
> > framework remains intact, whereas the configuration part
> > is done as per the DMA API support.
> >
> > Changes in v2:
> > - Fix checkpath errors
> > - Fix documentation compilation
> >
> > Changes in v3:
> > - Add the missing doc/dmadevs/dpaa2.rst file
> >
> > Nipun Gupta (6):
> > raw/dpaa2_qdma: remove dpaa2 QDMA driver from raw
> > dma/dpaa2: introduce DPAA2 DMA driver skeleton
> > dma/dpaa2: support basic operations
> > dma/dpaa2: add PMD apis for additional configuration
> > dma/dpaa2: support DMA operations
> > dma/dpaa2: support statistics
Fixed some mistakes in the file MAINTAINERS,
and added an exception in devtools/check-abi.sh to skip old driver.
Applied, thanks.
^ permalink raw reply [relevance 3%]
* [PATCH v4 7/8] devtools: add RISC-V to test-meson-builds.sh
@ 2022-05-31 14:13 9% ` Stanislaw Kardach
0 siblings, 0 replies; 200+ results
From: Stanislaw Kardach @ 2022-05-31 14:13 UTC (permalink / raw)
To: Bruce Richardson
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
Validate RISC-V compilation when test-meson-builds.sh is called. The
check will be only performed if appropriate toolchain is present on the
system (same as with other architectures).
Sponsored-by: Frank Zhao <Frank.Zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
devtools/test-meson-builds.sh | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index a653b253cb..f732dccf6c 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -275,6 +275,10 @@ for f in $srcdir/config/ppc/ppc* ; do
build $targetdir $f ABI $use_shared
done
+# RISC-V configuration
+build build-riscv64-linux-gcc $srcdir/config/riscv/riscv64_linux_gcc ABI \
+ $use_shared
+
# Test installation of the x86-generic target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
load_env cc
--
2.30.2
^ permalink raw reply [relevance 9%]
* RE: [PATCH v3] pcap: support MTU set
2022-05-30 18:05 0% ` Ferruh Yigit
@ 2022-05-31 13:12 0% ` Ido Goshen
0 siblings, 0 replies; 200+ results
From: Ido Goshen @ 2022-05-31 13:12 UTC (permalink / raw)
To: Ferruh Yigit, stephen; +Cc: dev, Tianli Lai
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> Sent: Monday, 30 May 2022 21:06
> To: Ido Goshen <Ido@cgstowernetworks.com>; ferruh.yigit@xilinx.com;
> stephen@networkplumber.org
> Cc: dev@dpdk.org; Tianli Lai <laitianli@tom.com>
> Subject: Re: [PATCH v3] pcap: support MTU set
>
> On 5/30/2022 11:36 AM, Ido Goshen wrote:
> > Support rte_eth_dev_set_mtu by pcap vdevs Enforce mtu on rx/tx
> >
>
> Still not sure about enforcing MTU on pcap, but please find comments on
> mechanical issues
[idog] Trying to detail more about use cases:
1. CI tests which are HW independent and works with --vdevs=net_pcap
For testing that mtu feature(s) work correctly in our app a pcap that contains
mix sized packets should be used. Using pcap that has only small size packets
will miss the all point.
2. Customer support - it's much simpler to debug on a workstation and not
real HW setup. We often get the customer's configuration and a pcap in order
to reproduce an issue. It will be a pain and error-prone to manipulate the pcap
before using it.
I will address the mechanical issues and post v4 patch
> > Bugzilla ID: 961
> > Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
> >
> > ---
> > v3:
> > Preserve pcap behavior to support max size packets by default
> > alternative to v2 in order to limit the code change to pcap only and
> > avoid abi change.
> > Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
> >
> > v2:
> > Preserve pcap behavior to support max size packets by default.
> > ---
> > drivers/net/pcap/pcap_ethdev.c | 44
> +++++++++++++++++++++++++++++++---
> > 1 file changed, 41 insertions(+), 3 deletions(-)
> >
>
> Is documentation needs to be updated as well?
[idog] I don't think so
It's using the standard rte_eth_dev_set_mtu() which is already documented in
features.rst https://doc.dpdk.org/guides/nics/features.html#mtu-update
I don't see other PMDs mention explicitly they support it (it's the normal behaviour)
> And what do you think to update release notes for this update?
[idog] ok
> > +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
> > + if (unlikely(len > dev->data->mtu) &&
> > + internals->is_mtu_set) {
>
> It is possible to save only some part of the packet to the pcap file, please
> check snaplen patch [1], how MTU config should work with this feature?
>
> [1]
> https://patchwork.dpdk.org/project/dpdk/patch/20220313112638.3945-1-
> laitianli@tom.com/
>
[idog] interesting to know this is being work on.
(To your method, why is it needed? there are tools like editpcap that can be
applied on the dpdk output file and snap the packets ;-)
I think integration of the 2 features is trivial, mtu controls if the packet is
written to file or not, and snaplan controls what part of it needs to be written.
i.e. mtu is checked before snaplen.
Using snaplen > mtu will become meaningless (maybe block/warn on such configuration)
Alternative is to apply mtu only on pcap iface (assuming snaplen is applied only
on tx_pcap file)
If supporting mtu only for pcap live ifaces and not for pcap files then
the all thing can be implemented differently by setting the OS netdevice
mtu (e.g. in linux SIOCSIFMTU) instead of enforcing it by the pcap pmd
but this will require osdep use and I admit I have no idea how to do it for windows
Would this be a better approach?
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-05-31 7:49 0% ` [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Zhang, Roy Fan
@ 2022-05-31 11:52 0% ` Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-05-31 11:52 UTC (permalink / raw)
To: Arek Kusztal, dev; +Cc: roy.fan.zhang
> This patchset introduces some of changes discussed on mailing list for 22.07
> release in cryptodev asym.
>
> Key changes:
>
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Adds Eliiptic-Curve point verification
> - Adds RSA missing padding fields
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
>
> v4:
> - fixed shared build problem
> - added ABI ignore entry for xform
The Documentation is still not updated for these changes.
Please update doc/guides/prog_guide/cryptodev_lib.rst
And doc/guides/cryptodevs/features/default.ini (for ECDH)
Also update release notes (ECDH).
>
> Arek Kusztal (12):
> cryptodev: redefine ec group enum
> cryptodev: separate key exchange operation enum
> cryptodev: remove comment about using ephemeral key in dsa
> cryptodev: clarify usage of private key in dh
> cryptodev: move dh type from xform to dh op
> cryptodev: add elliptic curve diffie hellman
> cryptodev: add public key verify option
> cryptodev: add asym op flags
> cryptodev: clarify usage of rsa padding hash
> cryptodev: move RSA padding into separate struct
> cryptodev: clarify rsa verify with none padding
> cryptodev: add salt length and optional label
>
> app/test/test_cryptodev_asym.c | 63 ++++----
> devtools/libabigail.abignore | 3 +
> drivers/common/cpt/cpt_ucode_asym.h | 4 +-
> drivers/crypto/cnxk/cnxk_ae.h | 8 +-
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
> drivers/crypto/openssl/rte_openssl_pmd.c | 17 +--
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +---
> drivers/crypto/qat/qat_asym.c | 12 +-
> lib/cryptodev/rte_crypto_asym.h | 217 ++++++++++++++++++++-------
> lib/cryptodev/rte_cryptodev.c | 15 +-
> lib/cryptodev/rte_cryptodev.h | 4 +-
> lib/cryptodev/version.map | 1 +
> 12 files changed, 237 insertions(+), 144 deletions(-)
>
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
@ 2022-05-31 7:49 0% ` Zhang, Roy Fan
2022-05-31 11:52 0% ` [EXT] " Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2022-05-31 7:49 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, dev; +Cc: gakhil
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:04 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
>
> This patchset introduces some of changes discussed on mailing list for 22.07
> release in cryptodev asym.
>
> Key changes:
>
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Adds Eliiptic-Curve point verification
> - Adds RSA missing padding fields
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
>
> v4:
> - fixed shared build problem
> - added ABI ignore entry for xform
>
> Arek Kusztal (12):
> cryptodev: redefine ec group enum
> cryptodev: separate key exchange operation enum
> cryptodev: remove comment about using ephemeral key in dsa
> cryptodev: clarify usage of private key in dh
> cryptodev: move dh type from xform to dh op
> cryptodev: add elliptic curve diffie hellman
> cryptodev: add public key verify option
> cryptodev: add asym op flags
> cryptodev: clarify usage of rsa padding hash
> cryptodev: move RSA padding into separate struct
> cryptodev: clarify rsa verify with none padding
> cryptodev: add salt length and optional label
>
> app/test/test_cryptodev_asym.c | 63 ++++----
> devtools/libabigail.abignore | 3 +
> drivers/common/cpt/cpt_ucode_asym.h | 4 +-
> drivers/crypto/cnxk/cnxk_ae.h | 8 +-
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
> drivers/crypto/openssl/rte_openssl_pmd.c | 17 +--
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +---
> drivers/crypto/qat/qat_asym.c | 12 +-
> lib/cryptodev/rte_crypto_asym.h | 217 ++++++++++++++++++++-----
> --
> lib/cryptodev/rte_cryptodev.c | 15 +-
> lib/cryptodev/rte_cryptodev.h | 4 +-
> lib/cryptodev/version.map | 1 +
> 12 files changed, 237 insertions(+), 144 deletions(-)
>
> --
> 2.13.6
Series-acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
@ 2022-05-31 4:04 4% ` Arek Kusztal
2022-05-31 7:49 0% ` [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Zhang, Roy Fan
2022-05-31 11:52 0% ` [EXT] " Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Arek Kusztal @ 2022-05-31 4:04 UTC (permalink / raw)
To: dev; +Cc: gakhil, roy.fan.zhang, Arek Kusztal, mdr
- Added elliptic curve Diffie-Hellman parameters.
Point multiplication allows the user to process every phase of
ECDH, but for phase 1, user should not really care about the generator.
The user does not even need to know what the generator looks like,
therefore setting ec xform would make this work.
Cc: mdr@ashroe.eu
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
devtools/libabigail.abignore | 3 +++
lib/cryptodev/rte_crypto_asym.h | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..6d174b291f 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,9 @@
; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
[suppress_type]
name = rte_crypto_asym_op
+; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is experimental
+[suppress_type]
+ name = rte_crypto_asym_xform_type
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 88bc34dc8c..f61a2ddce8 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Digital Signature Algorithm
* Perform Signature Generation and Verification.
*/
+ RTE_CRYPTO_ASYM_XFORM_ECDH,
+ /**< Elliptic Curve Diffie Hellman */
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
@@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param {
};
/**
+ * Elliptic Curve Diffie-Hellman Operations params.
+ */
+struct rte_crypto_ecdh_op_param {
+ enum rte_crypto_asym_ke_type ke_type;
+ /**< Key exchange operation type */
+ rte_crypto_uint priv_key;
+ /**<
+ * Output - generated private key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
+ *
+ * Input - private key when ke_type is one of:
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ *
+ * In case priv_key.length is 0 and ke_type is set with
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+ * device will generate private key and use it for public
+ * key generation.
+ */
+ struct rte_crypto_ec_point pub_key;
+ /**<
+ * Output - generated public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
+ *
+ * Input - peer's public key when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+ struct rte_crypto_ec_point shared_secret;
+ /**<
+ * Output - calculated shared secret when ke_type is
+ * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+ */
+};
+
+/**
* DSA Operations params
*
*/
@@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_mod_op_param modex;
struct rte_crypto_mod_op_param modinv;
struct rte_crypto_dh_op_param dh;
+ struct rte_crypto_ecdh_op_param ecdh;
struct rte_crypto_dsa_op_param dsa;
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
--
2.13.6
^ permalink raw reply [relevance 4%]
* [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
@ 2022-05-31 4:04 3% Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Arek Kusztal @ 2022-05-31 4:04 UTC (permalink / raw)
To: dev; +Cc: gakhil, roy.fan.zhang, Arek Kusztal
This patchset introduces some of changes discussed on mailing list for 22.07 release in cryptodev asym.
Key changes:
- It fixes API for RSA (expescially signature paddings)
- Adds Elliptic-Curve Diffie-Hellman
- Adds Eliiptic-Curve point verification
- Adds RSA missing padding fields
- Adds asym op flags
- Fixes many API comments (like EC curves)
v4:
- fixed shared build problem
- added ABI ignore entry for xform
Arek Kusztal (12):
cryptodev: redefine ec group enum
cryptodev: separate key exchange operation enum
cryptodev: remove comment about using ephemeral key in dsa
cryptodev: clarify usage of private key in dh
cryptodev: move dh type from xform to dh op
cryptodev: add elliptic curve diffie hellman
cryptodev: add public key verify option
cryptodev: add asym op flags
cryptodev: clarify usage of rsa padding hash
cryptodev: move RSA padding into separate struct
cryptodev: clarify rsa verify with none padding
cryptodev: add salt length and optional label
app/test/test_cryptodev_asym.c | 63 ++++----
devtools/libabigail.abignore | 3 +
drivers/common/cpt/cpt_ucode_asym.h | 4 +-
drivers/crypto/cnxk/cnxk_ae.h | 8 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 17 +--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 33 +---
drivers/crypto/qat/qat_asym.c | 12 +-
lib/cryptodev/rte_crypto_asym.h | 217 ++++++++++++++++++++-------
lib/cryptodev/rte_cryptodev.c | 15 +-
lib/cryptodev/rte_cryptodev.h | 4 +-
lib/cryptodev/version.map | 1 +
12 files changed, 237 insertions(+), 144 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
@ 2022-05-31 1:09 0% ` Min Hu (Connor)
2022-05-31 16:09 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Min Hu (Connor) @ 2022-05-31 1:09 UTC (permalink / raw)
To: jerinj, dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, cristian.dumitrescu
Hi, jerinj,
在 2022/5/30 21:15, jerinj@marvell.com 写道:
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> doc/guides/nics/features.rst | 12 +++
> doc/guides/nics/features/default.ini | 1 +
> lib/eal/include/meson.build | 1 +
> lib/eal/include/rte_cman.h | 51 ++++++++++
> lib/ethdev/rte_ethdev.h | 145 +++++++++++++++++++++++++++
> 5 files changed, 210 insertions(+)
> create mode 100644 lib/eal/include/rte_cman.h
>
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 21bedb743f..ffcc2bcc92 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -727,6 +727,18 @@ Supports configuring per-queue stat counter mapping.
> ``rte_eth_dev_set_tx_queue_stats_mapping()``.
>
>
> +.. _nic_features_congestion_management
> +
> +Congestion management
> +---------------------
> +
> +Supports congestion management.
> +
> +* **[implements] eth_dev_ops**: ``cman_info_get``, ``cman_config_set``, ``cman_config_get``.
> +* **[related] API**: ``rte_eth_cman_info_get()``, ``rte_eth_cman_config_init()``,
> + ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
> +
> +
> .. _nic_features_fw_version:
>
> FW version
> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
> index b1d18ac62c..060497e41f 100644
> --- a/doc/guides/nics/features/default.ini
> +++ b/doc/guides/nics/features/default.ini
> @@ -60,6 +60,7 @@ Tx descriptor status =
> Basic stats =
> Extended stats =
> Stats per queue =
> +Congestion management =
> FW version =
> EEPROM dump =
> Module EEPROM dump =
> diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
> index 9700494816..40e31e0e6d 100644
> --- a/lib/eal/include/meson.build
> +++ b/lib/eal/include/meson.build
> @@ -10,6 +10,7 @@ headers += files(
> 'rte_branch_prediction.h',
> 'rte_bus.h',
> 'rte_class.h',
> + 'rte_cman.h',
> 'rte_common.h',
> 'rte_compat.h',
> 'rte_debug.h',
> diff --git a/lib/eal/include/rte_cman.h b/lib/eal/include/rte_cman.h
> new file mode 100644
> index 0000000000..e6dad2ebf7
> --- /dev/null
> +++ b/lib/eal/include/rte_cman.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2022 Marvell International Ltd.
> + */
> +
> +#ifndef RTE_CMAN_H
> +#define RTE_CMAN_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_bitops.h>
> +
> +/**
> + * @file
> + * Congestion management related parameters for DPDK.
> + */
> +
> +/** Congestion management modes */
> +enum rte_cman_mode {
> + /** Congestion based on Random Early Detection.
> + *
> + * https://en.wikipedia.org/wiki/Random_early_detection
> + * @see struct rte_cman_red_params
> + */
> + RTE_CMAN_RED = RTE_BIT64(0),
> +};
> +
> +/**
> + * RED based congestion management configuration parameters.
> + */
> +struct rte_cman_red_params {
> + /**< Minimum threshold (min_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t min_th;
> + /**< Maximum threshold (max_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t max_th;
> + /** Inverse of packet marking probability maximum value (maxp = 1 / maxp_inv) */
> + uint16_t maxp_inv;
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* RTE_CMAN_H */
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8ee10..7c8718bb2e 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -160,6 +160,7 @@ extern "C" {
> #define RTE_ETHDEV_DEBUG_TX
> #endif
>
> +#include <rte_cman.h>
> #include <rte_compat.h>
> #include <rte_log.h>
> #include <rte_interrupts.h>
> @@ -5452,6 +5453,150 @@ typedef struct {
> __rte_experimental
> int rte_eth_dev_priv_dump(uint16_t port_id, FILE *file);
>
> +/* Congestion management */
> +
> +/** Enumerate list of ethdev congestion management objects */
> +enum rte_eth_cman_obj {
> + /** Congestion management based on Rx queue depth */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE = RTE_BIT64(0),
> + /** Congestion management based on mempool depth associated with Rx queue
> + * @see rte_eth_rx_queue_setup()
> + */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL = RTE_BIT64(1),
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
'API' --> 'structure'
> + *
> + * A structure used to retrieve information of ethdev congestion management.
> + */
> +struct rte_eth_cman_info {
> + /** Set of supported congestion management modes
> + * @see enum rte_cman_mode
> + */
> + uint64_t modes_supported;
> + /** Set of supported congestion management objects
> + * @see enum rte_eth_cman_obj
> + */
> + uint64_t objs_supported;
> + /** Reserved for future fields */
> + uint8_t rsvd[64];
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
'API' --> 'structure'
> + *
> + * A structure used to configure the ethdev congestion management.
> + */
> +struct rte_eth_cman_config {
> + /** Congestion management object */
> + enum rte_eth_cman_obj obj;
> + /** Congestion management mode */
> + enum rte_cman_mode mode;
> + union {
> + /** Rx queue to configure congestion management.
> + *
> + * Valid when object is RTE_ETH_CMAN_OBJ_RX_QUEUE or
> + * RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL.
> + */
> + uint16_t rx_queue;
> + /** Reserved for future fields */
> + uint8_t rsvd_obj_params[16];
> + } obj_param;
> + union {
> + /** RED configuration parameters.
> + *
> + * Valid when mode is RTE_CMAN_RED.
> + */
> + struct rte_cman_red_params red;
> + /** Reserved for future fields */
> + uint8_t rsvd_mode_params[64];
> + } mode_param;
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the information for ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param info
> + * A pointer to a structure of type *rte_eth_cman_info* to be filled with
> + * the information about congestion management.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_info_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_info_get(uint16_t port_id, struct rte_eth_cman_info *info);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Initialize the ethdev congestion management configuration structure with default values.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be initialized
> + * with default value.
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_init(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Configure ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be configured.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_set does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_set(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the applied ethdev congestion management parameters for the given port.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to retrieve
> + * congestion management parameters for the given object.
> + * Application must fill all parameters except mode_param parameter in
> + * struct rte_eth_cman_config.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_get(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> #include <rte_ethdev_core.h>
>
> /**
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
@ 2022-05-30 20:38 0% ` Stephen Hemminger
2022-06-01 9:35 0% ` Medvedkin, Vladimir
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2022-05-30 20:38 UTC (permalink / raw)
To: Stanislaw Kardach
Cc: Vladimir Medvedkin, dev, Frank Zhao, Sam Grove, mw, upstream
On Mon, 30 May 2022 20:24:36 +0200
Stanislaw Kardach <kda@semihalf.com> wrote:
> All other rte_lpm_lookup* functions take lpm argument as a const. As the
> basic rte_lpm_lookup() performs the same function, it should also do
> that.
>
> As this function is inline, no API/ABI change happens.
>
> Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
@ 2022-05-30 19:43 0% ` Ajit Khaparde
2022-07-13 12:11 0% ` Jerin Jacob
2022-05-31 1:09 0% ` Min Hu (Connor)
2022-05-31 16:09 0% ` Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: Ajit Khaparde @ 2022-05-30 19:43 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: dpdk-dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko,
Andrew Boyer, Beilei Xing, Bruce Richardson, Chas Williams, Xia,
Chenbo, Ciara Loftus, Devendra Singh Rawat, Ed Czeck,
Evgeny Schemeilin, Gaetan Rivet, Gagandeep Singh, Guoyang Zhou,
Haiyue Wang, Harman Kalra, Heinrich Kuhn, Hemant Agrawal,
Hyong Youb Kim, Igor Chauskin, Igor Russkikh, Jakub Grajciar,
Singh, Jasvinder, Jian Wang, Jiawen Wu, Jingjing Wu, John Daley,
John Miller, John W. Linville, Wiles, Keith, Kiran Kumar K,
oulijun, Liron Himi, Long Li, Marcin Wojtas, Martin Spinler,
Matan Azrad, Matt Peters, Maxime Coquelin, Michal Krawczyk,
Min Hu (Connor),
Nalla Pradeep, Nithin Dabilpuram, Qiming Yang, Qi Zhang,
Radha Mohan Chintakuntla, Rahul Lakkireddy, Rasesh Mody,
Rosen Xu, Sachin Saxena (OSS),
Satha Rao, Shahed Shaikh, Shai Brandes, Shepard Siegel,
Somalapuram Amaranath, Somnath Kotur, Stephen Hemminger,
Steven Webster, Sunil Kumar Kori, Tetsuya Mukawa,
Veerasenareddy Burru, Slava Ovsiienko, Xiao Wang, Xiaoyun Wang,
Yisen Zhuang, Yong Wang, Ziyang Xuan, Dumitrescu, Cristian
[-- Attachment #1: Type: text/plain, Size: 10369 bytes --]
On Mon, May 30, 2022 at 6:16 AM <jerinj@marvell.com> wrote:
>
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
Can you also add How all this helps an application? Thanks
>
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> ---
> doc/guides/nics/features.rst | 12 +++
> doc/guides/nics/features/default.ini | 1 +
> lib/eal/include/meson.build | 1 +
> lib/eal/include/rte_cman.h | 51 ++++++++++
> lib/ethdev/rte_ethdev.h | 145 +++++++++++++++++++++++++++
> 5 files changed, 210 insertions(+)
> create mode 100644 lib/eal/include/rte_cman.h
>
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 21bedb743f..ffcc2bcc92 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -727,6 +727,18 @@ Supports configuring per-queue stat counter mapping.
> ``rte_eth_dev_set_tx_queue_stats_mapping()``.
>
>
> +.. _nic_features_congestion_management
> +
> +Congestion management
> +---------------------
> +
> +Supports congestion management.
> +
> +* **[implements] eth_dev_ops**: ``cman_info_get``, ``cman_config_set``, ``cman_config_get``.
> +* **[related] API**: ``rte_eth_cman_info_get()``, ``rte_eth_cman_config_init()``,
> + ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
> +
> +
> .. _nic_features_fw_version:
>
> FW version
> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
> index b1d18ac62c..060497e41f 100644
> --- a/doc/guides/nics/features/default.ini
> +++ b/doc/guides/nics/features/default.ini
> @@ -60,6 +60,7 @@ Tx descriptor status =
> Basic stats =
> Extended stats =
> Stats per queue =
> +Congestion management =
> FW version =
> EEPROM dump =
> Module EEPROM dump =
> diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
> index 9700494816..40e31e0e6d 100644
> --- a/lib/eal/include/meson.build
> +++ b/lib/eal/include/meson.build
> @@ -10,6 +10,7 @@ headers += files(
> 'rte_branch_prediction.h',
> 'rte_bus.h',
> 'rte_class.h',
> + 'rte_cman.h',
> 'rte_common.h',
> 'rte_compat.h',
> 'rte_debug.h',
> diff --git a/lib/eal/include/rte_cman.h b/lib/eal/include/rte_cman.h
> new file mode 100644
> index 0000000000..e6dad2ebf7
> --- /dev/null
> +++ b/lib/eal/include/rte_cman.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2022 Marvell International Ltd.
> + */
> +
> +#ifndef RTE_CMAN_H
> +#define RTE_CMAN_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_bitops.h>
> +
> +/**
> + * @file
> + * Congestion management related parameters for DPDK.
> + */
> +
> +/** Congestion management modes */
> +enum rte_cman_mode {
> + /** Congestion based on Random Early Detection.
> + *
> + * https://en.wikipedia.org/wiki/Random_early_detection
> + * @see struct rte_cman_red_params
> + */
> + RTE_CMAN_RED = RTE_BIT64(0),
> +};
> +
> +/**
> + * RED based congestion management configuration parameters.
> + */
> +struct rte_cman_red_params {
> + /**< Minimum threshold (min_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t min_th;
> + /**< Maximum threshold (max_th) value
> + *
> + * Value expressed as percentage. Value must be in 0 to 100(inclusive).
> + */
> + uint8_t max_th;
> + /** Inverse of packet marking probability maximum value (maxp = 1 / maxp_inv) */
> + uint16_t maxp_inv;
> +};
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* RTE_CMAN_H */
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 04cff8ee10..7c8718bb2e 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -160,6 +160,7 @@ extern "C" {
> #define RTE_ETHDEV_DEBUG_TX
> #endif
>
> +#include <rte_cman.h>
> #include <rte_compat.h>
> #include <rte_log.h>
> #include <rte_interrupts.h>
> @@ -5452,6 +5453,150 @@ typedef struct {
> __rte_experimental
> int rte_eth_dev_priv_dump(uint16_t port_id, FILE *file);
>
> +/* Congestion management */
> +
> +/** Enumerate list of ethdev congestion management objects */
> +enum rte_eth_cman_obj {
> + /** Congestion management based on Rx queue depth */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE = RTE_BIT64(0),
> + /** Congestion management based on mempool depth associated with Rx queue
> + * @see rte_eth_rx_queue_setup()
> + */
> + RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL = RTE_BIT64(1),
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * A structure used to retrieve information of ethdev congestion management.
> + */
> +struct rte_eth_cman_info {
> + /** Set of supported congestion management modes
> + * @see enum rte_cman_mode
> + */
> + uint64_t modes_supported;
> + /** Set of supported congestion management objects
> + * @see enum rte_eth_cman_obj
> + */
> + uint64_t objs_supported;
> + /** Reserved for future fields */
> + uint8_t rsvd[64];
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * A structure used to configure the ethdev congestion management.
> + */
> +struct rte_eth_cman_config {
> + /** Congestion management object */
> + enum rte_eth_cman_obj obj;
> + /** Congestion management mode */
> + enum rte_cman_mode mode;
> + union {
> + /** Rx queue to configure congestion management.
> + *
> + * Valid when object is RTE_ETH_CMAN_OBJ_RX_QUEUE or
> + * RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL.
> + */
> + uint16_t rx_queue;
> + /** Reserved for future fields */
> + uint8_t rsvd_obj_params[16];
> + } obj_param;
> + union {
> + /** RED configuration parameters.
> + *
> + * Valid when mode is RTE_CMAN_RED.
> + */
> + struct rte_cman_red_params red;
> + /** Reserved for future fields */
> + uint8_t rsvd_mode_params[64];
> + } mode_param;
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the information for ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param info
> + * A pointer to a structure of type *rte_eth_cman_info* to be filled with
> + * the information about congestion management.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_info_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_info_get(uint16_t port_id, struct rte_eth_cman_info *info);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Initialize the ethdev congestion management configuration structure with default values.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be initialized
> + * with default value.
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_init(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Configure ethdev congestion management
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to be configured.
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_set does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_set(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> + *
> + * Retrieve the applied ethdev congestion management parameters for the given port.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param config
> + * A pointer to a structure of type *rte_eth_cman_config* to retrieve
> + * congestion management parameters for the given object.
> + * Application must fill all parameters except mode_param parameter in
> + * struct rte_eth_cman_config.
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if support for cman_config_get does not exist.
> + * - (-ENODEV) if *port_id* invalid.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_cman_config_get(uint16_t port_id, struct rte_eth_cman_config *config);
> +
> #include <rte_ethdev_core.h>
>
> /**
> --
> 2.36.1
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4218 bytes --]
^ permalink raw reply [relevance 0%]
* [PATCH v3 1/2] lpm: add const to lpm arg of rte_lpm_lookup
2022-05-27 18:18 3% ` [PATCH v2 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
@ 2022-05-30 18:24 3% ` Stanislaw Kardach
2022-05-30 20:38 0% ` Stephen Hemminger
2022-06-01 9:35 0% ` Medvedkin, Vladimir
0 siblings, 2 replies; 200+ results
From: Stanislaw Kardach @ 2022-05-30 18:24 UTC (permalink / raw)
To: Vladimir Medvedkin
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
All other rte_lpm_lookup* functions take lpm argument as a const. As the
basic rte_lpm_lookup() performs the same function, it should also do
that.
As this function is inline, no API/ABI change happens.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
lib/lpm/rte_lpm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index eb91960e81..1cf863a146 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
* -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
*/
static inline int
-rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
+rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
{
unsigned tbl24_index = (ip >> 8);
uint32_t tbl_entry;
--
2.30.2
^ permalink raw reply [relevance 3%]
* Re: [PATCH v3] pcap: support MTU set
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
@ 2022-05-30 18:05 0% ` Ferruh Yigit
2022-05-31 13:12 0% ` Ido Goshen
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-05-30 18:05 UTC (permalink / raw)
To: Ido Goshen, ferruh.yigit, stephen; +Cc: dev, Tianli Lai
On 5/30/2022 11:36 AM, Ido Goshen wrote:
> Support rte_eth_dev_set_mtu by pcap vdevs
> Enforce mtu on rx/tx
>
Still not sure about enforcing MTU on pcap, but please find comments on
mechanical issues
> Bugzilla ID: 961
> Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
>
> ---
> v3:
> Preserve pcap behavior to support max size packets by default
> alternative to v2 in order to limit the code change to pcap only and
> avoid abi change.
> Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
>
> v2:
> Preserve pcap behavior to support max size packets by default.
> ---
> drivers/net/pcap/pcap_ethdev.c | 44 +++++++++++++++++++++++++++++++---
> 1 file changed, 41 insertions(+), 3 deletions(-)
>
Is documentation needs to be updated as well?
And what do you think to update release notes for this update?
> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index ec29fd6bc5..2e7fff9579 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -93,6 +93,7 @@ struct pmd_internals {
> int single_iface;
> int phy_mac;
> unsigned int infinite_rx;
> + int is_mtu_set;
> };
>
> struct pmd_process_private {
> @@ -278,11 +279,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> const u_char *packet;
> struct rte_mbuf *mbuf;
> struct pcap_rx_queue *pcap_q = queue;
> + struct rte_eth_dev *dev = &rte_eth_devices[pcap_q->port_id];
> + struct pmd_internals *internals = dev->data->dev_private;
'rte_eth_devices[]' needs to be used for 'process_private' but lets not
tie it to access 'dev_private'.
You can add "struct pmd_internals *" to the "struct pcap_rx_queue" &
"struct pcap_tx_queue" structs for the access. Please check null PMD for
sample.
> uint16_t num_rx = 0;
> uint32_t rx_bytes = 0;
> pcap_t *pcap;
>
> - pp = rte_eth_devices[pcap_q->port_id].process_private;
> + pp = dev->process_private;
> pcap = pp->rx_pcap[pcap_q->queue_id];
>
> if (unlikely(pcap == NULL || nb_pkts == 0))
> @@ -303,6 +306,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> break;
> }
>
> + if (unlikely(header.caplen > dev->data->mtu) &&
> + internals->is_mtu_set) {
> + pcap_q->rx_stat.err_pkts++;
> + rte_pktmbuf_free(mbuf);
> + break;
> + }
> +
> if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
> /* pcap packet will fit in the mbuf, can copy it */
> rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> @@ -378,6 +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *dumper_q = queue;
> + struct rte_eth_dev *dev = &rte_eth_devices[dumper_q->port_id];
> + struct pmd_internals *internals = dev->data->dev_private;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> struct pcap_pkthdr header;
> @@ -385,7 +397,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
> size_t len, caplen;
>
> - pp = rte_eth_devices[dumper_q->port_id].process_private;
> + pp = dev->process_private;
> dumper = pp->tx_dumper[dumper_q->queue_id];
>
> if (dumper == NULL || nb_pkts == 0)
> @@ -396,6 +408,13 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = caplen = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > dev->data->mtu) &&
> + internals->is_mtu_set) {
It is possible to save only some part of the packet to the pcap file,
please check snaplen patch [1], how MTU config should work with this
feature?
[1]
https://patchwork.dpdk.org/project/dpdk/patch/20220313112638.3945-1-laitianli@tom.com/
> + rte_pktmbuf_free(mbuf);
> + continue;
Normally a PMD should not silently free a packet itself, it should
return error and application will decide to free the packet or not.
> + }
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> caplen = sizeof(temp_data);
> @@ -464,13 +483,15 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> struct rte_mbuf *mbuf;
> struct pmd_process_private *pp;
> struct pcap_tx_queue *tx_queue = queue;
> + struct rte_eth_dev *dev = &rte_eth_devices[tx_queue->port_id];
> + struct pmd_internals *internals = dev->data->dev_private;
> uint16_t num_tx = 0;
> uint32_t tx_bytes = 0;
> pcap_t *pcap;
> unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
> size_t len;
>
> - pp = rte_eth_devices[tx_queue->port_id].process_private;
> + pp = dev->process_private;
> pcap = pp->tx_pcap[tx_queue->queue_id];
>
> if (unlikely(nb_pkts == 0 || pcap == NULL))
> @@ -479,6 +500,13 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
> for (i = 0; i < nb_pkts; i++) {
> mbuf = bufs[i];
> len = rte_pktmbuf_pkt_len(mbuf);
> +
> + if (unlikely(len > dev->data->mtu) &&
> + internals->is_mtu_set) {
> + rte_pktmbuf_free(mbuf);
> + continue;
ditto
> + }
> +
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> PMD_LOG(ERR,
> @@ -807,6 +835,14 @@ eth_stats_reset(struct rte_eth_dev *dev)
> return 0;
> }
>
> +static int eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
Please follow coding convention to have return type in a separate line:
static int
eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
> +{
> + PMD_LOG(INFO, "mtu set %s %u\n", dev->device->name, mtu);
Can you please move the log after variable declerations. And can be good
to capitilise MTU in the log.
> + struct pmd_internals *internals = dev->data->dev_private;
> + internals->is_mtu_set = 1;
> + return 0;
> +}
> +
> static inline void
> infinite_rx_ring_free(struct rte_ring *pkts)
> {
> @@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
> .link_update = eth_link_update,
> .stats_get = eth_stats_get,
> .stats_reset = eth_stats_reset,
> + .mtu_set = eth_mtu_set,
> };
>
> static int
> @@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> .addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
> };
> (*internals)->phy_mac = 0;
> + (*internals)->is_mtu_set = 0;
> data = (*eth_dev)->data;
> data->nb_rx_queues = (uint16_t)nb_rx_queues;
> data->nb_tx_queues = (uint16_t)nb_tx_queues;
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:19 3% ` Dumitrescu, Cristian
@ 2022-05-30 14:03 4% ` Danilewicz, MarcinX
2022-06-02 9:57 3% ` Danilewicz, MarcinX
1 sibling, 0 replies; 200+ results
From: Danilewicz, MarcinX @ 2022-05-30 14:03 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
Hi Cristian,
> Can you please explain why you need to add the new
> RTE_SCHED_CMAN_NONE value to this enumeration and what is the ABI
> breakage that you are trying to avoid?
>
> The library expects the struct rte_sched_subport_params:: cman_params to
> be NULL when the CMAN is disabled, why is this not enough to detect that
> CMAN is disabled? I suggest to keep the current approach.
Well, that above was just another approach. I'll have look to follow your advice, because there should be a third case when no RED or PIR config was found in files.
So I used third enum to detect this case, like here:
> + else if (params->cman_params->cman_mode ==
> RTE_SCHED_CMAN_NONE)
> + return 1;
Also I got this advice to move RTE_SCHED_CMAN_NONE to the bottom to remove ABI warnings, because structure in header file has changed without change in map files (?) for that?
Here is some more detailed log with errors:
1 data member change:
type of 'rte_sched_cman_params* rte_sched_subport_params::cman_params' changed:
in pointed to type 'struct rte_sched_cman_params' at rte_sched.h:166:1:
type size hasn't changed
1 data member change:
type of 'rte_sched_cman_mode rte_sched_cman_params::cman_mode' changed:
type size hasn't changed
1 enumerator insertion:
'rte_sched_cman_mode::RTE_SCHED_CMAN_NONE' value '0'
2 enumerator changes:
'rte_sched_cman_mode::RTE_SCHED_CMAN_RED' from value '0' to '1' at rte_sched.h:128:1
'rte_sched_cman_mode::RTE_SCHED_CMAN_PIE' from value '1' to '2' at rte_sched.h:128:1
Error: ABI issue reported for 'abidiff --suppr devtools/libabigail.abignore --no-added-syms --headers-dir1 reference/usr/local/include --headers-dir2 install/usr/local/include reference/dump/librte_sched.dump install/dump/librte_sched.dump'
ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged this as a potential issue).
Kind Regards,
/Marcin
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC PATCH] ethdev: support congestion management
@ 2022-05-30 13:15 2% jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: jerinj @ 2022-05-30 13:15 UTC (permalink / raw)
To: dev, Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko
Cc: ajit.khaparde, aboyer, beilei.xing, bruce.richardson, chas3,
chenbo.xia, ciara.loftus, dsinghrawat, ed.czeck, evgenys, grive,
g.singh, zhouguoyang, haiyue.wang, hkalra, heinrich.kuhn,
hemant.agrawal, hyonkim, igorch, irusskikh, jgrajcia,
jasvinder.singh, jianwang, jiawenwu, jingjing.wu, johndale,
john.miller, linville, keith.wiles, kirankumark, oulijun, lironh,
longli, mw, spinler, matan, matt.peters, maxime.coquelin, mk,
humin29, pnalla, ndabilpuram, qiming.yang, qi.z.zhang, radhac,
rahul.lakkireddy, rmody, rosen.xu, sachin.saxena, skoteshwar,
shshaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, skori, mtetsuyah, vburru, viacheslavo,
xiao.w.wang, cloud.wangxiaoyun, yisen.zhuang, yongwang,
xuanziyang2, cristian.dumitrescu, Jerin Jacob
From: Jerin Jacob <jerinj@marvell.com>
NIC HW controllers often come with congestion management support on
various HW objects such as Rx queue depth or mempool queue depth.
Also, it can support various modes of operation such as RED
(Random early discard), WRED etc on those HW objects.
This patch adds a framework to express such modes(enum rte_cman_mode)
and introduce (enum rte_eth_cman_obj) to enumerate the different
objects where the modes can operate on.
This patch adds RTE_CMAN_RED mode of operation and
RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
Introduced reserved fields in configuration structure
backed by rte_eth_cman_config_init() to add new configuration
parameters without ABI breakage.
Added rte_eth_cman_info_get() API to get the information such as
supported modes and objects.
Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
to configure congestion management on those object with associated mode.
Finally, Added rte_eth_cman_config_get() API to retrieve the
applied configuration.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
---
doc/guides/nics/features.rst | 12 +++
doc/guides/nics/features/default.ini | 1 +
lib/eal/include/meson.build | 1 +
lib/eal/include/rte_cman.h | 51 ++++++++++
lib/ethdev/rte_ethdev.h | 145 +++++++++++++++++++++++++++
5 files changed, 210 insertions(+)
create mode 100644 lib/eal/include/rte_cman.h
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 21bedb743f..ffcc2bcc92 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -727,6 +727,18 @@ Supports configuring per-queue stat counter mapping.
``rte_eth_dev_set_tx_queue_stats_mapping()``.
+.. _nic_features_congestion_management
+
+Congestion management
+---------------------
+
+Supports congestion management.
+
+* **[implements] eth_dev_ops**: ``cman_info_get``, ``cman_config_set``, ``cman_config_get``.
+* **[related] API**: ``rte_eth_cman_info_get()``, ``rte_eth_cman_config_init()``,
+ ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
+
+
.. _nic_features_fw_version:
FW version
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index b1d18ac62c..060497e41f 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -60,6 +60,7 @@ Tx descriptor status =
Basic stats =
Extended stats =
Stats per queue =
+Congestion management =
FW version =
EEPROM dump =
Module EEPROM dump =
diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build
index 9700494816..40e31e0e6d 100644
--- a/lib/eal/include/meson.build
+++ b/lib/eal/include/meson.build
@@ -10,6 +10,7 @@ headers += files(
'rte_branch_prediction.h',
'rte_bus.h',
'rte_class.h',
+ 'rte_cman.h',
'rte_common.h',
'rte_compat.h',
'rte_debug.h',
diff --git a/lib/eal/include/rte_cman.h b/lib/eal/include/rte_cman.h
new file mode 100644
index 0000000000..e6dad2ebf7
--- /dev/null
+++ b/lib/eal/include/rte_cman.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2022 Marvell International Ltd.
+ */
+
+#ifndef RTE_CMAN_H
+#define RTE_CMAN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_bitops.h>
+
+/**
+ * @file
+ * Congestion management related parameters for DPDK.
+ */
+
+/** Congestion management modes */
+enum rte_cman_mode {
+ /** Congestion based on Random Early Detection.
+ *
+ * https://en.wikipedia.org/wiki/Random_early_detection
+ * @see struct rte_cman_red_params
+ */
+ RTE_CMAN_RED = RTE_BIT64(0),
+};
+
+/**
+ * RED based congestion management configuration parameters.
+ */
+struct rte_cman_red_params {
+ /**< Minimum threshold (min_th) value
+ *
+ * Value expressed as percentage. Value must be in 0 to 100(inclusive).
+ */
+ uint8_t min_th;
+ /**< Maximum threshold (max_th) value
+ *
+ * Value expressed as percentage. Value must be in 0 to 100(inclusive).
+ */
+ uint8_t max_th;
+ /** Inverse of packet marking probability maximum value (maxp = 1 / maxp_inv) */
+ uint16_t maxp_inv;
+};
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* RTE_CMAN_H */
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 04cff8ee10..7c8718bb2e 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -160,6 +160,7 @@ extern "C" {
#define RTE_ETHDEV_DEBUG_TX
#endif
+#include <rte_cman.h>
#include <rte_compat.h>
#include <rte_log.h>
#include <rte_interrupts.h>
@@ -5452,6 +5453,150 @@ typedef struct {
__rte_experimental
int rte_eth_dev_priv_dump(uint16_t port_id, FILE *file);
+/* Congestion management */
+
+/** Enumerate list of ethdev congestion management objects */
+enum rte_eth_cman_obj {
+ /** Congestion management based on Rx queue depth */
+ RTE_ETH_CMAN_OBJ_RX_QUEUE = RTE_BIT64(0),
+ /** Congestion management based on mempool depth associated with Rx queue
+ * @see rte_eth_rx_queue_setup()
+ */
+ RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL = RTE_BIT64(1),
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * A structure used to retrieve information of ethdev congestion management.
+ */
+struct rte_eth_cman_info {
+ /** Set of supported congestion management modes
+ * @see enum rte_cman_mode
+ */
+ uint64_t modes_supported;
+ /** Set of supported congestion management objects
+ * @see enum rte_eth_cman_obj
+ */
+ uint64_t objs_supported;
+ /** Reserved for future fields */
+ uint8_t rsvd[64];
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * A structure used to configure the ethdev congestion management.
+ */
+struct rte_eth_cman_config {
+ /** Congestion management object */
+ enum rte_eth_cman_obj obj;
+ /** Congestion management mode */
+ enum rte_cman_mode mode;
+ union {
+ /** Rx queue to configure congestion management.
+ *
+ * Valid when object is RTE_ETH_CMAN_OBJ_RX_QUEUE or
+ * RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL.
+ */
+ uint16_t rx_queue;
+ /** Reserved for future fields */
+ uint8_t rsvd_obj_params[16];
+ } obj_param;
+ union {
+ /** RED configuration parameters.
+ *
+ * Valid when mode is RTE_CMAN_RED.
+ */
+ struct rte_cman_red_params red;
+ /** Reserved for future fields */
+ uint8_t rsvd_mode_params[64];
+ } mode_param;
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Retrieve the information for ethdev congestion management
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param info
+ * A pointer to a structure of type *rte_eth_cman_info* to be filled with
+ * the information about congestion management.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if support for cman_info_get does not exist.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_info_get(uint16_t port_id, struct rte_eth_cman_info *info);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Initialize the ethdev congestion management configuration structure with default values.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param config
+ * A pointer to a structure of type *rte_eth_cman_config* to be initialized
+ * with default value.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_config_init(uint16_t port_id, struct rte_eth_cman_config *config);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Configure ethdev congestion management
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param config
+ * A pointer to a structure of type *rte_eth_cman_config* to be configured.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if support for cman_config_set does not exist.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_config_set(uint16_t port_id, struct rte_eth_cman_config *config);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Retrieve the applied ethdev congestion management parameters for the given port.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param config
+ * A pointer to a structure of type *rte_eth_cman_config* to retrieve
+ * congestion management parameters for the given object.
+ * Application must fill all parameters except mode_param parameter in
+ * struct rte_eth_cman_config.
+ *
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if support for cman_config_get does not exist.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+__rte_experimental
+int rte_eth_cman_config_get(uint16_t port_id, struct rte_eth_cman_config *config);
+
#include <rte_ethdev_core.h>
/**
--
2.36.1
^ permalink raw reply [relevance 2%]
* RE: [PATCH v2] sched: enable CMAN at runtime
2022-05-30 11:19 3% ` Dumitrescu, Cristian
@ 2022-05-30 11:35 0% ` Dumitrescu, Cristian
2022-06-07 10:40 0% ` Danilewicz, MarcinX
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2 siblings, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2022-05-30 11:35 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha, Liu, Yu Y
Hi Marcin,
Comments inline below.
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Thursday, May 12, 2022 2:11 PM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v2] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Log: v2 change in rte_sched.h to avoid ABI breakage.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 14 +--
> examples/qos_sched/cfg_file.h | 2 -
> examples/qos_sched/init.c | 4 -
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 130 ++++++++++-----------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 53 ++-------
> lib/sched/rte_sched.h | 2 +
> 12 files changed, 371 insertions(+), 140 deletions(-)
> create mode 100644 examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
<snip>
> diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
> index ec74bee939..db14934832 100644
> --- a/lib/sched/rte_sched.c
> +++ b/lib/sched/rte_sched.c
<snip>
> -#ifdef RTE_SCHED_CMAN
> static int
> rte_sched_red_config(struct rte_sched_port *port,
> struct rte_sched_subport *s,
> @@ -1161,9 +1156,11 @@ rte_sched_cman_config(struct rte_sched_port
> *port,
> else if (params->cman_params->cman_mode ==
> RTE_SCHED_CMAN_PIE)
> return rte_sched_pie_config(port, s, params, n_subports);
>
> + else if (params->cman_params->cman_mode ==
> RTE_SCHED_CMAN_NONE)
> + return 1;
> +
> return -EINVAL;
> }
> -#endif
Yes, you do need to remove the #ifdef ... #endif around this function, but no, you don't need to change this function, as it is only called when params->cman_params != NULL, i.e. CMAN is enabled. As mentioned before, there is no need to add the CMAN_NONE to the enumeration, as the CMAN_NONE value is equivalent to params->cman_params being set to NULL.
>
> int
> rte_sched_subport_config(struct rte_sched_port *port,
> @@ -1254,19 +1251,20 @@ rte_sched_subport_config(struct
> rte_sched_port *port,
> s->n_pipe_profiles = params->n_pipe_profiles;
> s->n_max_pipe_profiles = params->n_max_pipe_profiles;
>
> -#ifdef RTE_SCHED_CMAN
> + s->cman_enabled = false;
> +
> if (params->cman_params != NULL) {
> - s->cman_enabled = true;
> status = rte_sched_cman_config(port, s, params,
> n_subports);
> if (status) {
> - RTE_LOG(NOTICE, SCHED,
> - "%s: CMAN configuration fails\n",
> __func__);
> - return status;
> + if (status != 1) {
> + RTE_LOG(NOTICE, SCHED,
> + "%s: CMAN configuration
> fails\n", __func__);
> + return status;
> + }
> + } else {
> + s->cman_enabled = true;
> }
> - } else {
> - s->cman_enabled = false;
> }
> -#endif
>
Same comment here: yes, remove the #ifdef ... #endif, but no need to change this code fragment, as it sets correctly the s->cman_enabled flag, which is then the only flag used by the rest of the code. Again, no need to have a CMAN_NONE in the enumeration, as the same is achieved by setting params->cman_params to NULL.
> /* Scheduling loop detection */
> s->pipe_loop = RTE_SCHED_PIPE_INVALID;
> @@ -1825,14 +1823,10 @@
> rte_sched_port_update_queue_stats_on_drop(struct rte_sched_subport
> *subport,
>
> qe->stats.n_pkts_dropped += 1;
> qe->stats.n_bytes_dropped += pkt_len;
> -#ifdef RTE_SCHED_CMAN
> if (subport->cman_enabled)
> qe->stats.n_pkts_cman_dropped += n_pkts_cman_dropped;
> -#endif
> }
Please don't forget to remove the __rte_unused attribute for the n_pkts_cman_dropped in the function parameters, right?
<snip>
Regards,
Cristian
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2] sched: enable CMAN at runtime
@ 2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 14:03 4% ` Danilewicz, MarcinX
2022-06-02 9:57 3% ` Danilewicz, MarcinX
2022-05-30 11:35 0% ` Dumitrescu, Cristian
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2 siblings, 2 replies; 200+ results
From: Dumitrescu, Cristian @ 2022-05-30 11:19 UTC (permalink / raw)
To: Danilewicz, MarcinX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
> -----Original Message-----
> From: Danilewicz, MarcinX <marcinx.danilewicz@intel.com>
> Sent: Thursday, May 12, 2022 2:11 PM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v2] sched: enable CMAN at runtime
>
> Added changes to enable CMAN (RED or PIE) at init
> from profile configuration file.
>
> By default CMAN code is enable but not in use, when
> there is no RED or PIE profile configured.
>
> Log: v2 change in rte_sched.h to avoid ABI breakage.
>
> Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
> ---
> config/rte_config.h | 3 -
> drivers/net/softnic/rte_eth_softnic_tm.c | 12 --
> examples/ip_pipeline/tmgr.c | 4 -
> examples/qos_sched/cfg_file.c | 14 +--
> examples/qos_sched/cfg_file.h | 2 -
> examples/qos_sched/init.c | 4 -
> examples/qos_sched/main.h | 2 -
> examples/qos_sched/profile.cfg | 130 ++++++++++-----------
> examples/qos_sched/profile_pie.cfg | 142 ++++++++++++++++++++++
> examples/qos_sched/profile_red.cfg | 143 +++++++++++++++++++++++
> lib/sched/rte_sched.c | 53 ++-------
> lib/sched/rte_sched.h | 2 +
> 12 files changed, 371 insertions(+), 140 deletions(-)
> create mode 100644 examples/qos_sched/profile_pie.cfg
> create mode 100644 examples/qos_sched/profile_red.cfg
>
> diff --git a/lib/sched/rte_sched.h b/lib/sched/rte_sched.h
> index 5ece64e527..82aa73ff5b 100644
> --- a/lib/sched/rte_sched.h
> +++ b/lib/sched/rte_sched.h
> @@ -128,6 +128,8 @@ extern "C" {
> enum rte_sched_cman_mode {
> RTE_SCHED_CMAN_RED, /**< Random Early Detection (RED) */
> RTE_SCHED_CMAN_PIE, /**< Proportional Integral Controller
> Enhanced (PIE) */
> + /* New enum RTE_SCHED_CMAN_NONE added at the end to avoid
> ABI breakage */
> + RTE_SCHED_CMAN_NONE, /**< no RED|PIE cfg available */
> };
Can you please explain why you need to add the new RTE_SCHED_CMAN_NONE value to this enumeration and what is the ABI breakage that you are trying to avoid?
The library expects the struct rte_sched_subport_params:: cman_params to be NULL when the CMAN is disabled, why is this not enough to detect that CMAN is disabled? I suggest to keep the current approach.
>
> /*
> --
> 2.25.1
^ permalink raw reply [relevance 3%]
* [PATCH v3] pcap: support MTU set
@ 2022-05-30 10:36 3% ` Ido Goshen
2022-05-30 18:05 0% ` Ferruh Yigit
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
` (3 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Ido Goshen @ 2022-05-30 10:36 UTC (permalink / raw)
To: ferruh.yigit, stephen; +Cc: dev, Ido Goshen
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
Bugzilla ID: 961
Signed-off-by: Ido Goshen <ido@cgstowernetworks.com>
---
v3:
Preserve pcap behavior to support max size packets by default
alternative to v2 in order to limit the code change to pcap only and
avoid abi change.
Enforce mtu only in case rte_eth_dev_set_mtu was explicitly called.
v2:
Preserve pcap behavior to support max size packets by default.
---
drivers/net/pcap/pcap_ethdev.c | 44 +++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..2e7fff9579 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -93,6 +93,7 @@ struct pmd_internals {
int single_iface;
int phy_mac;
unsigned int infinite_rx;
+ int is_mtu_set;
};
struct pmd_process_private {
@@ -278,11 +279,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
const u_char *packet;
struct rte_mbuf *mbuf;
struct pcap_rx_queue *pcap_q = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[pcap_q->port_id];
+ struct pmd_internals *internals = dev->data->dev_private;
uint16_t num_rx = 0;
uint32_t rx_bytes = 0;
pcap_t *pcap;
- pp = rte_eth_devices[pcap_q->port_id].process_private;
+ pp = dev->process_private;
pcap = pp->rx_pcap[pcap_q->queue_id];
if (unlikely(pcap == NULL || nb_pkts == 0))
@@ -303,6 +306,13 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
break;
}
+ if (unlikely(header.caplen > dev->data->mtu) &&
+ internals->is_mtu_set) {
+ pcap_q->rx_stat.err_pkts++;
+ rte_pktmbuf_free(mbuf);
+ break;
+ }
+
if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
/* pcap packet will fit in the mbuf, can copy it */
rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
@@ -378,6 +388,8 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *dumper_q = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[dumper_q->port_id];
+ struct pmd_internals *internals = dev->data->dev_private;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
struct pcap_pkthdr header;
@@ -385,7 +397,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
size_t len, caplen;
- pp = rte_eth_devices[dumper_q->port_id].process_private;
+ pp = dev->process_private;
dumper = pp->tx_dumper[dumper_q->queue_id];
if (dumper == NULL || nb_pkts == 0)
@@ -396,6 +408,13 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = caplen = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > dev->data->mtu) &&
+ internals->is_mtu_set) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
caplen = sizeof(temp_data);
@@ -464,13 +483,15 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *tx_queue = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[tx_queue->port_id];
+ struct pmd_internals *internals = dev->data->dev_private;
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
pcap_t *pcap;
unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
size_t len;
- pp = rte_eth_devices[tx_queue->port_id].process_private;
+ pp = dev->process_private;
pcap = pp->tx_pcap[tx_queue->queue_id];
if (unlikely(nb_pkts == 0 || pcap == NULL))
@@ -479,6 +500,13 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > dev->data->mtu) &&
+ internals->is_mtu_set) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
PMD_LOG(ERR,
@@ -807,6 +835,14 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ PMD_LOG(INFO, "mtu set %s %u\n", dev->device->name, mtu);
+ struct pmd_internals *internals = dev->data->dev_private;
+ internals->is_mtu_set = 1;
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1040,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
@@ -1233,6 +1270,7 @@ pmd_init_internals(struct rte_vdev_device *vdev,
.addr_bytes = { 0x02, 0x70, 0x63, 0x61, 0x70, iface_idx++ }
};
(*internals)->phy_mac = 0;
+ (*internals)->is_mtu_set = 0;
data = (*eth_dev)->data;
data->nb_rx_queues = (uint16_t)nb_rx_queues;
data->nb_tx_queues = (uint16_t)nb_tx_queues;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [PATCH v2 1/2] lpm: add const to lpm arg of rte_lpm_lookup
@ 2022-05-27 18:18 3% ` Stanislaw Kardach
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
1 sibling, 1 reply; 200+ results
From: Stanislaw Kardach @ 2022-05-27 18:18 UTC (permalink / raw)
To: Vladimir Medvedkin
Cc: Stanislaw Kardach, dev, Frank Zhao, Sam Grove, mw, upstream
All other rte_lpm_lookup* functions take lpm argument as a const. As the
basic rte_lpm_lookup() performs the same function, it should also do
that.
As this function is inline, no API/ABI change happens.
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
---
lib/lpm/rte_lpm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index eb91960e81..1cf863a146 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -279,7 +279,7 @@ rte_lpm_delete_all(struct rte_lpm *lpm);
* -EINVAL for incorrect arguments, -ENOENT on lookup miss, 0 on lookup hit
*/
static inline int
-rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
+rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)
{
unsigned tbl24_index = (ip >> 8);
uint32_t tbl_entry;
--
2.30.2
^ permalink raw reply [relevance 3%]
* Re: [PATCH 1/1] lpm: add a scalar version of lookupx4 function
@ 2022-05-27 13:16 3% ` Medvedkin, Vladimir
0 siblings, 0 replies; 200+ results
From: Medvedkin, Vladimir @ 2022-05-27 13:16 UTC (permalink / raw)
To: Stanisław Kardach
Cc: Michal Mazurek, dev, Frank Zhao, Sam Grove, Marcin Wojtas,
upstream, Bruce Richardson
Hi Stanislaw,
On 27/05/2022 12:16, Stanisław Kardach wrote:
> On Tue, May 24, 2022 at 6:28 PM Stanisław Kardach <kda@semihalf.com> wrote:
> <snip>
>> That said I wonder why do we have different const requirements for
>> rte_lpm_lookup() and rte_lpm_lookupx4():
>> static inline int rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip,
>> uint32_t *next_hop)
>> static inline void rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t
>> ip, uint32_t hop[4], uint32_t defv);
>> I think both should be const.
>>
> To re-iterate the question, should I also post a patch for changing
> rte_lpm_lookup() to add "const" to "struct rte_lpm *lpm" argument?
> rte_lpm_lookup_bulk_func() and rte_lpm_lookupx4() already take lpm as
> const.
> I'm pushing because otherwise I get a const discard warning in the
> scalar version of rte_lpm_lookupx4() utilizing rte_lpm_lookup().
Since these are inline functions, there will be no problems with the
ABI/API, so please add const to the *lpm argument.
Thanks!
>
> Best Regards,
> Stanislaw Kardach
--
Regards,
Vladimir
^ permalink raw reply [relevance 3%]
* RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split
@ 2022-05-26 14:58 0% ` Ding, Xuan
0 siblings, 0 replies; 200+ results
From: Ding, Xuan @ 2022-05-26 14:58 UTC (permalink / raw)
To: Ding, Xuan, Thomas Monjalon, Wang, YuanX, Wu, WenxuanX
Cc: andrew.rybchenko, Li, Xiaoyun, ferruh.yigit, Singh, Aman Deep,
dev, Zhang, Yuying, Zhang, Qi Z, jerinjacobk, stephen, mb,
viacheslavo, Yu, Ping
Hi,
> -----Original Message-----
> From: Ding, Xuan <xuan.ding@intel.com>
> Sent: Thursday, May 19, 2022 10:40 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Wang, YuanX
> <yuanx.wang@intel.com>; Wu, WenxuanX <wenxuanx.wu@intel.com>
> Cc: andrew.rybchenko@oktetlabs.ru; Li, Xiaoyun <xiaoyun.li@intel.com>;
> ferruh.yigit@xilinx.com; Singh, Aman Deep <aman.deep.singh@intel.com>;
> dev@dpdk.org; Zhang, Yuying <yuying.zhang@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>; jerinjacobk@gmail.com;
> stephen@networkplumber.org; mb@smartsharesystems.com;
> viacheslavo@nvidia.com; Yu, Ping <ping.yu@intel.com>
> Subject: RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer
> split
>
> Hi Thomas,
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Wednesday, May 18, 2022 5:12 AM
> > To: Ding, Xuan <xuan.ding@intel.com>; Wang, YuanX
> > <yuanx.wang@intel.com>; Wu, WenxuanX <wenxuanx.wu@intel.com>
> > Cc: andrew.rybchenko@oktetlabs.ru; Li, Xiaoyun <xiaoyun.li@intel.com>;
> > ferruh.yigit@xilinx.com; Singh, Aman Deep <aman.deep.singh@intel.com>;
> > dev@dpdk.org; Zhang, Yuying <yuying.zhang@intel.com>; Zhang, Qi Z
> > <qi.z.zhang@intel.com>; jerinjacobk@gmail.com;
> > stephen@networkplumber.org; mb@smartsharesystems.com;
> > viacheslavo@nvidia.com; Yu, Ping <ping.yu@intel.com>
> > Subject: Re: [PATCH v5 1/4] lib/ethdev: introduce protocol type based
> > buffer split
> >
> > Hello,
> >
> > It seems you didn't try to address my main comment on v4:
> > "
> > Before doing anything, the first patch of this series should make the
> > current status clearer.
> > Example, this line does not explain what it does:
> > uint16_t split_hdr_size; /**< hdr buf size (header_split
> > enabled).*/ And header_split has been removed in ab3ce1e0c193
> > ("ethdev: remove old offload API")
> >
> > If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a
> comment
> > to start a deprecation.
> > "
>
> Thank you for the detailed review.
>
> First of all, I agree that header split should be deprecated.
> Since it is unrelated with buffer split, I was planning to send the deprecation
> notice in 22.07 sometime later and start the deprecation in 22.11.
>
> If you think it should be the first step, I will send the deprecation notice first.
>
> >
> > Also the comment from Andrew about removing limitation to 2 packets is
> > not addressed.
>
> Secondly, it is said that the protocol based buffer split will divide the packet
> into two segments.
> Because I thought it will only be used in the split between header and
> payload.
>
> In fact, protocol based buffer split can support multi-segment split.
> That is to say, like length-based buffer split, we define a series of protos, as
> the split point of protocol based buffer split. And this series of protos, like
> lengths, indicate the split location.
>
> For example, a packet consists of MAC/IPV4/UDP/payload.
> If we define the buffer split proto with IPV4, and UDP, the packet will be split
> into three segments:
> seg0: MAC and IPV4 header, 34 bytes
> seg1: UDP header, 8 bytes
> seg2: Payload, the actual payload size
>
> What do you think of this design?
>
> >
> > All the part about the protocols capability is missing here.
>
> Yes, I missed the protocols capability with RTE_PTYPE* now.
> I will update the doc with supported protocol capability in v6.
>
> >
> > It is not encouraging.
> >
> > 26/04/2022 13:13, wenxuanx.wu@intel.com:
> > > From: Wenxuan Wu <wenxuanx.wu@intel.com>
> > >
> > > Protocol based buffer split consists of splitting a received packet
> > > into two separate regions based on its content. The split happens
> > > after the packet protocol header and before the packet payload.
> > > Splitting is usually between the packet protocol header that can be
> > > posted to a dedicated buffer and the packet payload that can be
> > > posted to
> > a different buffer.
> > >
> > > Currently, Rx buffer split supports length and offset based packet split.
> > > protocol split is based on buffer split, configuring length of
> > > buffer split is not suitable for NICs that do split based on protocol types.
> >
> > Why? Is it impossible to support length split on Intel NIC?
>
> Yes, our NIC supports split based on protocol types. And I think there are
> other vendors too.
> The existence of tunneling results in the composition of a packet is various.
> Given a changeable length, it is impossible to tell the driver a fixed protocol
> type.
>
> >
> > > Because tunneling makes the conversion from length to protocol type
> > > impossible.
> >
> > This is not a HW issue.
> > I agree on the need but that a different usage than length split.
>
> I think the new usage can solve this problem, so that length split and proto
> split can have the same result.
>
> >
> > > This patch extends the current buffer split to support protocol and
> > > offset based buffer split. A new proto field is introduced in the
> > > rte_eth_rxseg_split structure reserved field to specify header
> > > protocol type. With Rx queue offload
> > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
> > > enabled and corresponding protocol type configured. PMD will split
> > > the
> > ingress packets into two separate regions.
> > > Currently, both inner and outer L2/L3/L4 level protocol based buffer
> > > split can be supported.
> > >
> > > For example, let's suppose we configured the Rx queue with the
> > > following segments:
> > > seg0 - pool0, off0=2B
> > > seg1 - pool1, off1=128B
> > >
> > > With protocol split type configured with RTE_PTYPE_L4_UDP. The
> > > packet consists of MAC_IP_UDP_PAYLOAD will be splitted like following:
> > > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from
> pool0
> > > seg1 - payload @ 128 in mbuf from pool1
> >
> > Not clear what is the calculation.
>
> The previous usage of protocol based split is the split between header and
> payload.
> Here for a packet composed of MAC_IP_UDP_PAYLOAD, with protocol split
> type RTE_PTYPE_L4_UDP configured, it means split between the UDP header
> and payload.
> In length configuration, the proto = RTE_PTYPE_L4_UDP means length = 42B.
>
> >
> > > The memory attributes for the split parts may differ either - for
> > > example the mempool0 and mempool1 belong to dpdk memory and
> > external
> > > memory, respectively.
> > >
> > > Signed-off-by: Xuan Ding <xuan.ding@intel.com>
> > > Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> > > Signed-off-by: Wenxuan Wu <wenxuanx.wu@intel.com>
> > > Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> > > ---
> > > lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++-------
> > > lib/ethdev/rte_ethdev.h | 15 ++++++++++++++-
> > > 2 files changed, 43 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index
> > > 29a3d80466..1a2bc172ab 100644
> > > --- a/lib/ethdev/rte_ethdev.c
> > > +++ b/lib/ethdev/rte_ethdev.c
> > > @@ -1661,6 +1661,7 @@ rte_eth_rx_queue_check_split(const struct
> > rte_eth_rxseg_split *rx_seg,
> > > struct rte_mempool *mpl = rx_seg[seg_idx].mp;
> > > uint32_t length = rx_seg[seg_idx].length;
> > > uint32_t offset = rx_seg[seg_idx].offset;
> > > + uint32_t proto = rx_seg[seg_idx].proto;
> > >
> > > if (mpl == NULL) {
> > > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n");
> > @@ -1694,13
> > > +1695,34 @@ rte_eth_rx_queue_check_split(const struct
> > rte_eth_rxseg_split *rx_seg,
> > > }
> > > offset += seg_idx != 0 ? 0 : RTE_PKTMBUF_HEADROOM;
> > > *mbp_buf_size = rte_pktmbuf_data_room_size(mpl);
> > > - length = length != 0 ? length : *mbp_buf_size;
> > > - if (*mbp_buf_size < length + offset) {
> > > - RTE_ETHDEV_LOG(ERR,
> > > - "%s mbuf_data_room_size %u < %u
> > (segment length=%u + segment offset=%u)\n",
> > > - mpl->name, *mbp_buf_size,
> > > - length + offset, length, offset);
> > > - return -EINVAL;
> > > + if (proto == 0) {
> >
> > Add a comment here, /* split at fixed length */
>
> Thanks for the suggestion, will add it in next version.
>
> >
> > > + length = length != 0 ? length : *mbp_buf_size;
> > > + if (*mbp_buf_size < length + offset) {
> > > + RTE_ETHDEV_LOG(ERR,
> > > + "%s mbuf_data_room_size %u < %u
> > (segment length=%u + segment offset=%u)\n",
> > > + mpl->name, *mbp_buf_size,
> > > + length + offset, length, offset);
> > > + return -EINVAL;
> > > + }
> > > + } else {
> >
> > Add a comment here, /* split after specified protocol header */
>
> Thanks for the suggestion, will add it in next version.
>
> >
> > > + /* Ensure n_seg is 2 in protocol based buffer split. */
> > > + if (n_seg != 2) {
> >
> > (should be a space, not a tab before brace)
>
> Get it.
>
> >
> > Why do you limit the feature to 2 segments only?
>
> Please see the new usage explained above.
>
> >
> > > + RTE_ETHDEV_LOG(ERR, "number of buffer
> > split protocol segments should be 2.\n");
> > > + return -EINVAL;
> > > + }
> > > + /* Length and protocol are exclusive here, so make
> > sure length is 0 in protocol
> > > + based buffer split. */
> > > + if (length != 0) {
> > > + RTE_ETHDEV_LOG(ERR, "segment length
> > should be set to zero in buffer split\n");
> > > + return -EINVAL;
> > > + }
> > > + if (*mbp_buf_size < offset) {
> > > + RTE_ETHDEV_LOG(ERR,
> > > + "%s
> > mbuf_data_room_size %u < %u segment offset)\n",
> > > + mpl->name, *mbp_buf_size,
> > > + offset);
> > > + return -EINVAL;
> > [...]
> > > + * - The proto in the elements defines the split position of received
> packets.
> > > + *
> > > * - If the length in the segment description element is zero
> > > * the actual buffer size will be deduced from the appropriate
> > > * memory pool properties.
> > > @@ -1197,12 +1200,21 @@ struct rte_eth_txmode {
> > > * - pool from the last valid element
> > > * - the buffer size from this pool
> > > * - zero offset
> > > + *
> > > + * - Length based buffer split:
> > > + * - mp, length, offset should be configured.
> > > + * - The proto should not be configured in length split. Zero default.
> > > + *
> > > + * - Protocol based buffer split:
> > > + * - mp, offset, proto should be configured.
> > > + * - The length should not be configured in protocol split. Zero default.
> >
> > What means "Zero default"?
> > You should just ignore the non relevant field.
>
> Yes, you are right, the none relevant field should be just ignored.
> I will update the doc in v6.
Sorry for replying myself.
After consideration, I found it is hard to just ignore the non-relevant field.
Because when length and proto both exist, it is hard to decide whether it is
length based buffer split or protocol based buffer split, which affects the
check in rte_eth_rx_queue_check_split().
So I would like to keep the current design in v6. When choosing one mode of
buffer split, the non-relevant field should not be configured.
Hope to get your feedbacks. :)
Regards,
Xuan
>
> >
> > > struct rte_eth_rxseg_split {
> > > struct rte_mempool *mp; /**< Memory pool to allocate segment
> > from. */
> > > uint16_t length; /**< Segment data length, configures split point. */
> > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer.
> > */
> > > - uint32_t reserved; /**< Reserved field. */
> >
> > How do you manage ABI compatibility?
> > Was the reserved field initialized to 0 in previous versions?
>
> I think we reached an agreement in RFC v1. There is no document for the
> reserved field in the previous release. And it is always initialized to zero in
> real cases.
> And now splitting based on fixed length and protocol header parsing is
> exclusive, we can ignore the none relevant field.
>
> >
> > > + uint32_t proto; /**< Protocol of buffer split, determines protocol
> > > +split point. */
> >
> > What are the values for "proto"?
>
> Yes, I missed the protocol capability here, will fix it in v6.
>
> >
> > > @@ -1664,6 +1676,7 @@ struct rte_eth_conf {
> > > RTE_ETH_RX_OFFLOAD_QINQ_STRIP) #define
> > DEV_RX_OFFLOAD_VLAN
> > > RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN)
> RTE_ETH_RX_OFFLOAD_VLAN
> > >
> > > +
> >
> > It looks to be an useless change.
>
> Thanks for the catch, will fix it in next version.
>
> Thanks again for your time.
>
> Regards,
> Xuan
>
> >
> > > /*
> > > * If new Rx offload capabilities are defined, they also must be
> > > * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> > >
> >
> >
> >
> >
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-26 10:18 0% ` Thomas Monjalon
@ 2022-05-26 11:02 0% ` Ray Kinsella
2022-06-01 15:04 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-05-26 11:02 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Tyler Retzlaff, dev, david.marchand, techboard, David Christensen
Thomas Monjalon <thomas@monjalon.net> writes:
> 25/05/2022 20:34, Tyler Retzlaff:
>> On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
>> > Thomas Monjalon <thomas@monjalon.net> writes:
>> > > 25/05/2022 13:48, Ray Kinsella:
>> > >> Thomas Monjalon <thomas@monjalon.net> writes:
>> > >>
>> > >> > The AltiVec header file is defining "vector", except in C++ build.
>> > >> > The keyword "vector" may conflict easily.
>> > >> > As a rule, it is better to use the alternative keyword "__vector".
>> > >> >
>> > >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
>> > >> > so the applications and dependencies are free to define the name "vector".
>> > >> >
>> > >> > This is a compatibility breakage for applications which were using
>> > >> > the keyword "vector" for its AltiVec meaning.
>> > >> >
>> > >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> > >> > ---
>> > >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
>> > >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
>> > >> > 2 files changed, 12 insertions(+)
>> > >> >
>> > >>
>> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
>> > >
>> > > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
>> > > It means the keyword vector is not available anymore with this #include.
>> > > Please confirm it is OK to merge in DPDK 22.07.
>> >
>> > I did think about it yes ;-).
>> > I can't see how it would break the ABI in the short term.
>> > And it makes sense to preclude this keyword in the long term.
>> >
>> > So I ack'ed - did I miss something?
>>
>> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>
>> double ack, impact of break is understood as follows.
>>
>> * this is not an issue with abi it is an issue with api.
>> * the break will cause a compile failure, the action to resolve is to
>> replace vector with __vector.
>
> Exactly
>
> I'll wait few days or acks from the techboard, and will apply.
+1
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-25 18:34 3% ` Tyler Retzlaff
@ 2022-05-26 10:18 0% ` Thomas Monjalon
2022-05-26 11:02 0% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-26 10:18 UTC (permalink / raw)
To: Ray Kinsella, Tyler Retzlaff
Cc: dev, david.marchand, techboard, David Christensen
25/05/2022 20:34, Tyler Retzlaff:
> On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
> > Thomas Monjalon <thomas@monjalon.net> writes:
> > > 25/05/2022 13:48, Ray Kinsella:
> > >> Thomas Monjalon <thomas@monjalon.net> writes:
> > >>
> > >> > The AltiVec header file is defining "vector", except in C++ build.
> > >> > The keyword "vector" may conflict easily.
> > >> > As a rule, it is better to use the alternative keyword "__vector".
> > >> >
> > >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
> > >> > so the applications and dependencies are free to define the name "vector".
> > >> >
> > >> > This is a compatibility breakage for applications which were using
> > >> > the keyword "vector" for its AltiVec meaning.
> > >> >
> > >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > >> > ---
> > >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> > >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
> > >> > 2 files changed, 12 insertions(+)
> > >> >
> > >>
> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> > >
> > > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> > > It means the keyword vector is not available anymore with this #include.
> > > Please confirm it is OK to merge in DPDK 22.07.
> >
> > I did think about it yes ;-).
> > I can't see how it would break the ABI in the short term.
> > And it makes sense to preclude this keyword in the long term.
> >
> > So I ack'ed - did I miss something?
>
> Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>
> double ack, impact of break is understood as follows.
>
> * this is not an issue with abi it is an issue with api.
> * the break will cause a compile failure, the action to resolve is to
> replace vector with __vector.
Exactly
I'll wait few days or acks from the techboard, and will apply.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
2022-05-25 18:02 3% ` Ray Kinsella
@ 2022-05-25 18:34 3% ` Tyler Retzlaff
2022-05-26 10:18 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-05-25 18:34 UTC (permalink / raw)
To: Ray Kinsella
Cc: Thomas Monjalon, dev, david.marchand, techboard, David Christensen
On Wed, May 25, 2022 at 07:02:52PM +0100, Ray Kinsella wrote:
>
> Thomas Monjalon <thomas@monjalon.net> writes:
>
> > 25/05/2022 13:48, Ray Kinsella:
> >>
> >> Thomas Monjalon <thomas@monjalon.net> writes:
> >>
> >> > The AltiVec header file is defining "vector", except in C++ build.
> >> > The keyword "vector" may conflict easily.
> >> > As a rule, it is better to use the alternative keyword "__vector".
> >> >
> >> > The DPDK header file rte_altivec.h takes care of undefining "vector",
> >> > so the applications and dependencies are free to define the name "vector".
> >> >
> >> > This is a compatibility breakage for applications which were using
> >> > the keyword "vector" for its AltiVec meaning.
> >> >
> >> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >> > ---
> >> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> >> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
> >> > 2 files changed, 12 insertions(+)
> >> >
> >>
> >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> >
> > Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> > It means the keyword vector is not available anymore with this #include.
> > Please confirm it is OK to merge in DPDK 22.07.
>
> I did think about it yes ;-).
> I can't see how it would break the ABI in the short term.
> And it makes sense to preclude this keyword in the long term.
>
> So I ack'ed - did I miss something?
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
double ack, impact of break is understood as follows.
* this is not an issue with abi it is an issue with api.
* the break will cause a compile failure, the action to resolve is to
replace vector with __vector.
>
>
> --
> Regards, Ray K
^ permalink raw reply [relevance 3%]
* Re: [PATCH] eal/ppc: undefine AltiVec keyword vector
@ 2022-05-25 18:02 3% ` Ray Kinsella
2022-05-25 18:34 3% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-05-25 18:02 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, david.marchand, techboard, David Christensen
Thomas Monjalon <thomas@monjalon.net> writes:
> 25/05/2022 13:48, Ray Kinsella:
>>
>> Thomas Monjalon <thomas@monjalon.net> writes:
>>
>> > The AltiVec header file is defining "vector", except in C++ build.
>> > The keyword "vector" may conflict easily.
>> > As a rule, it is better to use the alternative keyword "__vector".
>> >
>> > The DPDK header file rte_altivec.h takes care of undefining "vector",
>> > so the applications and dependencies are free to define the name "vector".
>> >
>> > This is a compatibility breakage for applications which were using
>> > the keyword "vector" for its AltiVec meaning.
>> >
>> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> > ---
>> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
>> > lib/eal/ppc/include/rte_altivec.h | 7 +++++++
>> > 2 files changed, 12 insertions(+)
>> >
>>
>> Acked-by: Ray Kinsella <mdr@ashroe.eu>
>
> Just to make sure, we are all OK to break compatibility of rte_altivec.h?
> It means the keyword vector is not available anymore with this #include.
> Please confirm it is OK to merge in DPDK 22.07.
I did think about it yes ;-).
I can't see how it would break the ABI in the short term.
And it makes sense to preclude this keyword in the long term.
So I ack'ed - did I miss something?
--
Regards, Ray K
^ permalink raw reply [relevance 3%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-25 13:58 3% ` Thomas Monjalon
@ 2022-05-25 14:23 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2022-05-25 14:23 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit
On 5/25/22 16:58, Thomas Monjalon wrote:
> 25/05/2022 14:59, Andrew Rybchenko:
>> On 5/24/22 11:18, Thomas Monjalon wrote:
>>> 24/05/2022 04:50, Spike Du:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 23/05/2022 05:01, Spike Du:
>>>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>>>> Spike Du <spiked@nvidia.com> wrote:
>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
>>>>>>>> */
>>>>>>>> union rte_eth_rxseg *rx_seg;
>>>>>>>>
>>>>>>>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
>>>>>>>> + /**
>>>>>>>> + * Per-queue Rx limit watermark defined as percentage of Rx queue
>>>>>>>> + * size. If Rx queue receives traffic higher than this percentage,
>>>>>>>> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
>>>>>>>> + */
>>>>>>>> + uint8_t lwm;
>>>>>>>> +
>>>>>>>> + uint8_t reserved_bits[3];
>>>>>>>> + uint32_t reserved_32s;
>>>>>>>> + uint64_t reserved_64s;
>>>>>>>
>>>>>>> Ok but, this is an ABI risk about this because reserved stuff was
>>>>>>> never required before.
>>>>>
>>>>> An ABI compatibility issue would be for an application compiled with an old
>>>>> DPDK, and loading a new DPDK at runtime.
>>>>> Let's think what would happen in such a case.
>>>>>
>>>>>>> Whenever is a reserved field is introduced the code (in this case
>>>>>>> rte_ethdev_configure).
>>>>>
>>>>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
>>>>> Then the library and drivers may interpret a wrong value.
>>>>>
>>>>>>> Best practice would have been to have the code require all reserved
>>>>>>> fields be
>>>>>>> 0 in earlier releases. In this case an application is like to define
>>>>>>> a watermark of zero; how will your code handle it.
>>>>>>
>>>>>> Having watermark of 0 is desired, which is the default. LWM of 0 means
>>>>>> the Rx Queue's watermark is not monitored, hence no LWM event is
>>>>> generated.
>>>>>
>>>>> The problem is to have a value not initialized.
>>>>> I think the best approach is to not expose the LWM value through this
>>>>> configuration structure.
>>>>> If the need is to get the current value, we should better add a field in the
>>>>> struct rte_eth_rxq_info.
>>>>
>>>> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
>>>> The Rx queue, if user follows these examples we should not have ABI issue.
>>>> Since many people are concerned about rxconf change, it's ok to remove the LWM
>>>> Field there.
>>>> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
>>>> We should have a way to get it.
>>>
>>> Unfortunately we cannot rely on examples for ABI compatibility.
>>> My suggestion of moving the field in rte_eth_rxq_info
>>> is not obvious because it could change the size of the struct.
>>> But thanks to __rte_cache_min_aligned, it is OK.
>>> Running pahole on this struct shows we have 50 bytes free:
>>> /* size: 128, cachelines: 2, members: 6 */
>>> /* padding: 50 */
>>>
>>> The other option would be to get the LWM value with a "get" function.
>>>
>>> What others prefer?
>>
>> If I'm not mistaken the changeset breaks ABI in any case since
>> it adds a new event and changes MAX.
>
> I think we can consider it as not a breakage (a rule should be added).
> Last time we had to update this enum, this was the conclusion:
> from https://git.dpdk.org/dpdk/commit/?id=44bf3c796be3f
> "
> The new event type addition in the enum is flagged as an ABI breakage,
> so an ignore rule is added for these reasons:
> - It is not changing value of existing types (except MAX)
> - The new value is not used by existing API if the event is not
> registered
> In general, it is safe adding new ethdev event types at the end of the
> enum, because of event callback registration mechanism.
> "
I see. Makes sense. Thanks for the information.
>> If so, I'd wait for the
>> next ABI breaking release and do not touch reserved fields.
>
> In any case, rte_eth_rxconf is not a good fit
> because we have a separate function for configuration.
Yes, it is better to avoid two ways to configure the same
thing.
> It should be either in rte_eth_rxq_info or a specific "get" function.
I see no point to introduce specific get function for a single
value. I think that rte_eth_rxq_info is the right way to get
current value.
^ permalink raw reply [relevance 0%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-25 12:59 4% ` Andrew Rybchenko
@ 2022-05-25 13:58 3% ` Thomas Monjalon
2022-05-25 14:23 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-25 13:58 UTC (permalink / raw)
To: Stephen Hemminger, Spike Du, Andrew Rybchenko
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit
25/05/2022 14:59, Andrew Rybchenko:
> On 5/24/22 11:18, Thomas Monjalon wrote:
> > 24/05/2022 04:50, Spike Du:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 23/05/2022 05:01, Spike Du:
> >>>> From: Stephen Hemminger <stephen@networkplumber.org>
> >>>>> Spike Du <spiked@nvidia.com> wrote:
> >>>>>> --- a/lib/ethdev/rte_ethdev.h
> >>>>>> +++ b/lib/ethdev/rte_ethdev.h
> >>>>>> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> >>>>>> */
> >>>>>> union rte_eth_rxseg *rx_seg;
> >>>>>>
> >>>>>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> >>>>>> + /**
> >>>>>> + * Per-queue Rx limit watermark defined as percentage of Rx queue
> >>>>>> + * size. If Rx queue receives traffic higher than this percentage,
> >>>>>> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> >>>>>> + */
> >>>>>> + uint8_t lwm;
> >>>>>> +
> >>>>>> + uint8_t reserved_bits[3];
> >>>>>> + uint32_t reserved_32s;
> >>>>>> + uint64_t reserved_64s;
> >>>>>
> >>>>> Ok but, this is an ABI risk about this because reserved stuff was
> >>>>> never required before.
> >>>
> >>> An ABI compatibility issue would be for an application compiled with an old
> >>> DPDK, and loading a new DPDK at runtime.
> >>> Let's think what would happen in such a case.
> >>>
> >>>>> Whenever is a reserved field is introduced the code (in this case
> >>>>> rte_ethdev_configure).
> >>>
> >>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> >>> Then the library and drivers may interpret a wrong value.
> >>>
> >>>>> Best practice would have been to have the code require all reserved
> >>>>> fields be
> >>>>> 0 in earlier releases. In this case an application is like to define
> >>>>> a watermark of zero; how will your code handle it.
> >>>>
> >>>> Having watermark of 0 is desired, which is the default. LWM of 0 means
> >>>> the Rx Queue's watermark is not monitored, hence no LWM event is
> >>> generated.
> >>>
> >>> The problem is to have a value not initialized.
> >>> I think the best approach is to not expose the LWM value through this
> >>> configuration structure.
> >>> If the need is to get the current value, we should better add a field in the
> >>> struct rte_eth_rxq_info.
> >>
> >> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
> >> The Rx queue, if user follows these examples we should not have ABI issue.
> >> Since many people are concerned about rxconf change, it's ok to remove the LWM
> >> Field there.
> >> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
> >> We should have a way to get it.
> >
> > Unfortunately we cannot rely on examples for ABI compatibility.
> > My suggestion of moving the field in rte_eth_rxq_info
> > is not obvious because it could change the size of the struct.
> > But thanks to __rte_cache_min_aligned, it is OK.
> > Running pahole on this struct shows we have 50 bytes free:
> > /* size: 128, cachelines: 2, members: 6 */
> > /* padding: 50 */
> >
> > The other option would be to get the LWM value with a "get" function.
> >
> > What others prefer?
>
> If I'm not mistaken the changeset breaks ABI in any case since
> it adds a new event and changes MAX.
I think we can consider it as not a breakage (a rule should be added).
Last time we had to update this enum, this was the conclusion:
from https://git.dpdk.org/dpdk/commit/?id=44bf3c796be3f
"
The new event type addition in the enum is flagged as an ABI breakage,
so an ignore rule is added for these reasons:
- It is not changing value of existing types (except MAX)
- The new value is not used by existing API if the event is not
registered
In general, it is safe adding new ethdev event types at the end of the
enum, because of event callback registration mechanism.
"
> If so, I'd wait for the
> next ABI breaking release and do not touch reserved fields.
In any case, rte_eth_rxconf is not a good fit
because we have a separate function for configuration.
It should be either in rte_eth_rxq_info or a specific "get" function.
^ permalink raw reply [relevance 3%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-24 8:18 3% ` Thomas Monjalon
@ 2022-05-25 12:59 4% ` Andrew Rybchenko
2022-05-25 13:58 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2022-05-25 12:59 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit
On 5/24/22 11:18, Thomas Monjalon wrote:
> 24/05/2022 04:50, Spike Du:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 23/05/2022 05:01, Spike Du:
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>> Spike Du <spiked@nvidia.com> wrote:
>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>> @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
>>>>>> */
>>>>>> union rte_eth_rxseg *rx_seg;
>>>>>>
>>>>>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
>>>>>> + /**
>>>>>> + * Per-queue Rx limit watermark defined as percentage of Rx queue
>>>>>> + * size. If Rx queue receives traffic higher than this percentage,
>>>>>> + * the event RTE_ETH_EVENT_RX_LWM is triggered.
>>>>>> + */
>>>>>> + uint8_t lwm;
>>>>>> +
>>>>>> + uint8_t reserved_bits[3];
>>>>>> + uint32_t reserved_32s;
>>>>>> + uint64_t reserved_64s;
>>>>>
>>>>> Ok but, this is an ABI risk about this because reserved stuff was
>>>>> never required before.
>>>
>>> An ABI compatibility issue would be for an application compiled with an old
>>> DPDK, and loading a new DPDK at runtime.
>>> Let's think what would happen in such a case.
>>>
>>>>> Whenever is a reserved field is introduced the code (in this case
>>>>> rte_ethdev_configure).
>>>
>>> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
>>> Then the library and drivers may interpret a wrong value.
>>>
>>>>> Best practice would have been to have the code require all reserved
>>>>> fields be
>>>>> 0 in earlier releases. In this case an application is like to define
>>>>> a watermark of zero; how will your code handle it.
>>>>
>>>> Having watermark of 0 is desired, which is the default. LWM of 0 means
>>>> the Rx Queue's watermark is not monitored, hence no LWM event is
>>> generated.
>>>
>>> The problem is to have a value not initialized.
>>> I think the best approach is to not expose the LWM value through this
>>> configuration structure.
>>> If the need is to get the current value, we should better add a field in the
>>> struct rte_eth_rxq_info.
>>
>> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
>> The Rx queue, if user follows these examples we should not have ABI issue.
>> Since many people are concerned about rxconf change, it's ok to remove the LWM
>> Field there.
>> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
>> We should have a way to get it.
>
> Unfortunately we cannot rely on examples for ABI compatibility.
> My suggestion of moving the field in rte_eth_rxq_info
> is not obvious because it could change the size of the struct.
> But thanks to __rte_cache_min_aligned, it is OK.
> Running pahole on this struct shows we have 50 bytes free:
> /* size: 128, cachelines: 2, members: 6 */
> /* padding: 50 */
>
> The other option would be to get the LWM value with a "get" function.
>
> What others prefer?
If I'm not mistaken the changeset breaks ABI in any case since
it adds a new event and changes MAX. If so, I'd wait for the
next ABI breaking release and do not touch reserved fields.
^ permalink raw reply [relevance 4%]
* [PATCH] eal/ppc: undefine AltiVec keyword vector
@ 2022-05-25 9:53 4% Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-25 9:53 UTC (permalink / raw)
To: dev; +Cc: mdr, david.marchand, techboard, David Christensen
The AltiVec header file is defining "vector", except in C++ build.
The keyword "vector" may conflict easily.
As a rule, it is better to use the alternative keyword "__vector".
The DPDK header file rte_altivec.h takes care of undefining "vector",
so the applications and dependencies are free to define the name "vector".
This is a compatibility breakage for applications which were using
the keyword "vector" for its AltiVec meaning.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/release_22_07.rst | 5 +++++
lib/eal/ppc/include/rte_altivec.h | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst
index e49cacecef..ee60b17821 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -133,6 +133,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* The DPDK header file ``rte_altivec.h``,
+ which is a wrapper for the PPC header file ``altivec.h``,
+ undefines the AltiVec keyword ``vector``.
+ The alternative keyword ``__vector`` should be used instead.
+
ABI Changes
-----------
diff --git a/lib/eal/ppc/include/rte_altivec.h b/lib/eal/ppc/include/rte_altivec.h
index 1551a94544..7c088d2d16 100644
--- a/lib/eal/ppc/include/rte_altivec.h
+++ b/lib/eal/ppc/include/rte_altivec.h
@@ -9,6 +9,13 @@
/* To include altivec.h, GCC version must be >= 4.8 */
#include <altivec.h>
+/*
+ * The keyword "vector" is defined in altivec.h,
+ * and often conflicts with code in applications or dependencies.
+ * It is preferred to use the alternative keyword "__vector".
+ */
+#undef vector
+
/*
* Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. std=c11.
* Otherwise there would be a type conflict between stdbool and altivec.
--
2.36.0
^ permalink raw reply [relevance 4%]
* RE: [RFT 0/2] pie: floating point fixes
2022-05-24 18:46 3% [RFT 0/2] pie: floating point fixes Stephen Hemminger
@ 2022-05-24 19:31 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-05-24 19:31 UTC (permalink / raw)
To: Stephen Hemminger, dev
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 24 May 2022 20.46
>
> A couple of small untested changes to address some
> issues found while reviewing usage of random in DPDK.
>
> The PIE code should get rexamined in later release.
Untested fixes to seemingly untested code. What's not to like? ;-)
> It should not be exposing internal algorithm, that makes
> it brittle for ABI.
Agree. Just look at the mempool... an increasing amount of its internals are getting elevated to public API, so other code can understand and use its internals instead of going through its API. (My current pet peeve.)
>
> Also, no code in DPDK should ever be doing floating point
> math in the data path!
+1
>
> Stephen Hemminger (2):
> rte_pie: remove unnecessary floating point
> rte_pie: fix incorrect floating point math
This looks much better than what it replaces, so...
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 0%]
* [RFT 0/2] pie: floating point fixes
@ 2022-05-24 18:46 3% Stephen Hemminger
2022-05-24 19:31 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-05-24 18:46 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
A couple of small untested changes to address some
issues found while reviewing usage of random in DPDK.
The PIE code should get rexamined in later release.
It should not be exposing internal algorithm, that makes
it brittle for ABI.
Also, no code in DPDK should ever be doing floating point
math in the data path!
Stephen Hemminger (2):
rte_pie: remove unnecessary floating point
rte_pie: fix incorrect floating point math
lib/sched/rte_pie.h | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--
2.35.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events
@ 2022-05-24 15:11 0% ` Ray Kinsella
2022-06-10 0:16 0% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2022-05-24 15:11 UTC (permalink / raw)
To: fengchengwen
Cc: Thomas Monjalon, Ferruh Yigit, Kalesh A P, dev, ajit.khaparde,
asafp, David Marchand, Andrew Rybchenko, lizhenyi1,
shuliubin 00419723
fengchengwen <fengchengwen@huawei.com> writes:
> Hi all,
>
> This patch lasts for a long time. Are we waiting for 22.11 to deal with it?
That was my read, as can't reliably change the value of _MAX at this
stage without it having impact elsewhere.
> We have the same requirements for the reset or recovery mechanism, but there are differences:
>
> APP PMD
> | |
> | detect error
> | <---report error event--- |
> | |
> do error stats |
> and report |
> | ---start recover--> |
> | do recover
> | <---report recover result |
> | |
> if succ just log
> else may migrate
> service
>
> Can we generalize these processes(means that the implementation is at the framework layer)? or only at PMD API?
>
>
> On 2022/2/15 0:06, Ray Kinsella wrote:
>>
>> Thomas Monjalon <thomas@monjalon.net> writes:
>>
>>> 14/02/2022 11:16, Ray Kinsella:
>>>> Ray Kinsella <mdr@ashroe.eu> writes:
>>>>> Thomas Monjalon <thomas@monjalon.net> writes:
>>>>>> 02/02/2022 12:44, Ray Kinsella:
>>>>>>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>>>>>>> On 1/28/2022 12:48 PM, Kalesh A P wrote:
>>>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>>>> @@ -3818,6 +3818,24 @@ enum rte_eth_event_type {
>>>>>>>>> RTE_ETH_EVENT_DESTROY, /**< port is released */
>>>>>>>>> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */
>>>>>>>>> RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */
>>>>>>>>> + RTE_ETH_EVENT_ERR_RECOVERING,
>>>>>>>>> + /**< port recovering from an error
>>>>>>>>> + *
>>>>>>>>> + * PMD detected a FW reset or error condition.
>>>>>>>>> + * PMD will try to recover from the error.
>>>>>>>>> + * Data path may be quiesced and Control path operations
>>>>>>>>> + * may fail at this time.
>>>>>>>>> + */
>>>>>>>>> + RTE_ETH_EVENT_RECOVERED,
>>>>>>>>> + /**< port recovered from an error
>>>>>>>>> + *
>>>>>>>>> + * PMD has recovered from the error condition.
>>>>>>>>> + * Control path and Data path are up now.
>>>>>>>>> + * PMD re-configures the port to the state prior to the error.
>>>>>>>>> + * Since the device has undergone a reset, flow rules
>>>>>>>>> + * offloaded prior to reset may be lost and
>>>>>>>>> + * the application should recreate the rules again.
>>>>>>>>> + */
>>>>>>>>> RTE_ETH_EVENT_MAX /**< max value of this enum */
>>>>>>>>
>>>>>>>>
>>>>>>>> Also ABI check complains about 'RTE_ETH_EVENT_MAX' value check, cc'ed more people
>>>>>>>> to evaluate if it is a false positive:
>>>>>>>>
>>>>>>>>
>>>>>>>> 1 function with some indirect sub-type change:
>>>>>>>> [C] 'function int rte_eth_dev_callback_register(uint16_t, rte_eth_event_type, rte_eth_dev_cb_fn, void*)' at rte_ethdev.c:4637:1 has some indirect sub-type changes:
>>>>>>>> parameter 3 of type 'typedef rte_eth_dev_cb_fn' has sub-type changes:
>>>>>>>> underlying type 'int (typedef uint16_t, enum rte_eth_event_type, void*, void*)*' changed:
>>>>>>>> in pointed to type 'function type int (typedef uint16_t, enum rte_eth_event_type, void*, void*)':
>>>>>>>> parameter 2 of type 'enum rte_eth_event_type' has sub-type changes:
>>>>>>>> type size hasn't changed
>>>>>>>> 2 enumerator insertions:
>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_ERR_RECOVERING' value '11'
>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_RECOVERED' value '12'
>>>>>>>> 1 enumerator change:
>>>>>>>> 'rte_eth_event_type::RTE_ETH_EVENT_MAX' from value '11' to '13' at rte_ethdev.h:3807:1
>>>>>>>
>>>>>>> I don't immediately see the problem that this would cause.
>>>>>>> There are no array sizes etc dependent on the value of MAX for instance.
>>>>>>>
>>>>>>> Looks safe?
>>>>>>
>>>>>> We never know how this enum will be used by the application.
>>>>>> The max value may be used for the size of an event array.
>>>>>> It looks a real ABI issue unfortunately.
>>>>>
>>>>> Right - but we only really care about it when an array size based on MAX
>>>>> is likely to be passed to DPDK, which doesn't apply in this case.
>>>
>>> I don't completely agree.
>>> A developer may assume an event will never exceed MAX value.
>>> However, after an upgrade of DPDK without app rebuild,
>>> a higher event value may be received in the app,
>>> breaking the assumption.
>>> Should we consider this case as an ABI breakage?
>>
>> Nope - I think we should explicitly exclude MAX values from any
>> ABI guarantee, as being able to change them is key to our be able to
>> evolve DPDK while maintaining ABI stability.
>>
>> Consider what it means applying the ABI policy to a MAX value, you are
>> in effect saying that that no value can be added to this enumeration
>> until the next ABI version, for me this is very restrictive without a
>> solid reason.
>>
>>>
>>>>> I noted that some Linux folks explicitly mark similar MAX values as not
>>>>> part of the ABI.
>>>>>
>>>>> /usr/include/linux/perf_event.h
>>>>> 37: PERF_TYPE_MAX, /* non-ABI */
>>>>> 60: PERF_COUNT_HW_MAX, /* non-ABI */
>>>>> 79: PERF_COUNT_HW_CACHE_MAX, /* non-ABI */
>>>>> 87: PERF_COUNT_HW_CACHE_OP_MAX, /* non-ABI */
>>>>> 94: PERF_COUNT_HW_CACHE_RESULT_MAX, /* non-ABI */
>>>>> 116: PERF_COUNT_SW_MAX, /* non-ABI */
>>>>> 149: PERF_SAMPLE_MAX = 1U << 24, /* non-ABI */
>>>>> 151: __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /*
>>>>> non-ABI; internal use */
>>>>> 189: PERF_SAMPLE_BRANCH_MAX_SHIFT /* non-ABI */
>>>>> 267: PERF_TXN_MAX = (1 << 8), /* non-ABI */
>>>>> 301: PERF_FORMAT_MAX = 1U << 4, /* non-ABI */
>>>>> 1067: PERF_RECORD_MAX, /* non-ABI */
>>>>> 1078: PERF_RECORD_KSYMBOL_TYPE_MAX /* non-ABI */
>>>>> 1087: PERF_BPF_EVENT_MAX, /* non-ABI */
>>>>
>>>> Any thoughts on similarly annotating all our _MAX enums in the same way?
>>>> We could also add a section in the ABI Policy to make it explicit _MAX
>>>> enum values are not part of the ABI - what do folks think?
>>>
>>> Interesting. I am not sure it is always ABI-safe though.
>>
>>
--
Regards, Ray K
^ permalink raw reply [relevance 0%]
* Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
2022-05-24 2:50 3% ` Spike Du
@ 2022-05-24 8:18 3% ` Thomas Monjalon
2022-05-25 12:59 4% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-05-24 8:18 UTC (permalink / raw)
To: Stephen Hemminger, Spike Du
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit, andrew.rybchenko
24/05/2022 04:50, Spike Du:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 23/05/2022 05:01, Spike Du:
> > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > > Spike Du <spiked@nvidia.com> wrote:
> > > > > --- a/lib/ethdev/rte_ethdev.h
> > > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > > > */
> > > > > union rte_eth_rxseg *rx_seg;
> > > > >
> > > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > > > + /**
> > > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > > > + * size. If Rx queue receives traffic higher than this percentage,
> > > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > > > + */
> > > > > + uint8_t lwm;
> > > > > +
> > > > > + uint8_t reserved_bits[3];
> > > > > + uint32_t reserved_32s;
> > > > > + uint64_t reserved_64s;
> > > >
> > > > Ok but, this is an ABI risk about this because reserved stuff was
> > > > never required before.
> >
> > An ABI compatibility issue would be for an application compiled with an old
> > DPDK, and loading a new DPDK at runtime.
> > Let's think what would happen in such a case.
> >
> > > > Whenever is a reserved field is introduced the code (in this case
> > > > rte_ethdev_configure).
> >
> > rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> > Then the library and drivers may interpret a wrong value.
> >
> > > > Best practice would have been to have the code require all reserved
> > > > fields be
> > > > 0 in earlier releases. In this case an application is like to define
> > > > a watermark of zero; how will your code handle it.
> > >
> > > Having watermark of 0 is desired, which is the default. LWM of 0 means
> > > the Rx Queue's watermark is not monitored, hence no LWM event is
> > generated.
> >
> > The problem is to have a value not initialized.
> > I think the best approach is to not expose the LWM value through this
> > configuration structure.
> > If the need is to get the current value, we should better add a field in the
> > struct rte_eth_rxq_info.
>
> At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
> The Rx queue, if user follows these examples we should not have ABI issue.
> Since many people are concerned about rxconf change, it's ok to remove the LWM
> Field there.
> Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
> We should have a way to get it.
Unfortunately we cannot rely on examples for ABI compatibility.
My suggestion of moving the field in rte_eth_rxq_info
is not obvious because it could change the size of the struct.
But thanks to __rte_cache_min_aligned, it is OK.
Running pahole on this struct shows we have 50 bytes free:
/* size: 128, cachelines: 2, members: 6 */
/* padding: 50 */
The other option would be to get the LWM value with a "get" function.
What others prefer?
^ permalink raw reply [relevance 3%]
* RE: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
@ 2022-05-24 3:46 0% ` Spike Du
0 siblings, 0 replies; 200+ results
From: Spike Du @ 2022-05-24 3:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
dev, Raslan Darawsheh
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, May 24, 2022 6:55 AM
> To: Spike Du <spiked@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dev@dpdk.org;
> Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
>
> External email: Use caution opening links or attachments
>
>
> On Mon, 23 May 2022 03:01:20 +0000
> Spike Du <spiked@nvidia.com> wrote:
>
> > Hi, pls see below.
> >
> > > -----Original Message-----
> > > From: Stephen Hemminger <stephen@networkplumber.org>
> > > Sent: Sunday, May 22, 2022 11:23 PM
> > > To: Spike Du <spiked@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dev@dpdk.org;
> > > Raslan Darawsheh <rasland@nvidia.com>
> > > Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit
> > > watermark
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Sun, 22 May 2022 08:58:56 +0300
> > > Spike Du <spiked@nvidia.com> wrote:
> > >
> > > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> > > > index
> > > > 04cff8ee10..687ae5ff29 100644
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > > */
> > > > union rte_eth_rxseg *rx_seg;
> > > >
> > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > > + /**
> > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > > + * size. If Rx queue receives traffic higher than this percentage,
> > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > > + */
> > > > + uint8_t lwm;
> > > > +
> > > > + uint8_t reserved_bits[3];
> > > > + uint32_t reserved_32s;
> > > > + uint64_t reserved_64s;
> > > > void *reserved_ptrs[2]; /**< Reserved for future fields */
> > > > };
> > > >
> > >
> > > Ok but, this is an ABI risk about this because reserved stuff was
> > > never required before.
> > > Whenever is a reserved field is introduced the code (in this case
> > > rte_ethdev_configure).
> > >
> > > Best practice would have been to have the code require all reserved
> > > fields be
> > > 0 in earlier releases. In this case an application is like to define
> > > a watermark of zero; how will your code handle it.
> > Having watermark of 0 is desired, which is the default. LWM of 0 means
> > the Rx Queue's watermark is not monitored, hence no LWM event is
> generated.
> > >
> > > Also, using 8 bits as percentage is different than how other API's handle
> this.
> > > Since Rx queue size is in packets, why is this not in packets?
> > The short answer is to simply the LWM configuration.
> > Rx queue descriptor is complex nowadays.
> > For normal queue, user may configure LWM according to queue descriptor
> number easily.
> > But for below queues, it's not easy:
> > Take mprq as example, the testpmd cmd options can be " -a
> >
> 0000:03:00.0,rxqs_min_mprq=1,mprq_en=1,mprq_max_memcpy_len=465,
> mprq_lo
> > g_stride_size=8,mprq_log_stride_num=3
> > -- --mbcache=512 -i --nb-cores=7 --txd=1024 --rxd=1024 ", For MLX5
> > implementation, the minimum "unit" in queue has 64 descriptors, the
> > "unit" number is 16, if you configure according to descriptor number(1024)
> Here, you may easily set LWM as something like 512, but HW doesn't allow it,
> because 512 > 16. If you want the watermark to be half, the correct value is 8.
> > The same issue happens to feature like "Rx queue buffer split" where a
> packet can be split to multiple descriptors.
> > Using percentage doesn't have such issues, PMD will cover all the details.
> >
> > > Also document what behavior of 0 is.
> > Sure. The behavior is like the old days without this feature, pls see above.
> >
> > > Why introduce new query/set operations? This should just be part of
> > > the overall device configuration.
> > Due to different implementation. LWM can be a dynamic configuration
> which can help user design a flexible flow control.
> > User may feel ok with LWM of 80% to get high throughput, or later on with
> 50% to throttle the traffic responsively by handling LWM event in order to
> reduce drop.
> > Some driver like mlx5 may implement LWM event as one-time shot. When
> > you receive LWM event, you need to reconfigure LWM in order to receive
> the event again, thus you will not likely to be overwhelmed by the events.
> > These all require set operation.
> >
> > For the query operation. The rte_event API
> rte_eth_dev_callback_process() is per-port API, it doesn't carry much
> information when an event happens.
> > When a LWM event happens, we need to know in which Rx queue it
> happens or optionally what's the current LWM percentage of this queue.
> > The query operation serves this purpose.
> >
> >
> > Regards,
> > Spike.
> >
> >
>
> The bigger question is why does this have to be just MLX5 and why can't it fit
> into the existing DPDK RX interrupt framework?
>
> Linux and BSD have had this for years in their packet coalescing logic.
> Ethtool provides ability to set lot of irq coalescing parameters like:
>
> ethtool -C|--coalesce devname [adaptive-rx on|off] [adaptive-tx on|off]
> [rx-usecs N] [rx-frames N] [rx-usecs-irq N] [rx-frames-irq N]
> [tx-usecs N] [tx-frames N] [tx-usecs-irq N] [tx-frames-irq N]
> [stats-block-usecs N] [pkt-rate-low N] [rx-usecs-low N]
> [rx-frames-low N] [tx-usecs-low N] [tx-frames-low N]
> [pkt-rate-high N] [rx-usecs-high N] [rx-frames-high N]
> [tx-usecs-high N] [tx-frames-high N] [sample-interval N]
> [cqe-mode-rx on|off] [cqe-mode-tx on|off]
>
> It feels like this is just the DPDK version of a small subset of that.
> Since many device already support IRQ coalescing, it would be best to build
> one new API that has most of these. Rather than a MLX/Nvidia only API for a
> single parameter.
I take MLX5 as example here because I only know how mlx5 works, I don't understand
How other NICs work. It doesn't mean I try to change common code only to satisfy
Mlx5 needs.
I think interrupt coalesce is different from LWM:
Interrupt coalesce is delay interrupt until a batch of packets(or an interval) is received.
LWM intends to notify when a Rx queue is out of buffer. Delaying interrupt can't detect
A specific fullness value of the Rx queue, but LWM can if driver supports it.
Regards,
Spike.
^ permalink raw reply [relevance 0%]
* RE: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
@ 2022-05-24 2:50 3% ` Spike Du
2022-05-24 8:18 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Spike Du @ 2022-05-24 2:50 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL), Stephen Hemminger
Cc: dev, Matan Azrad, Slava Ovsiienko, Ori Kam, Raslan Darawsheh,
ferruh.yigit, andrew.rybchenko
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, May 24, 2022 5:46 AM
> To: Stephen Hemminger <stephen@networkplumber.org>; Spike Du
> <spiked@nvidia.com>
> Cc: dev@dpdk.org; Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; Raslan Darawsheh
> <rasland@nvidia.com>; ferruh.yigit@amd.com;
> andrew.rybchenko@oktetlabs.ru
> Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
>
> External email: Use caution opening links or attachments
>
>
> 23/05/2022 05:01, Spike Du:
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > > Spike Du <spiked@nvidia.com> wrote:
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf {
> > > > */
> > > > union rte_eth_rxseg *rx_seg;
> > > >
> > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > > > + /**
> > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue
> > > > + * size. If Rx queue receives traffic higher than this percentage,
> > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered.
> > > > + */
> > > > + uint8_t lwm;
> > > > +
> > > > + uint8_t reserved_bits[3];
> > > > + uint32_t reserved_32s;
> > > > + uint64_t reserved_64s;
> > >
> > > Ok but, this is an ABI risk about this because reserved stuff was
> > > never required before.
>
> An ABI compatibility issue would be for an application compiled with an old
> DPDK, and loading a new DPDK at runtime.
> Let's think what would happen in such a case.
>
> > > Whenever is a reserved field is introduced the code (in this case
> > > rte_ethdev_configure).
>
> rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized.
> Then the library and drivers may interpret a wrong value.
>
> > > Best practice would have been to have the code require all reserved
> > > fields be
> > > 0 in earlier releases. In this case an application is like to define
> > > a watermark of zero; how will your code handle it.
> >
> > Having watermark of 0 is desired, which is the default. LWM of 0 means
> > the Rx Queue's watermark is not monitored, hence no LWM event is
> generated.
>
> The problem is to have a value not initialized.
> I think the best approach is to not expose the LWM value through this
> configuration structure.
> If the need is to get the current value, we should better add a field in the
> struct rte_eth_rxq_info.
At least from all the dpdk app/example code, rxconf is initialized to 0 then setup
The Rx queue, if user follows these examples we should not have ABI issue.
Since many people are concerned about rxconf change, it's ok to remove the LWM
Field there.
Yes, I think we can add lwm into rte_eth_rxq_info. If we can set Rx queue's attribute,
We should have a way to get it.
>
> [...]
> >
> > > Why introduce new query/set operations? This should just be part of
> > > the overall device configuration.
>
> Thanks to the "set" function, we can avoid the ABI compat issue.
>
> > Due to different implementation. LWM can be a dynamic configuration
> which can help user design a flexible flow control.
> > User may feel ok with LWM of 80% to get high throughput, or later on with
> 50% to throttle the traffic responsively by handling LWM event in order to
> reduce drop.
> > Some driver like mlx5 may implement LWM event as one-time shot. When
> > you receive LWM event, you need to reconfigure LWM in order to receive
> the event again, thus you will not likely to be overwhelmed by the events.
> > These all require set operation.
>
> Yes it is better to allow dynamic watermark configuration, not using the
> function rte_eth_rx_queue_setup().
>
> > For the query operation. The rte_event API
> rte_eth_dev_callback_process() is per-port API, it doesn't carry much
> information when an event happens.
> > When a LWM event happens, we need to know in which Rx queue it
> happens or optionally what's the current LWM percentage of this queue.
> > The query operation serves this purpose.
>
> Yes "query" has to be called in the event handler because event structure is
> not specific to any event type.
>
>
^ permalink raw reply [relevance 3%]
Results 2401-2600 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2020-10-09 3:48 [dpdk-dev] [PATCH v6 0/3] librte_ethdev: error recovery support Kalesh A P
2022-02-11 10:09 ` [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events Ray Kinsella
2022-02-14 10:16 ` Ray Kinsella
2022-02-14 11:15 ` Thomas Monjalon
2022-02-14 16:06 ` Ray Kinsella
2022-05-21 10:33 ` fengchengwen
2022-05-24 15:11 0% ` Ray Kinsella
2022-06-10 0:16 0% ` fengchengwen
2021-03-10 23:24 [dpdk-dev] [PATCH] doc: propose correction rte_bsf64 return type declaration Tyler Retzlaff
2021-10-26 7:45 ` [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use Morten Brørup
2021-11-11 4:15 ` Tyler Retzlaff
2021-11-11 11:54 ` Thomas Monjalon
2021-11-11 12:41 ` Morten Brørup
2022-07-11 14:07 0% ` Jerin Jacob
2021-06-23 17:31 [dpdk-dev] [PATCH] doc: note KNI alternatives and deprecation plan Ferruh Yigit
2021-11-24 17:16 ` [PATCH v3 1/2] doc: note KNI alternatives Ferruh Yigit
2021-11-24 17:16 ` [PATCH v3 2/2] doc: announce KNI deprecation Ferruh Yigit
2022-07-11 14:47 0% ` Jerin Jacob
2021-09-10 2:23 [dpdk-dev] [PATCH 0/8] Removal of PCI bus ABIs Chenbo Xia
2021-10-13 22:48 ` [dpdk-dev] [PATCH v2 0/7] " Walker, Benjamin
2021-10-14 6:41 ` Thomas Monjalon
2022-07-11 12:11 0% ` Thomas Monjalon
2022-02-19 23:43 [PATCH 0/3] more unnecessary null checks Stephen Hemminger
2022-02-20 18:21 ` [PATCH v3 0/8] yet more unnecessary NULL checks Stephen Hemminger
2022-06-24 12:41 0% ` David Marchand
2022-03-09 0:22 [PATCH v1 2/2] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-06-17 18:37 4% ` [PATCH v2 0/5] bbdev changes for 22.11 Nicolas Chautru
2022-06-17 18:37 3% ` [PATCH v2 1/5] bbdev: allow operation type enum for growth Nicolas Chautru
2022-03-10 23:49 [PATCH v1] bbdev: add new operation for FFT processing Nicolas Chautru
2022-03-10 23:49 ` Nicolas Chautru
2022-05-25 22:07 ` Chautru, Nicolas
2022-05-26 6:05 ` Hemant Agrawal
2022-06-07 11:29 3% ` David Marchand
2022-03-17 17:43 [PATCH] net/pcap: support MTU set ido g
2022-05-30 10:36 3% ` [PATCH v3] pcap: " Ido Goshen
2022-05-30 18:05 0% ` Ferruh Yigit
2022-05-31 13:12 0% ` Ido Goshen
2022-06-06 16:21 3% ` [PATCH v4] " Ido Goshen
2022-06-06 17:10 0% ` Stephen Hemminger
2022-06-06 19:07 3% ` Ido Goshen
2022-06-07 6:27 3% ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
2022-06-08 16:04 3% ` [PATCH v6] " Ido Goshen
2022-06-19 9:30 3% ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-20 8:39 3% ` [PATCH v8 " Ido Goshen
2022-03-17 18:37 [PATCH v2] doc: announce changes in bbdev related to enum extension Nicolas Chautru
2022-06-09 0:20 3% ` [PATCH v3] " Nicolas Chautru
2022-06-09 0:20 3% ` Nicolas Chautru
2022-06-09 0:34 3% ` [PATCH v4] " Nicolas Chautru
2022-06-09 0:34 3% ` Nicolas Chautru
2022-06-09 5:14 0% ` Hemant Agrawal
2022-06-09 7:53 0% ` Maxime Coquelin
2022-06-17 16:13 0% ` Chautru, Nicolas
2022-06-27 20:47 0% ` Chautru, Nicolas
2022-06-30 14:52 0% ` Chautru, Nicolas
2022-07-05 15:45 0% ` Bruce Richardson
2022-04-02 10:41 [v4 1/3] ethdev: introduce protocol type based header split wenxuanx.wu
2022-04-26 11:13 ` [PATCH v5 0/3] ethdev: introduce protocol based buffer split wenxuanx.wu
2022-04-26 11:13 ` [PATCH v5 1/4] lib/ethdev: introduce protocol type " wenxuanx.wu
2022-05-17 21:12 ` Thomas Monjalon
2022-05-19 14:40 ` Ding, Xuan
2022-05-26 14:58 0% ` Ding, Xuan
2022-04-19 16:14 [RFC] eal: add bus cleanup to eal cleanup Kevin Laatz
2022-06-03 14:36 ` [PATCH v7] " Kevin Laatz
2022-06-07 11:09 ` Thomas Monjalon
2022-06-07 15:12 3% ` David Marchand
2022-06-13 15:58 0% ` Bruce Richardson
2022-04-21 12:30 [PATCH 0/6] move DPAA2 QDMA driver freom raw to dma nipun.gupta
2022-05-05 9:05 ` [PATCH v3 " nipun.gupta
2022-05-26 6:00 ` Hemant Agrawal
2022-05-31 15:29 3% ` Thomas Monjalon
2022-05-06 3:56 [RFC v1 0/7] net/mlx5: introduce limit watermark and host shaper Spike Du
2022-05-22 5:58 ` [RFC v2 0/7] introduce per-queue " Spike Du
2022-05-22 5:58 ` [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark Spike Du
2022-05-22 15:23 ` Stephen Hemminger
2022-05-23 3:01 ` Spike Du
2022-05-23 21:45 ` Thomas Monjalon
2022-05-24 2:50 3% ` Spike Du
2022-05-24 8:18 3% ` Thomas Monjalon
2022-05-25 12:59 4% ` Andrew Rybchenko
2022-05-25 13:58 3% ` Thomas Monjalon
2022-05-25 14:23 0% ` Andrew Rybchenko
2022-05-23 22:54 ` Stephen Hemminger
2022-05-24 3:46 0% ` Spike Du
2022-05-10 11:58 [PATCH 1/1] lpm: add a scalar version of lookupx4 function Stanislaw Kardach
2022-05-19 17:02 ` Medvedkin, Vladimir
2022-05-24 16:28 ` Stanisław Kardach
2022-05-27 11:16 ` Stanisław Kardach
2022-05-27 13:16 3% ` Medvedkin, Vladimir
2022-05-27 18:18 3% ` [PATCH v2 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
2022-05-30 18:24 3% ` [PATCH v3 " Stanislaw Kardach
2022-05-30 20:38 0% ` Stephen Hemminger
2022-06-01 9:35 0% ` Medvedkin, Vladimir
2022-05-11 13:53 [PATCH] sched: enable CMAN at runtime Marcin Danilewicz
2022-05-12 13:10 ` [PATCH v2] " Marcin Danilewicz
2022-05-30 11:19 3% ` Dumitrescu, Cristian
2022-05-30 14:03 4% ` Danilewicz, MarcinX
2022-06-02 9:57 3% ` Danilewicz, MarcinX
2022-05-30 11:35 0% ` Dumitrescu, Cristian
2022-06-07 10:40 0% ` Danilewicz, MarcinX
2022-06-08 9:42 1% ` [PATCH v3] " Marcin Danilewicz
2022-06-08 11:59 0% ` Dumitrescu, Cristian
2022-06-08 15:29 0% ` Danilewicz, MarcinX
2022-06-13 9:09 1% ` [PATCH v4] " Marcin Danilewicz
2022-06-17 11:48 0% ` Dumitrescu, Cristian
2022-06-20 13:56 1% ` [PATCH v5] ched: " Marcin Danilewicz
2022-06-21 8:16 1% ` [PATCH v6] sched: " Marcin Danilewicz
2022-07-04 9:19 1% ` [PATCH v7] " Marcin Danilewicz
2022-07-05 17:05 1% ` [PATCH v8] " Marcin Danilewicz
2022-07-05 18:00 0% ` Ajmera, Megha
2022-07-06 8:53 0% ` Singh, Jasvinder
2022-07-07 13:07 0% ` Danilewicz, MarcinX
2022-07-08 13:14 1% ` [PATCH v9] " Marcin Danilewicz
2022-05-24 18:46 3% [RFT 0/2] pie: floating point fixes Stephen Hemminger
2022-05-24 19:31 0% ` Morten Brørup
2022-05-25 9:53 4% [PATCH] eal/ppc: undefine AltiVec keyword vector Thomas Monjalon
2022-05-25 11:48 ` Ray Kinsella
2022-05-25 15:40 ` Thomas Monjalon
2022-05-25 18:02 3% ` Ray Kinsella
2022-05-25 18:34 3% ` Tyler Retzlaff
2022-05-26 10:18 0% ` Thomas Monjalon
2022-05-26 11:02 0% ` Ray Kinsella
2022-06-01 15:04 0% ` Thomas Monjalon
2022-05-30 13:15 2% [dpdk-dev] [RFC PATCH] ethdev: support congestion management jerinj
2022-05-30 19:43 0% ` Ajit Khaparde
2022-07-13 12:11 0% ` Jerin Jacob
2022-05-31 1:09 0% ` Min Hu (Connor)
2022-05-31 16:09 0% ` Stephen Hemminger
2022-05-31 4:04 3% [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-05-31 4:04 4% ` [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-05-31 7:49 0% ` [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes Zhang, Roy Fan
2022-05-31 11:52 0% ` [EXT] " Akhil Goyal
2022-05-31 14:12 [PATCH v4 0/8] Introduce support for RISC-V architecture Stanislaw Kardach
2022-05-31 14:13 9% ` [PATCH v4 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-06-01 9:02 [PATCH v5 00/12] cryptodev: rsa, dh, ecdh changes Arek Kusztal
2022-06-01 9:02 4% ` [PATCH v5 06/12] cryptodev: add elliptic curve diffie hellman Arek Kusztal
2022-06-01 10:14 0% ` Kusztal, ArkadiuszX
2022-06-02 13:33 3% ` [EXT] " Akhil Goyal
2022-06-02 14:21 0% ` Ray Kinsella
2022-06-02 14:25 0% ` Akhil Goyal
2022-06-02 14:46 4% ` Kusztal, ArkadiuszX
2022-06-03 13:26 4% ` Ray Kinsella
2022-06-01 11:15 3% [PATCH v4 1/2] lpm: add const to lpm arg of rte_lpm_lookup Stanislaw Kardach
2022-06-02 20:52 0% ` Thomas Monjalon
2022-06-03 7:29 0% ` Bruce Richardson
2022-06-03 7:43 0% ` Thomas Monjalon
2022-06-02 1:52 [PATCH 00/14] Add support of NFP3800 chip and firmware with NFDk Jin Liu
2022-06-02 1:52 6% ` [PATCH 07/14] net/nfp: support NFDK firmware Jin Liu
2022-06-02 22:53 0% ` Ferruh Yigit
2022-06-14 8:49 3% ` Kevin Liu
2022-06-14 9:21 0% ` Ferruh Yigit
2022-06-14 9:30 0% ` Kevin Liu
2022-06-16 2:39 ` [PATCH v2 00/15] Add support of NFP3800 chip and firmware with NFDk Jin Liu
2022-06-16 2:39 5% ` [PATCH v2 09/15] net/nfp: support " Jin Liu
2022-06-17 9:34 ` [PATCH v3 00/13] Add support of NFP3800 chip and " Jin Liu
2022-06-17 9:34 5% ` [PATCH v3 07/13] net/nfp: support " Jin Liu
2022-06-23 2:26 ` [PATCH v4 00/13] Add support of NFP3800 chip and " Jin Liu
2022-06-23 2:26 5% ` [PATCH v4 07/13] net/nfp: support " Jin Liu
2022-06-02 9:23 [dpdk-dev] [PATCH v1] build: ccache support for cross build jerinj
2022-06-08 17:13 3% ` [dpdk-dev] [PATCH v2] " jerinj
2022-06-14 16:01 0% ` Thomas Monjalon
2022-06-04 9:09 3% Optimizations are not features Morten Brørup
2022-06-04 9:33 0% ` Jerin Jacob
2022-06-04 10:00 0% ` Andrew Rybchenko
2022-06-04 11:10 0% ` Jerin Jacob
2022-06-04 12:19 3% ` Morten Brørup
2022-06-04 12:51 0% ` Andrew Rybchenko
2022-06-05 8:15 0% ` Morten Brørup
2022-06-05 16:05 0% ` Stephen Hemminger
2022-06-06 9:35 0% ` Konstantin Ananyev
2022-06-29 20:44 0% ` Honnappa Nagarahalli
2022-06-30 15:39 0% ` Morten Brørup
2022-07-03 19:38 0% ` Konstantin Ananyev
2022-06-06 22:50 [PATCH v1] bbdev: add device status info Nicolas Chautru
2022-06-06 22:50 ` Nicolas Chautru
2022-06-07 0:09 3% ` Stephen Hemminger
2022-06-07 12:42 0% ` Maxime Coquelin
2022-06-07 15:44 0% ` Chautru, Nicolas
2022-06-07 16:20 0% ` Maxime Coquelin
2022-06-07 16:42 0% ` Stephen Hemminger
2022-06-08 22:44 0% ` Chautru, Nicolas
2022-06-07 10:46 [PATCH RESEND v4 0/8] Introduce support for RISC-V architecture Stanislaw Kardach
2022-06-07 10:46 9% ` [PATCH RESEND v4 7/8] devtools: add RISC-V to test-meson-builds.sh Stanislaw Kardach
2022-06-07 12:59 [PATCH v5 0/7] introduce per-queue available descriptor threshold and host shaper Spike Du
2022-06-08 16:35 ` [PATCH v6] ethdev: introduce available Rx descriptors threshold Andrew Rybchenko
2022-06-08 17:22 ` Thomas Monjalon
2022-06-08 17:46 3% ` Thomas Monjalon
2022-06-09 0:17 3% ` fengchengwen
2022-06-09 7:05 0% ` Thomas Monjalon
2022-06-10 0:01 3% ` fengchengwen
2022-06-07 13:48 4% Minutes of Technical Board Meeting, 2022-06-01 Olivier Matz
2022-06-08 12:49 3% [PATCH v2 0/6] Vhost checksum offload improvements Maxime Coquelin
2022-06-17 14:06 0% ` Maxime Coquelin
2022-06-08 15:50 15% [PATCH] devtools: unify cross-compilation tests Thomas Monjalon
2022-06-08 16:34 4% ` David Marchand
2022-06-08 17:20 0% ` Thomas Monjalon
2022-06-13 18:24 4% [PATCH v1] bbdev: allow operation type enum for growth Nicolas Chautru
2022-06-13 18:24 ` Nicolas Chautru
2022-06-17 8:21 3% ` Thomas Monjalon
2022-06-17 16:12 0% ` Chautru, Nicolas
2022-06-23 16:09 0% ` Ray Kinsella
2022-06-15 7:39 [PATCH 0/5] support telemetry dump dev Chengwen Feng
2022-06-15 7:39 ` [PATCH 1/5] usertools: use non-strict when json-loads in telemetry Chengwen Feng
2022-06-15 13:54 ` Morten Brørup
2022-06-15 16:54 ` Bruce Richardson
2022-06-15 18:01 3% ` Morten Brørup
2022-06-15 20:09 0% ` Morten Brørup
2022-06-17 9:46 ` [PATCH v2 0/5] support telemetry dump Chengwen Feng
2022-06-17 9:46 ` [PATCH v2 1/5] telemetry: escape special char when tel string Chengwen Feng
2022-06-17 11:16 ` Morten Brørup
2022-06-17 11:25 ` Bruce Richardson
2022-06-17 17:05 ` Stephen Hemminger
2022-06-18 3:52 3% ` fengchengwen
2022-06-18 9:59 0% ` Morten Brørup
2022-06-22 7:57 0% ` Power, Ciara
2022-06-22 9:19 0% ` Bruce Richardson
2022-06-23 16:45 0% ` Bruce Richardson
2022-06-17 18:37 [PATCH v2 5/5] bbdev: add new operation for FFT processing Nicolas Chautru
2022-06-28 1:35 4% ` [PATCH v3 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-06-28 1:35 3% ` [PATCH v3 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-07-06 0:23 4% ` [PATCH v4 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-07-06 0:23 3% ` [PATCH v4 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-07-06 12:50 0% ` Tom Rix
2022-07-06 21:20 0% ` Chautru, Nicolas
2022-07-06 0:23 ` [PATCH v4 2/7] bbdev: add device status info Nicolas Chautru
2022-07-06 15:38 ` Tom Rix
2022-07-06 21:16 3% ` Chautru, Nicolas
2022-07-07 13:37 0% ` Tom Rix
2022-07-07 17:15 0% ` Chautru, Nicolas
2022-07-06 0:23 ` [PATCH v4 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-07-06 16:06 ` Tom Rix
2022-07-06 21:12 3% ` Chautru, Nicolas
2022-07-07 13:34 0% ` Tom Rix
2022-07-07 17:13 3% ` Chautru, Nicolas
2022-07-06 23:28 4% ` [PATCH v5 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-07-06 23:28 3% ` [PATCH v5 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-06-21 12:29 5% [PATCH] config/riscv: name the cross file properly Stanislaw Kardach
2022-06-24 13:35 [PATCH 1/1] doc: notice to add new ipsec event subtypes Vamsi Attunuru
2022-06-27 5:29 ` [PATCH v2 1/1] doc: announce addition of " Vamsi Attunuru
2022-07-12 15:03 3% ` Thomas Monjalon
2022-07-12 15:30 0% ` [EXT] " Akhil Goyal
2022-07-12 20:44 0% ` Thomas Monjalon
2022-06-27 9:32 4% [Bug 1042] [dpdk-22.07](ABI) unit_tests_eal/link_bonding_rssconf: link_bonding_rssconf_autotest test failed bugzilla
2022-06-28 13:53 [PATCH 1/2] doc: announce region based device mapping support skori
2022-07-07 12:39 ` Xia, Chenbo
2022-07-13 7:03 3% ` Sunil Kumar Kori
2022-07-13 7:27 3% ` Xia, Chenbo
2022-07-13 7:38 0% ` Sunil Kumar Kori
2022-07-13 7:18 ` David Marchand
2022-07-13 7:21 3% ` Xia, Chenbo
2022-06-28 14:46 2% [RFC PATCH 00/11] Bus cleanup for 22.11 David Marchand
2022-06-28 14:46 1% ` [RFC PATCH 11/11] bus: hide bus object David Marchand
2022-06-28 16:22 3% ` Tyler Retzlaff
2022-06-28 16:29 0% ` Stephen Hemminger
2022-06-28 17:07 0% ` Tyler Retzlaff
2022-07-09 8:26 1% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 13/29] bus: hide bus object David Marchand
2022-07-09 8:26 1% ` [RFC v2 v2 27/29] dev: hide driver object David Marchand
2022-07-09 8:26 3% ` [RFC v2 v2 29/29] dev: hide device object David Marchand
2022-07-09 16:30 0% ` [RFC v2 v2 00/29] Bus and device cleanup for 22.11 Stephen Hemminger
2022-07-11 8:38 0% ` Bruce Richardson
2022-06-28 19:08 3% [PATCH] doc: announce support for MACsec in rte_security Akhil Goyal
2022-06-29 3:37 0% ` Hemant Agrawal
2022-06-29 7:40 0% ` Zhang, Roy Fan
2022-07-11 15:00 0% ` Jerin Jacob
2022-06-29 21:22 3% Call for Proposals - Userspace 2022 Nathan Southern
2022-06-30 9:41 8% [PATCH] doc: announce marking bus object as internal David Marchand
2022-06-30 9:54 0% ` Bruce Richardson
2022-06-30 14:36 0% ` Thomas Monjalon
2022-07-04 14:29 0% ` Kevin Laatz
2022-07-05 4:43 0% ` Hemant Agrawal
2022-07-05 6:59 0% ` Andrew Rybchenko
2022-06-30 10:47 DPDK Release Status Meeting 2022-06-30 Mcnamara, John
2022-06-30 11:43 3% ` Ferruh Yigit
2022-06-30 11:57 0% ` David Marchand
2022-06-30 12:40 0% ` Ferruh Yigit
2022-06-30 12:43 0% ` Dodji Seketeli
2022-06-30 17:52 0% ` Ferruh Yigit
[not found] <20220708131431.148279-1-marcinx.danilewicz>
2022-07-08 14:22 1% ` [PATCH v10] sched: enable CMAN at runtime Marcin Danilewicz
2022-07-10 6:17 13% [PATCH] doc: announce marking device and driver objects as internal David Marchand
2022-07-10 8:25 0% ` Andrew Rybchenko
2022-07-11 2:16 0% ` Xia, Chenbo
2022-07-11 12:36 4% ` Thomas Monjalon
2022-07-11 15:01 0% ` Jerin Jacob
2022-07-12 4:25 0% ` Hemant Agrawal
2022-07-12 8:24 0% ` Kevin Laatz
2022-07-12 11:38 0% ` Andrew Rybchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).