Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
Hi, 21/01/2020 01:24, Thomas Monjalon: > 02/12/2019 16:35, David Marchand: > > We are currently stuck with no option but recompile a DPDK if the system > > has more cores than RTE_MAX_LCORE. > > A bit of a pity when you get a system with more than 200+ cores and your > > testpmd has been built and packaged with RTE_MAX_LCORE == 128. > > > > The --lcores does not need to care about the underlying cores, remove > > this limitation. > > > David Marchand (4): > > eal/windows: fix cpuset macro name > > eal: do not cache lcore detection state > > eal: display all detected cores at startup > > eal: remove limitation on cpuset with --lcores > > The patches look good but it is very hard to review parsing code (last patch). > We will better experience corner cases after merging. > > Applied for -rc1, thanks This patch was merged in 20.02. We don't have any feedback about issues so it's probably working fine. It is solving a problem for running DPDK on machines having a lot of cores. Now the difficult question: is it a new feature or a fix? Should we backport this patchset?
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
Hi Thomas
Thank you for your correction spelling error of 'cancel'.
Indeed it is not the best solution by creating a thread. I refer to the same
solution with Linux kernel driver. Linux kernel driver manages link status by
using a thread. Maybe we can figure out another better solution to fix this
problem but it may take much more time. At this time, 20.02 formal release is
coming and this problem affect some basic library.
Tks for your understanding.
BR,
Zhu, Tao
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Thursday, February 20, 2020 11:37 PM
> To: Ye, Xiaolong ; Zhu, TaoX ;
> Yigit, Ferruh
> Cc: dev@dpdk.org; Ananyev, Konstantin ;
> Lu, Wenzhuo ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
>
> 17/02/2020 14:01, Ferruh Yigit:
> > On 2/15/2020 3:41 PM, Ye Xiaolong wrote:
> > > On 01/15, taox@intel.com wrote:
> > >> From: Zhu Tao
> > >>
> > >> IXGBE link status task use rte alarm thread in old implementation.
> > >
> > > s/use/uses
> > >
> > >> Sometime ixgbe link status task takes up to 9 seconds. This will
> > >> severely affect the rte-alarm-thread-dependent a task in the
> > >> system, like interrupt or hotplug event. So replace with a
> > >
> > > s/a/an
> > >
> > >> independent thread which has the same thread affinity settings as
> > >> rte interrupt.
> > >>
> > >> Fixes: 0408f47b ("net/ixgbe: fix busy polling while fiber link
> > >> update")
> > >
> > > Should be:
> > >
> > > Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link
> > > update")
> > >
> > >> Cc: sta...@dpdk.org
> > >>
> > >
> > > Applied to dpdk-next-net-intel with Konstantin's ack, Thanks.
> > >
> >
> > Shared build is failing because of missing pthread library, fixing
> > while merging to next-net:
>
> One more thing looks strange in this patch:
> ixgbe_dev_cannel_link_thread
> Should it be
> ixgbe_dev_cancel_link_thread
> ?
>
> Note: I looked at it because I am not sure multiplying the interrupt threads
> is
> a good idea.
> Basically the link status management is too long in this driver.
> Instead of fixing the root cause, you move the annoying workload
> somewhere else. But it is still there...
>
> Please could you work on a long term fix?
>
Re: [dpdk-dev] [PATCH] net/mlx5: fix last completed built descriptor
From: Viacheslav Ovsiienko
> Sent: Thursday, February 20, 2020 11:18 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Thomas Monjalon ;
> ferruh.yi...@intel.com; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix last completed built descriptor
>
> The routine sending packets with Multi-Packet Write method assigns the
> wqe_last variable with transmit descriptor (WQE - work queue entry) being
> built. If send queue is close to full state, the WQE has no data yet (trying
> to
> put the first packet) and there is no enough space in descriptor for the next
> packet the WQE is discarded and the stored wqe_last value becomes invalid -
> points to the discarded WQE.
>
> The mlx5_tx_burst_request_completion() routine might set the completion
> request flags in the WQE pointed by wqe_last, it is safe, but the next
> mlx5_tx_burst call uses the WQE as the first free one and request
> completion flags might be overwritten and completion request will be lost
> causing the transmit datapath malfunction.
>
> Fixes: 8b581c690a54 ("net/mlx5: move Tx complete request routine")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
21/02/2020 09:19, Zhu, TaoX:
> Hi Thomas
>
> Thank you for your correction spelling error of 'cancel'.
>
> Indeed it is not the best solution by creating a thread. I refer to the same
> solution with Linux kernel driver. Linux kernel driver manages link status by
> using a thread. Maybe we can figure out another better solution to fix this
> problem but it may take much more time. At this time, 20.02 formal release is
> coming and this problem affect some basic library.
> Tks for your understanding.
I understand, that's why I already accepted this patch in mainline (while
fixing typo).
Please it would be really appreciated to work on a better solution.
> > -Original Message-
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Thursday, February 20, 2020 11:37 PM
> > To: Ye, Xiaolong ; Zhu, TaoX ;
> > Yigit, Ferruh
> > Cc: dev@dpdk.org; Ananyev, Konstantin ;
> > Lu, Wenzhuo ; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
> >
> > 17/02/2020 14:01, Ferruh Yigit:
> > > On 2/15/2020 3:41 PM, Ye Xiaolong wrote:
> > > > On 01/15, taox@intel.com wrote:
> > > >> From: Zhu Tao
> > > >>
> > > >> IXGBE link status task use rte alarm thread in old implementation.
> > > >
> > > > s/use/uses
> > > >
> > > >> Sometime ixgbe link status task takes up to 9 seconds. This will
> > > >> severely affect the rte-alarm-thread-dependent a task in the
> > > >> system, like interrupt or hotplug event. So replace with a
> > > >
> > > > s/a/an
> > > >
> > > >> independent thread which has the same thread affinity settings as
> > > >> rte interrupt.
> > > >>
> > > >> Fixes: 0408f47b ("net/ixgbe: fix busy polling while fiber link
> > > >> update")
> > > >
> > > > Should be:
> > > >
> > > > Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link
> > > > update")
> > > >
> > > >> Cc: sta...@dpdk.org
> > > >>
> > > >
> > > > Applied to dpdk-next-net-intel with Konstantin's ack, Thanks.
> > > >
> > >
> > > Shared build is failing because of missing pthread library, fixing
> > > while merging to next-net:
> >
> > One more thing looks strange in this patch:
> > ixgbe_dev_cannel_link_thread
> > Should it be
> > ixgbe_dev_cancel_link_thread
> > ?
> >
> > Note: I looked at it because I am not sure multiplying the interrupt
> > threads is
> > a good idea.
> > Basically the link status management is too long in this driver.
> > Instead of fixing the root cause, you move the annoying workload
> > somewhere else. But it is still there...
> >
> > Please could you work on a long term fix?
> >
>
>
Re: [dpdk-dev] [PATCH] doc: update thunderx guide
On Fri, Feb 7, 2020 at 3:33 PM Harman Kalra wrote: > > Updating the thunderx with loopback port support, > debugging options, new features added and correcting > some formating issues. Fixed: s/formating/formatting > > Signed-off-by: Harman Kalra Acked-by: Jerin Jacob Applied to dpdk-next-net-mrvl/master. Thanks
Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang wrote: > > [AMD Official Use Only - Internal Distribution Only] Please, get this header removed. This is a public mailing list. > Thanks Thomas for bringing this up. > I consider this is not a new feature, but rather a fix to address the issue > with statically assigned maximum lcore limit on high-density CPU platform > such as AMD Epyc. > As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11, and they > have 1~2 yrs of lifetime left, we like to backport this to LTS 18.11 & 19.11 > at least. It is not a fix. The use of static arrays is a design choice that goes back to the early days in dpdk. The addition of --lcores came in after this, but it was introduced for a different use case than placing lcores on any physical core. And there was no claim that a core > RTE_MAX_LCORE would be usable. When testing on a new hardware, it is normal to observe some limitations. Running DPDK on those platforms should be possible: "should be" because I do not have access to this hardware and saw neither tests reports nor performance numbers. Before this patch, the limitation is that on Epyc, cores > RTE_MAX_LCORE are not usable. Now, this change is quite constrained. If we backport it, I don't expect issues in the main dpdk components (based on code review and ovs tests with a RTE_MAX_LCORE set to 16 on a 24 cores system). There might be issues in some examples or not widely used library which uses a physical core id instead of a lcore id. This is the same recurring question "do we allow new features in a stable branch?". -- David Marchand
Re: [dpdk-dev] [PATCH] net/mlx5: fix last completed built descriptor
On 2/21/2020 8:25 AM, Matan Azrad wrote:
> From: Viacheslav Ovsiienko
>> Sent: Thursday, February 20, 2020 11:18 PM
>> To: dev@dpdk.org
>> Cc: Matan Azrad ; Raslan Darawsheh
>> ; Thomas Monjalon ;
>> ferruh.yi...@intel.com; sta...@dpdk.org
>> Subject: [PATCH] net/mlx5: fix last completed built descriptor
>>
>> The routine sending packets with Multi-Packet Write method assigns the
>> wqe_last variable with transmit descriptor (WQE - work queue entry) being
>> built. If send queue is close to full state, the WQE has no data yet (trying
>> to
>> put the first packet) and there is no enough space in descriptor for the next
>> packet the WQE is discarded and the stored wqe_last value becomes invalid -
>> points to the discarded WQE.
>>
>> The mlx5_tx_burst_request_completion() routine might set the completion
>> request flags in the WQE pointed by wqe_last, it is safe, but the next
>> mlx5_tx_burst call uses the WQE as the first free one and request
>> completion flags might be overwritten and completion request will be lost
>> causing the transmit datapath malfunction.
>>
>> Fixes: 8b581c690a54 ("net/mlx5: move Tx complete request routine")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Viacheslav Ovsiienko
> Acked-by: Matan Azrad
>
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/mlx5: fix inline packet size for ConnectX-4LX
On 2/21/2020 7:39 AM, Slava Ovsiienko wrote:
>> -Original Message-
>> From: Matan Azrad
>> Sent: Friday, February 21, 2020 9:38
>> To: Slava Ovsiienko ; dev@dpdk.org
>> Cc: Raslan Darawsheh ; Thomas Monjalon
>> ; ferruh.yi...@intel.com
>> Subject: RE: [PATCH] net/mlx5: fix inline packet size for ConnectX-4LX
>>
>>
>>
>> From: Viacheslav Ovsiienko
>>> This patch does extra inline packet size check to tune the
>>> ConnectX-4LX performance in the legacy Multi-Packet Write mode.
>>>
>>> Signed-off-by: Viacheslav Ovsiienko
>>
>> Slava, Don't you think we want it for stable releases?
> Yes, thanks for reminding, just forgot "cc: stable", will send to stable ML.
Is the fixed commit known? (fixes line)
>
>>
>> Besides it:
>> Acked-by: Matan Azrad
>>
>>> drivers/net/mlx5/mlx5_rxtx.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/mlx5/mlx5_rxtx.c
>>> b/drivers/net/mlx5/mlx5_rxtx.c index b55db4f..0df811b 100644
>>> --- a/drivers/net/mlx5/mlx5_rxtx.c
>>> +++ b/drivers/net/mlx5/mlx5_rxtx.c
>>> @@ -4281,6 +4281,8 @@ enum mlx5_txcmp_code {
>>> loc->mbuf->ol_flags & PKT_TX_DYNF_NOINLINE)
>>> goto pointer_empw;
>>> if (MLX5_TXOFF_CONFIG(MPW)) {
>>> + if (dlen > txq->inlen_send)
>>> + goto pointer_empw;
>>> tlen = dlen;
>>> if (part == room) {
>>> /* Open new inline MPW session. */
>>> --
>>> 1.8.3.1
>
Re: [dpdk-dev] [PATCH] net/mlx5: fix inline packet size for ConnectX-4LX
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, February 21, 2020 11:44
> To: Slava Ovsiienko ; Matan Azrad
> ; dev@dpdk.org
> Cc: Raslan Darawsheh ; Thomas Monjalon
>
> Subject: Re: [PATCH] net/mlx5: fix inline packet size for ConnectX-4LX
>
> On 2/21/2020 7:39 AM, Slava Ovsiienko wrote:
> >> -Original Message-
> >> From: Matan Azrad
> >> Sent: Friday, February 21, 2020 9:38
> >> To: Slava Ovsiienko ; dev@dpdk.org
> >> Cc: Raslan Darawsheh ; Thomas Monjalon
> >> ; ferruh.yi...@intel.com
> >> Subject: RE: [PATCH] net/mlx5: fix inline packet size for
> >> ConnectX-4LX
> >>
> >>
> >>
> >> From: Viacheslav Ovsiienko
> >>> This patch does extra inline packet size check to tune the
> >>> ConnectX-4LX performance in the legacy Multi-Packet Write mode.
> >>>
> >>> Signed-off-by: Viacheslav Ovsiienko
> >>
> >> Slava, Don't you think we want it for stable releases?
> > Yes, thanks for reminding, just forgot "cc: stable", will send to stable ML.
>
> Is the fixed commit known? (fixes line)
Yes, sorry for missed "Fixes" tag
It should be:
Fixes: 7593cf1d3500 ("net/mlx5: fix legacy multi-packet write session")
With best regards, Slava
>
> >
> >>
> >> Besides it:
> >> Acked-by: Matan Azrad
> >>
> >>> drivers/net/mlx5/mlx5_rxtx.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/net/mlx5/mlx5_rxtx.c
> >>> b/drivers/net/mlx5/mlx5_rxtx.c index b55db4f..0df811b 100644
> >>> --- a/drivers/net/mlx5/mlx5_rxtx.c
> >>> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> >>> @@ -4281,6 +4281,8 @@ enum mlx5_txcmp_code {
> >>> loc->mbuf->ol_flags & PKT_TX_DYNF_NOINLINE)
> >>> goto pointer_empw;
> >>> if (MLX5_TXOFF_CONFIG(MPW)) {
> >>> + if (dlen > txq->inlen_send)
> >>> + goto pointer_empw;
> >>> tlen = dlen;
> >>> if (part == room) {
> >>> /* Open new inline MPW session. */
> >>> --
> >>> 1.8.3.1
> >
Re: [dpdk-dev] [PATCH] net/mlx5: fix inline packet size for ConnectX-4LX
On 2/21/2020 7:37 AM, Matan Azrad wrote:
>
>
> From: Viacheslav Ovsiienko
>> This patch does extra inline packet size check to tune the ConnectX-4LX
>> performance in the legacy Multi-Packet Write mode.
>>
>> Signed-off-by: Viacheslav Ovsiienko
>
> Slava, Don't you think we want it for stable releases?
>
> Besides it:
> Acked-by: Matan Azrad
Fixes: 7593cf1d3500 ("net/mlx5: fix legacy multi-packet write session")
Cc: sta...@dpdk.org
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] doc: fix octeontx2 eventdev devargs
On Wed, Feb 19, 2020 at 12:25 PM wrote:
>
> From: Pavan Nikhilesh
>
> Fix OCTEON TX2 event device devargs examples.
>
> Fixes: 55e778ca4648 ("event/octeontx2: add devargs for inflight buffer count")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pavan Nikhilesh
Reviewed-by: Jerin Jacob
Thomas,
This is the only patch for RC4 from the eventdev tree.
Could you please merge this directly to dpdk.git?
> ---
> doc/guides/eventdevs/octeontx2.rst | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/doc/guides/eventdevs/octeontx2.rst
> b/doc/guides/eventdevs/octeontx2.rst
> index fad84cf42..d4b2515ce 100644
> --- a/doc/guides/eventdevs/octeontx2.rst
> +++ b/doc/guides/eventdevs/octeontx2.rst
> @@ -66,7 +66,7 @@ Runtime Config Options
>upper limit for in-flight events.
>For example::
>
> ---dev "0002:0e:00.0,xae_cnt=16384"
> +-w 0002:0e:00.0,xae_cnt=16384
>
> - ``Force legacy mode``
>
> @@ -74,7 +74,7 @@ Runtime Config Options
>single workslot mode in SSO and disable the default dual workslot mode.
>For example::
>
> ---dev "0002:0e:00.0,single_ws=1"
> +-w 0002:0e:00.0,single_ws=1
>
> - ``Event Group QoS support``
>
> @@ -89,7 +89,7 @@ Runtime Config Options
>default.
>For example::
>
> ---dev "0002:0e:00.0,qos=[1-50-50-50]"
> +-w 0002:0e:00.0,qos=[1-50-50-50]
>
> - ``Selftest``
>
> @@ -98,7 +98,7 @@ Runtime Config Options
>The tests are run once the vdev creation is successfully complete.
>For example::
>
> ---dev "0002:0e:00.0,selftest=1"
> +-w 0002:0e:00.0,selftest=1
>
> - ``TIM disable NPA``
>
> @@ -107,7 +107,7 @@ Runtime Config Options
>parameter disables NPA and uses software mempool to manage chunks
>For example::
>
> ---dev "0002:0e:00.0,tim_disable_npa=1"
> +-w 0002:0e:00.0,tim_disable_npa=1
>
> - ``TIM modify chunk slots``
>
> @@ -118,7 +118,7 @@ Runtime Config Options
>to SSO. The default value is 255 and the max value is 4095.
>For example::
>
> ---dev "0002:0e:00.0,tim_chnk_slots=1023"
> +-w 0002:0e:00.0,tim_chnk_slots=1023
>
> - ``TIM enable arm/cancel statistics``
>
> @@ -126,7 +126,7 @@ Runtime Config Options
>event timer adapter.
>For example::
>
> ---dev "0002:0e:00.0,tim_stats_ena=1"
> +-w 0002:0e:00.0,tim_stats_ena=1
>
> - ``TIM limit max rings reserved``
>
> @@ -136,7 +136,7 @@ Runtime Config Options
>rings.
>For example::
>
> ---dev "0002:0e:00.0,tim_rings_lmt=5"
> +-w 0002:0e:00.0,tim_rings_lmt=5
>
> - ``TIM ring control internal parameters``
>
> @@ -146,7 +146,7 @@ Runtime Config Options
>default values.
>For Example::
>
> ---dev "0002:0e:00.0,tim_ring_ctl=[2-1023-1-0]"
> +-w 0002:0e:00.0,tim_ring_ctl=[2-1023-1-0]
>
> Debugging Options
> ~
> --
> 2.17.1
>
Re: [dpdk-dev] [PATCH v3] examples/tep_term: remove redundant info get
On Mon, Feb 17, 2020 at 2:41 AM Xiaoyun Li wrote:
>
> Removed redundant function call of 'rte_eth_dev_info_get()' since it has
> already been called earlier.
>
> Coverity issue: 349922
> Fixes: 2bb43bd4350a ("examples/tep_term: add TSO offload configuration")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiaoyun Li
Little comment, this patch solves a coverity issue.
Upon inspection of this example code, I can see no check on device
capability when sending packets.
So I suppose it is broken when user asks for TSO, but the devices do
not support TSO.
Can you investigate and fix this in the next release?
Reviewed-by: Xiaolong Ye
Acked-by: David Marchand
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH] doc: fix octeontx2 eventdev devargs
21/02/2020 11:13, Jerin Jacob:
> On Wed, Feb 19, 2020 at 12:25 PM wrote:
> >
> > From: Pavan Nikhilesh
> >
> > Fix OCTEON TX2 event device devargs examples.
> >
> > Fixes: 55e778ca4648 ("event/octeontx2: add devargs for inflight buffer
> > count")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Pavan Nikhilesh
>
> Reviewed-by: Jerin Jacob
>
> Thomas,
> This is the only patch for RC4 from the eventdev tree.
> Could you please merge this directly to dpdk.git?
Yes, sure.
Re: [dpdk-dev] [PATCH 2/4] ci: fix Travis config warnings
20/02/2020 22:01, Aaron Conole: > David Marchand writes: > > > On Thu, Feb 20, 2020 at 12:03 PM Thomas Monjalon > > wrote: > >> > >> 19/02/2020 20:41, David Marchand: > >> > Reading https://config.travis-ci.com/ and using > >> > https://config.travis-ci.com/explore to check changes, we can cleanup > >> > some warnings reported by the config validation options in Travis. > >> > >> For documentation purpose, would be good to describe issues in the commit > >> log. > > > > Since I only have this commitlog to update, I intend to push the > > series with the following addition: > > > > Example on a job in master: > > https://travis-ci.com/DPDK/dpdk/builds/149537002/config > > > > Build config validation: > > root: deprecated key doc_packages (anchor on a non-private key) > > root: deprecated key build_32b_packages (anchor on a non-private key) > > root: deprecated key libabigail_build_packages (anchor on a non-private key) > > root: deprecated key extra_packages (anchor on a non-private key) > > root: deprecated key aarch64_packages (anchor on a non-private key) > > root: key matrix is an alias for jobs, using jobs > > > > For the "(anchor on a non-private key)" warnings, the Travis > > documentation [1] recommends prefixing private keys with _ (Travis > > schema is available at [2]). > > > > The use of the "matrix" key is allowed, but it is just an alias to the > > "jobs" key. > > > > 1: > > https://docs.travis-ci.com/user/build-config-yaml#private-keys-as-yaml-anchors-and-aliases-and-external-tooling > > 2: > > https://github.com/travis-ci/travis-yml/blob/730a77f4028b91293a55c8c1c52fc72e64379dde/schema.json > > LGTM Perfect, thanks
Re: [dpdk-dev] [PATCH] doc: deprecate using MAX values as array size
On 1/30/2020 2:20 PM, Ferruh Yigit wrote: > Adding the deprecation notice as reminder for next ABI breakage release > (20.11). > This one time breakage is required to be able to extend enum/define > without breaking ABI. > > Signed-off-by: Ferruh Yigit > --- > doc/guides/rel_notes/deprecation.rst | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index dfcca87ab..99d81564a 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -38,6 +38,20 @@ Deprecation Notices >remove it from the externally visible ABI and allow it to be updated in the >future. > > +* 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 > + ``.*MAX.*`` value. So extending this enum/define increases the ``.*MAX.*`` > + value which increases the size of the array and depending on how/where the > + array is used this may break the ABI. > + ``RTE_ETH_FLOW_MAX`` is one sample of the mentioned case, adding a new flow > + type will break the ABI because of ``flex_mask[RTE_ETH_FLOW_MAX]`` array > + usage in following public struct hierarchy: > + ``rte_eth_fdir_flex_conf -> rte_fdir_conf -> rte_eth_conf (in the > middle)``. > + Need to identify this kind of usages and fix in 20.11, otherwise this > blocks > + us extending existing enum/define. > + One solution can be using a fixed size array instead of ``.*MAX.*`` value. > + > * dpaa2: removal of ``rte_dpaa2_memsegs`` structure which has been replaced >by a pa-va search library. This structure was earlier being used for > holding >memory segments used by dpaa2 driver for faster pa->va translation. This > Reminder of this deprecation notice.
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: > > On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon wrote: > > > > Hi Jerin, > > Hi Thomas, > > Thanks for starting this discussion now. It is an interesting > discussion. Some thoughts below. > We can decide based on community consensus and follow a single rule > across the components. Thomas, No feedback yet on the below questions. If there no consensus in the email, I would like to propose this topic to the 26th Feb TB meeting. > > > > > 17/02/2020 08:19, Jerin Jacob: > > > I got initial comments from Ray and Stephen on this RFC[1]. Thanks for > > > the comments. > > > > > > Is anyone else planning to have an architecture level or API usage > > > level review or any review of other top-level aspects? > > > > If we add rte_graph to DPDK, we will have 2 similar libraries. > > > > I already proposed several times to move rte_pipeline in a separate > > repository for two reasons: > > 1/ it is acting at a higher API layer level > > We need to define what is the higher layer API. Is it processing beyond L2? > > In the context of Graph library, it is a framework, not using any of > the substem API > other than EAL and it is under lib/librte_graph. > Nodes library using graph and other subsystem components such as ethdev and > it is under lib/lib_node/ > > > Another interesting question would what would be an issue in DPDK supporting > beyond L2. Or higher level protocols? > > > > 2/ there can be different solutions in this layer > > Is there any issue with that? > There is overlap with the distributor library and eventdev as well. > ethdev and SW traffic manager libraries as well. That list goes on. > > > > > I think 1/ was commonly agreed in the community. > > Now we see one more proof of the reason 2/. > > > > I believe it is time to move rte_pipeline (Packet Framework) > > in a separate repository, and welcome rte_graph as well in another > > separate repository. > > What would be gain out of this? > > My concerns are: > # Like packet-gen, The new code will be filled with unnecessary DPDK > version checks > and unnecessary compatibility issues. > # Anything is not in main dpdk repo, it is a second class citizen. > # Customer has the pain to use two repos and two releases. Internally, > it can be two different > repo but release needs to go through one repo. > > If we are focusing ONLY on the driver API then how can DPDK grow > further? If linux kernel > would be thought only have just the kernel and networking/storage as > different repo it would > not have grown up? > > What is the real concern? Maintenance? > > > I think the original DPDK repository should focus on low-level features > > which offer hardware offloads and optimizations. > > The nodes can be vendor-specific to optimize the specific use cases. > As I mentioned in the cover letter, > > " > 2) Based on our experience, NPU HW accelerates are so different than one > vendor > to another vendor. Going forward, We believe, API abstraction may not be > enough > abstract the difference in HW. The Vendor-specific nodes can abstract the HW > differences and reuse generic the nodes as needed. > This would help both the silicon vendors and DPDK end users. > " > > Thoughts from other folks? > > > > Consuming the low-level API in different abstractions, > > and building applications, should be done on top of dpdk.git. > > > >
Re: [dpdk-dev] [PATCH] doc: plan splitting the ethdev ops struct
On 2/18/2020 6:01 AM, Stephen Hemminger wrote: > On Mon, 17 Feb 2020 15:38:05 + > Ferruh Yigit wrote: > >> For the ABI compatibility it is better to hide internal data structures >> from the application as much as possible. But because of some inline >> functions 'struct eth_dev_ops' can't be hidden completely. >> >> Plan is to split the 'struct eth_dev_ops' into two as ones used by >> inline functions and ones not used, and hide the second part that not >> used by inline functions completely to the application. >> >> Signed-off-by: Ferruh Yigit >> --- >> Cc: David Marchand >> Cc: Thomas Monjalon >> Cc: Andrew Rybchenko >> --- >> 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 dfcca87ab..2aa431028 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -72,6 +72,12 @@ Deprecation Notices >>In 19.11 PMDs will still update the field even when the offload is not >>enabled. >> >> +* ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as >> possible. >> + Currently the ``struct eth_dev_ops`` struct is accessible by the >> application >> + because some inline functions, like ``rte_eth_tx_descriptor_status()``, >> + access the struct directly. The struct will be separate in two, the ops >> used >> + by inline functions still will be accessible to user but rest will be >> hidden. >> + >> * cryptodev: support for using IV with all sizes is added, J0 still can >>be used but only when IV length in following structs >> ``rte_crypto_auth_xform``, >>``rte_crypto_aead_xform`` is set to zero. When IV length is greater or >> equal > > Good luck, truely hiding internals is hard. The mbuf structure is already > split but not really > hidden at all (just look at dwarf output). It doesn't make sense to do it > unless > you can really hide it. I believe this can be done, only following [1] dev_ops are used by inline functions, rest can be moved into separate struct and moved into ethdev driver looking header. [1] rx_queue_count rx_descriptor_done rx_descriptor_status tx_descriptor_status > > I would attack the rte_device stuff first. Make rte_device opaque to the > application > that would help for future versions. Then work backwards to rte_tehtdev. >
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
21/02/2020 11:30, Jerin Jacob: > On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: > > On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon wrote: > > Thanks for starting this discussion now. It is an interesting > > discussion. Some thoughts below. > > We can decide based on community consensus and follow a single rule > > across the components. > > Thomas, > > No feedback yet on the below questions. Indeed. I was waiting for opininons from others. > If there no consensus in the email, I would like to propose this topic > to the 26th Feb TB meeting. I gave my opinion below. If a consensus cannot be reached, I agree with the request to the techboard. > > > 17/02/2020 08:19, Jerin Jacob: > > > > I got initial comments from Ray and Stephen on this RFC[1]. Thanks for > > > > the comments. > > > > > > > > Is anyone else planning to have an architecture level or API usage > > > > level review or any review of other top-level aspects? > > > > > > If we add rte_graph to DPDK, we will have 2 similar libraries. > > > > > > I already proposed several times to move rte_pipeline in a separate > > > repository for two reasons: > > > 1/ it is acting at a higher API layer level > > > > We need to define what is the higher layer API. Is it processing beyond L2? My opinion is that any API which is implemented differently for different hardware should be in DPDK. Hardware devices can offload protocol processing higher than L2, so L2 does not look to be a good limit from my point of view. > > In the context of Graph library, it is a framework, not using any of > > the substem API > > other than EAL and it is under lib/librte_graph. > > Nodes library using graph and other subsystem components such as ethdev and > > it is under lib/lib_node/ > > > > > > Another interesting question would what would be an issue in DPDK supporting > > beyond L2. Or higher level protocols? Definitely higher than L2 is OK in DPDK as long as it is related to hardware capabilities, not software stack (which can be a DPDK application). > > > 2/ there can be different solutions in this layer > > > > Is there any issue with that? > > There is overlap with the distributor library and eventdev as well. > > ethdev and SW traffic manager libraries as well. That list goes on. I don't know how much it is an issue. But I think it shows that at least one implementation is not generic enough. > > > I think 1/ was commonly agreed in the community. > > > Now we see one more proof of the reason 2/. > > > > > > I believe it is time to move rte_pipeline (Packet Framework) > > > in a separate repository, and welcome rte_graph as well in another > > > separate repository. > > > > What would be gain out of this? The gain is to be clear about what should be the focus for contributors working on the main DPDK repository. What is expected to be maintained, tested, etc. > > My concerns are: > > # Like packet-gen, The new code will be filled with unnecessary DPDK > > version checks > > and unnecessary compatibility issues. > > # Anything is not in main dpdk repo, it is a second class citizen. > > # Customer has the pain to use two repos and two releases. Internally, > > it can be two different > > repo but release needs to go through one repo. > > > > If we are focusing ONLY on the driver API then how can DPDK grow > > further? If linux kernel > > would be thought only have just the kernel and networking/storage as > > different repo it would > > not have grown up? Linux kernel is selecting what can enter in the focus or not. And I wonder what is the desire of extending/growing the scope of a library? > > What is the real concern? Maintenance? > > > > > I think the original DPDK repository should focus on low-level features > > > which offer hardware offloads and optimizations. > > > > The nodes can be vendor-specific to optimize the specific use cases. > > As I mentioned in the cover letter, > > > > " > > 2) Based on our experience, NPU HW accelerates are so different than one > > vendor > > to another vendor. Going forward, We believe, API abstraction may not be > > enough > > abstract the difference in HW. The Vendor-specific nodes can abstract the HW > > differences and reuse generic the nodes as needed. > > This would help both the silicon vendors and DPDK end users. > > " > > > > Thoughts from other folks? > > > > > > > Consuming the low-level API in different abstractions, > > > and building applications, should be done on top of dpdk.git.
Re: [dpdk-dev] [RFC] service: stop lcore threads before 'finalize'
> -Original Message- > From: David Marchand > Sent: Thursday, February 20, 2020 1:25 PM > To: Van Haaren, Harry > Cc: Aaron Conole ; dev > Subject: Re: [RFC] service: stop lcore threads before 'finalize' > > On Mon, Feb 10, 2020 at 3:16 PM Van Haaren, Harry > wrote: > > > > We need a fix for this issue. > > > > > > +1 > > > > > > Interestingly, Stephen patch that joins all pthreads at > > > > rte_eal_cleanup [1] makes this issue disappear. > > > > So my understanding is that we are missing a api (well, I could not > > > > find a way) to synchronously stop service lcores. > > > > > > Maybe we can take that patch as a fix. I hate to see this segfault > > > in the field. I need to figure out what I missed in my cleanup > > > (probably missed a synchronization point). > > > > I haven't easily reproduced this yet - so I'll investigate a way to > > reproduce with close to 100% rate, then we can identify the root cause > > and actually get a clean fix. If you have pointers to reproduce easily, > > please let me know. > > > > ping. > I want a fix in 20.05, or I will start considering how to drop this thing. Hi David, I have been attempting to reproduce, unfortunately without success. Attempted you suggested meson test approach (thanks for suggesting!), but I haven't had a segfault with that approach (yet, and its done a lot of iterations..) I've made the service-cores unit tests delay before exit, in an attempt to have them access previously rte_free()-ed memory, no luck to reproduce. Thinking perhaps we need it on exit, I've also POCed a unit test that leaves service cores active on exit on purpose, to try have them poll after exit, still no luck. Simplifying the problem, and using hello-world sample app with a rte_eal_cleaup() call at the end also doesn't easily aggravate the problem. From code inspection, I agree there is an issue. It seems like a call to rte_service_lcore_reset_all() from rte_service_finalize() is enough... But without reproducing it is hard to have good confidence in a fix. If you have cycles to help, investigating if the above reset_all() call fixes there? Otherwise I'll continue trying to reproduce reliably. Regards, -HvH
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
On 20/02/2020 19:54, Ferruh Yigit wrote:
> The problem occurred when workaround that makes soname two digits
> applied. With this change for the ABI version "20.0.1" the experimental
> library version become ".so.2001".
> After workaround removed in ABI version 21.0, the experimental library
> version will become ".so.210".
> "2001" is bigger value than "201" although it is a previous version of
> the library version, this can break the version comparisons.
>
> To fix this, introducing a temporary sub level versioning for the
> experimental libraries, so that minor version comparison will continue
> to work.
>
> After change experimental libraries will follow below versioning:
>
> DPDK version ABI version soname library name
> --- --
> DPDK 19.11 20.0.so.0.200.so.0.200
> DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1
> DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2
> DPDK 20.11 21.0.so.0.210.so.0.210
> DPDK 21.02 21.1.so.0.211.so.0.211
>
> Note: After workaround removed in DPDK 20.11 and soname switch back to
> single digit this patch won't work and needs to be updated.
>
> Fixes: f26c2b39b271 ("build: fix soname info for 19.11 compatibility")
>
Acked-by: Ray Kinsella
> Signed-off-by: Ferruh Yigit
> ---
> Cc: Thomas Monjalon
> Cc: ray.kinse...@intel.com
> Cc: nhor...@tuxdriver.com
> Cc: bruce.richard...@intel.com
> Cc: bl...@debian.org
> Cc: david.march...@redhat.com
> Cc: ktray...@redhat.com
> ---
> config/meson.build | 4 ++--
> mk/rte.lib.mk | 8 +---
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/config/meson.build b/config/meson.build
> index 6c46767e3..d3d2370ce 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -31,8 +31,8 @@ abi_version = run_command(find_program('cat', 'more'),
> # sonames => librte_stable.so.20.0, librte_experimental.so.0.200
> abi_va = abi_version.split('.')
> stable_so_version = abi_va.length() == 2 ? abi_va[0] : abi_va[0] + '.' +
> abi_va[1]
> -experimental_abi_version = '0.' + ''.join(abi_va)
> -experimental_so_version = '0.' + ''.join(stable_so_version.split('.'))
> +experimental_abi_version = '0.' + abi_va[0] + abi_va[1] + '.' + abi_va[2]
> +experimental_so_version = experimental_abi_version
>
> # extract all version information into the build configuration
> dpdk_conf.set('RTE_VER_YEAR', pver.get(0).to_int())
> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
> index b1a8372cc..682b590db 100644
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -15,8 +15,8 @@ LIBABIVER ?= $(shell cat $(RTE_SRCDIR)/ABI_VERSION)
> SOVER := $(basename $(LIBABIVER))
> ifeq ($(shell grep -s "^DPDK_" $(SRCDIR)/$(EXPORT_MAP)),)
> # EXPERIMENTAL ABI is versioned as 0.major+minor, e.g. 0.201 for 20.1 ABI
> -LIBABIVER := 0.$(shell echo $(LIBABIVER) | tr -d '.')
> -SOVER := 0.$(shell echo $(SOVER) | tr -d '.')
> +LIBABIVER := 0.$(shell echo $(LIBABIVER) | awk 'BEGIN { FS="." }; { print
> $$1$$2"."$$3 }')
> +SOVER := $(LIBABIVER)
> endif
>
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> @@ -135,7 +135,9 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
> $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
> - $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so.$(SOVER)/')
> + $(Q)if [ $(SOVER) != $(LIBABIVER) ]; then \
> + ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so.$(SOVER)/') ; \
> + fi
> endif
>
> #
>
[dpdk-dev] [PATCH] maintainers: resign from virtio and vhost
I'm leaving Intel, and I'm not sure when I could dedicate enough time to DPDK in the future. So I'm removing my name from the MAINTAINERS file. Signed-off-by: Tiwei Bie --- Xiaolong has been an active and experienced -next tree maintainer for a long time. He also knows and loves virtio/vhost. I would recommend him as my replacement. --- I really appreciate the helps and supports from Maxime, Zhihong, Thomas and the community! Thank you all so much! MAINTAINERS | 4 1 file changed, 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 762c13bd6..9c22c3eb4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -51,7 +51,6 @@ T: git://dpdk.org/next/dpdk-next-net-mlx Next-virtio Tree M: Maxime Coquelin -M: Tiwei Bie T: git://dpdk.org/next/dpdk-next-virtio Next-crypto Tree @@ -855,7 +854,6 @@ F: doc/guides/nics/features/vmxnet3.ini Vhost-user M: Maxime Coquelin -M: Tiwei Bie M: Zhihong Wang T: git://dpdk.org/next/dpdk-next-virtio F: lib/librte_vhost/ @@ -870,7 +868,6 @@ F: doc/guides/sample_app_ug/vdpa.rst Vhost PMD M: Maxime Coquelin -M: Tiwei Bie M: Zhihong Wang T: git://dpdk.org/next/dpdk-next-virtio F: drivers/net/vhost/ @@ -879,7 +876,6 @@ F: doc/guides/nics/features/vhost.ini Virtio PMD M: Maxime Coquelin -M: Tiwei Bie M: Zhihong Wang T: git://dpdk.org/next/dpdk-next-virtio F: drivers/net/virtio/ -- 2.24.1
Re: [dpdk-dev] [PATCH] maintainers: resign from virtio and vhost
21/02/2020 14:28, Tiwei Bie: > I'm leaving Intel, and I'm not sure when I could dedicate enough > time to DPDK in the future. So I'm removing my name from the > MAINTAINERS file. > > Signed-off-by: Tiwei Bie > --- > Xiaolong has been an active and experienced -next tree maintainer > for a long time. He also knows and loves virtio/vhost. I would > recommend him as my replacement. > > --- > I really appreciate the helps and supports from Maxime, Zhihong, > Thomas and the community! Thank you all so much! Thanks Tiwei, your work is very appreciated. You will be welcome to be back at any time :-)
Re: [dpdk-dev] [RFC 00/12] introduce s390x architecture
Sorry for the delayed reply. We are working on updating the port to a newer version. We'd like to ask for feedback when it's ready. Regards, Vivian Kong Linux on IBM Z Open Source Ecosystem IBM Canada Toronto Lab Thomas Monjalon wrote on 2020/02/18 04:03:27 PM: > From: Thomas Monjalon > To: Vivian Kong > Cc: dev@dpdk.org, Pradeep Satyanarayana , David > Christensen , David Wilder > Date: 2020/02/18 04:03 PM > Subject: [EXTERNAL] Re: [dpdk-dev] [RFC 00/12] introduce s390x architecture > > Hi, > > 09/04/2019 21:06, Vivian Kong: > > To build and run DPDK on Linux on IBM Z (s390x), big endian support > > is added and s390x vector intrinics are used in the implementation > > of DPDK libraries. > > What is the status of this work? > Is it abandoned? > >
[dpdk-dev] [PATCH] maintainers: update for virtio and vhost
I volunteer to be co-maintainer for Vhost-user/Vhost PMD/Virtio PMD. Signed-off-by: Xiaolong Ye --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9c22c3eb4..8e5d18235 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -855,6 +855,7 @@ F: doc/guides/nics/features/vmxnet3.ini Vhost-user M: Maxime Coquelin M: Zhihong Wang +M: Xiaolong Ye T: git://dpdk.org/next/dpdk-next-virtio F: lib/librte_vhost/ F: doc/guides/prog_guide/vhost_lib.rst @@ -869,6 +870,7 @@ F: doc/guides/sample_app_ug/vdpa.rst Vhost PMD M: Maxime Coquelin M: Zhihong Wang +M: Xiaolong Ye T: git://dpdk.org/next/dpdk-next-virtio F: drivers/net/vhost/ F: doc/guides/nics/vhost.rst @@ -877,6 +879,7 @@ F: doc/guides/nics/features/vhost.ini Virtio PMD M: Maxime Coquelin M: Zhihong Wang +M: Xiaolong Ye T: git://dpdk.org/next/dpdk-next-virtio F: drivers/net/virtio/ F: doc/guides/nics/virtio.rst -- 2.17.1
Re: [dpdk-dev] [PATCH] maintainers: resign from virtio and vhost
On Fri, Feb 21, 2020 at 02:34:42PM +0100, Thomas Monjalon wrote: > 21/02/2020 14:28, Tiwei Bie: > > I'm leaving Intel, and I'm not sure when I could dedicate enough > > time to DPDK in the future. So I'm removing my name from the > > MAINTAINERS file. > > > > Signed-off-by: Tiwei Bie > > --- > > Xiaolong has been an active and experienced -next tree maintainer > > for a long time. He also knows and loves virtio/vhost. I would > > recommend him as my replacement. > > > > --- > > I really appreciate the helps and supports from Maxime, Zhihong, > > Thomas and the community! Thank you all so much! > > Thanks Tiwei, your work is very appreciated. > You will be welcome to be back at any time :-) Thanks! I really appreciate that! :-) Best regards, Tiwei
Re: [dpdk-dev] [PATCH] maintainers: update for virtio and vhost
On Fri, Feb 21, 2020 at 09:35:39PM +0800, Xiaolong Ye wrote: > I volunteer to be co-maintainer for Vhost-user/Vhost PMD/Virtio PMD. > > Signed-off-by: Xiaolong Ye > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) Thanks Xiaolong for being willing to contribute on virtio and vhost with your expertise and passion. Acked-by: Tiwei Bie Thanks, Tiwei > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9c22c3eb4..8e5d18235 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -855,6 +855,7 @@ F: doc/guides/nics/features/vmxnet3.ini > Vhost-user > M: Maxime Coquelin > M: Zhihong Wang > +M: Xiaolong Ye > T: git://dpdk.org/next/dpdk-next-virtio > F: lib/librte_vhost/ > F: doc/guides/prog_guide/vhost_lib.rst > @@ -869,6 +870,7 @@ F: doc/guides/sample_app_ug/vdpa.rst > Vhost PMD > M: Maxime Coquelin > M: Zhihong Wang > +M: Xiaolong Ye > T: git://dpdk.org/next/dpdk-next-virtio > F: drivers/net/vhost/ > F: doc/guides/nics/vhost.rst > @@ -877,6 +879,7 @@ F: doc/guides/nics/features/vhost.ini > Virtio PMD > M: Maxime Coquelin > M: Zhihong Wang > +M: Xiaolong Ye > T: git://dpdk.org/next/dpdk-next-virtio > F: drivers/net/virtio/ > F: doc/guides/nics/virtio.rst > -- > 2.17.1 >
Re: [dpdk-dev] Dependency issue between event/dpaa and crypto/dpaa_sec
On Thu, Feb 13, 2020 at 1:16 PM David Marchand wrote: > > On Thu, Feb 13, 2020 at 1:07 PM Hemant Agrawal wrote: > > > I could not find a dependency in the makefiles for this. > > > But meson has this dependency. > > > > > > drivers/event/dpaa/meson.build > > > deps += ['pmd_dpaa', 'pmd_dpaa_sec'] > > > > > > > > [Hemant] Makefile do have dependency set, but at a different place. I have > > done a small change. Please check if you can : > > I must have missed it then. > Can you describe how this dependency is expressed in the makefiles? > > > > > diff --git a/drivers/event/dpaa/Makefile b/drivers/event/dpaa/Makefile > > index 2f53efdf9e..093d3a38cf 100644 > > --- a/drivers/event/dpaa/Makefile > > +++ b/drivers/event/dpaa/Makefile > > @@ -21,8 +21,6 @@ CFLAGS += -I$(RTE_SDK)/drivers/bus/dpaa/include/ > > CFLAGS += -I$(RTE_SDK)/drivers/mempool/dpaa > > CFLAGS += -I$(RTE_SDK)/drivers/common/dpaax > > CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/include > > - > > -LDLIBS += -lrte_pmd_dpaa_sec > > CFLAGS += -I$(RTE_SDK)/drivers/crypto/dpaa_sec > > > > EXPORT_MAP := rte_pmd_dpaa_event_version.map > > @@ -34,6 +32,7 @@ LDLIBS += -lrte_bus_dpaa > > LDLIBS += -lrte_mempool_dpaa > > LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring > > LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs > > +LDLIBS += -lrte_pmd_dpaa_sec > > LDLIBS += -lrte_eventdev -lrte_pmd_dpaa -lrte_bus_vdev > > LDLIBS += -lrte_common_dpaax > > I don't see how this would affect the building order between > drivers/event/dpaa and drivers/crypto/dpaa_sec. Just hit it again, on master. I am simply running ./devtools/test-builds.sh with: export DPDK_MAKE_JOBS=28 target i686-native-linux-gcc+shared+debug+default LD librte_pmd_dpaa2_event.so.20.0.1 LD dpaa_eventdev.o /usr/bin/ld: cannot find -lrte_pmd_dpaa2_sec collect2: error: ld returned 1 exit status gmake[4]: *** [/home/dmarchan/dpdk/mk/rte.lib.mk:100: librte_pmd_dpaa2_event.so.20.0.1] Error 1 gmake[3]: *** [/home/dmarchan/dpdk/mk/rte.subdir.mk:35: dpaa2] Error 2 gmake[3]: *** Waiting for unfinished jobs LD librte_pmd_sw_event.so.20.0.1 LD librte_pmd_dpaa_event.so.20.0.1 /usr/bin/ld: cannot find -lrte_pmd_dpaa_sec collect2: error: ld returned 1 exit status gmake[4]: *** [/home/dmarchan/dpdk/mk/rte.lib.mk:100: librte_pmd_dpaa_event.so.20.0.1] Error 1 gmake[3]: *** [/home/dmarchan/dpdk/mk/rte.subdir.mk:35: dpaa] Error 2 INSTALL-LIB librte_pmd_sw_event.so.20.0.1 LD librte_pmd_octeontx_ssovf.so.20.0.1 INSTALL-LIB librte_pmd_octeontx_ssovf.so.20.0.1 PMDINFO dpaa_sec.o.pmd.c CC dpaa_sec.o.pmd.o LD dpaa_sec.o PMDINFO dpaa2_sec_dpseci.o.pmd.c CC dpaa2_sec_dpseci.o.pmd.o LD librte_pmd_dpaa_sec.so.20.0.1 LD dpaa2_sec_dpseci.o INSTALL-LIB librte_pmd_dpaa_sec.so.20.0.1 LD librte_pmd_dpaa2_sec.so.20.0.1 INSTALL-LIB librte_pmd_dpaa2_sec.so.20.0.1 LD librte_pmd_ccp.so.20.0.1 INSTALL-LIB librte_pmd_ccp.so.20.0.1 LD librte_pmd_opdl_event.so.20.0.1 -- David Marchand
Re: [dpdk-dev] [PATCH] maintainers: update for virtio and vhost
> -Original Message- > From: Ye, Xiaolong > Sent: Friday, February 21, 2020 9:36 PM > To: dev@dpdk.org > Cc: maxime.coque...@redhat.com; Wang, Zhihong > ; Bie, Tiwei ; > tho...@monjalon.net; Ye, Xiaolong > Subject: [PATCH] maintainers: update for virtio and vhost > > I volunteer to be co-maintainer for Vhost-user/Vhost PMD/Virtio PMD. > > Signed-off-by: Xiaolong Ye > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) Thanks Xiaolong for your passion! Acked-by: Zhihong Wang > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9c22c3eb4..8e5d18235 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -855,6 +855,7 @@ F: doc/guides/nics/features/vmxnet3.ini > Vhost-user > M: Maxime Coquelin > M: Zhihong Wang > +M: Xiaolong Ye > T: git://dpdk.org/next/dpdk-next-virtio > F: lib/librte_vhost/ > F: doc/guides/prog_guide/vhost_lib.rst > @@ -869,6 +870,7 @@ F: doc/guides/sample_app_ug/vdpa.rst > Vhost PMD > M: Maxime Coquelin > M: Zhihong Wang > +M: Xiaolong Ye > T: git://dpdk.org/next/dpdk-next-virtio > F: drivers/net/vhost/ > F: doc/guides/nics/vhost.rst > @@ -877,6 +879,7 @@ F: doc/guides/nics/features/vhost.ini > Virtio PMD > M: Maxime Coquelin > M: Zhihong Wang > +M: Xiaolong Ye > T: git://dpdk.org/next/dpdk-next-virtio > F: drivers/net/virtio/ > F: doc/guides/nics/virtio.rst > -- > 2.17.1
Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
David Marchand writes: > On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang wrote: >> >> [AMD Official Use Only - Internal Distribution Only] > > Please, get this header removed. > This is a public mailing list. > > >> Thanks Thomas for bringing this up. >> I consider this is not a new feature, but rather a fix to address >> the issue with statically assigned maximum lcore limit on >> high-density CPU platform such as AMD Epyc. >> As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11, >> and they have 1~2 yrs of lifetime left, we like to backport this to >> LTS 18.11 & 19.11 at least. > > It is not a fix. > > The use of static arrays is a design choice that goes back to the > early days in dpdk. > The addition of --lcores came in after this, but it was introduced for > a different use case than placing lcores on any physical core. > And there was no claim that a core > RTE_MAX_LCORE would be usable. > > > When testing on a new hardware, it is normal to observe some limitations. > Running DPDK on those platforms should be possible: "should be" > because I do not have access to this hardware and saw neither tests > reports nor performance numbers. > Before this patch, the limitation is that on Epyc, cores > > RTE_MAX_LCORE are not usable. > > > Now, this change is quite constrained. > If we backport it, I don't expect issues in the main dpdk components > (based on code review and ovs tests with a RTE_MAX_LCORE set to 16 on > a 24 cores system). > There might be issues in some examples or not widely used library > which uses a physical core id instead of a lcore id. > > > This is the same recurring question "do we allow new features in a > stable branch?". Usually, the answer is 'no'. But we do allow some "new" things to be backported (pci ids, etc) that might be required to enable older functionality. Additionally, I'm sure if some feature were required to mitigate a CVE, we'd rather favor backporting it. I guess we could pose a litmus test: 1. Is the problem this feature solves so widespread that it needs to be addressed ASAP? 2. Is there a known workaround to the problem this is solving? 3. How intrusive is the feature? 4. Is it shown to be stable in the mainline (number of fixes, testing, etc)? 5. Is it constrained enough that we know we can support it with even higher priority than other things? Probably other questions that will need to be asked. And even in that list of question, I'm not sure I'd be able to advocate backporting this in the upstream branches - it hasn't had much testing. It's unstable. It's "difficult" to use. It is not widespread that people have so many cores. The workaround is much simpler than supporting this (recompile). > > -- > David Marchand
[dpdk-dev] [PATCH] doc: fix naming of Mellanox devices
The devices of the family ConnectX may have two letters as suffix. Such suffix is preceded with a space and the second x is lowercase: - ConnectX-4 Lx - ConnectX-5 Ex - ConnectX-6 Dx Uppercase of the device family name BlueField is also fixed. Signed-off-by: Thomas Monjalon --- config/common_base | 4 ++-- doc/guides/nics/mlx5.rst | 24 doc/guides/rel_notes/release_18_08.rst | 2 +- doc/guides/rel_notes/release_19_02.rst | 2 +- doc/guides/rel_notes/release_19_11.rst | 2 +- doc/guides/vdpadevs/mlx5.rst | 6 +++--- drivers/net/mlx5/mlx5.c| 2 +- drivers/net/mlx5/mlx5_rxtx.c | 2 +- drivers/net/mlx5/mlx5_txq.c| 2 +- 9 files changed, 23 insertions(+), 23 deletions(-) diff --git a/config/common_base b/config/common_base index 6ea9c63cc3..7ca2f28b19 100644 --- a/config/common_base +++ b/config/common_base @@ -361,13 +361,13 @@ CONFIG_RTE_LIBRTE_MLX4_DEBUG=n # # Compile burst-oriented Mellanox ConnectX-4, ConnectX-5, -# ConnectX-6 & Bluefield (MLX5) PMD +# ConnectX-6 & BlueField (MLX5) PMD # CONFIG_RTE_LIBRTE_MLX5_PMD=n CONFIG_RTE_LIBRTE_MLX5_DEBUG=n # -# Compile vdpa-oriented Mellanox ConnectX-6 & Bluefield (MLX5) PMD +# Compile vdpa-oriented Mellanox ConnectX-6 & BlueField (MLX5) PMD # CONFIG_RTE_LIBRTE_MLX5_VDPA_PMD=n diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 5ab7c07165..748a87d8f3 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -7,7 +7,7 @@ MLX5 poll mode driver The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support for **Mellanox ConnectX-4**, **Mellanox ConnectX-4 Lx** , **Mellanox -ConnectX-5**, **Mellanox ConnectX-6**, **Mellanox ConnectX-6DX** and +ConnectX-5**, **Mellanox ConnectX-6**, **Mellanox ConnectX-6 Dx** and **Mellanox BlueField** families of 10/25/40/50/100/200 Gb/s adapters as well as their virtual functions (VF) in SR-IOV context. @@ -324,9 +324,9 @@ Run-time configuration Supported on: - - x86_64 with ConnectX-4, ConnectX-4 LX, ConnectX-5, ConnectX-6, ConnectX-6 DX + - x86_64 with ConnectX-4, ConnectX-4 Lx, ConnectX-5, ConnectX-6, ConnectX-6 Dx and BlueField. - - POWER9 and ARMv8 with ConnectX-4 LX, ConnectX-5, ConnectX-6, ConnectX-6 DX + - POWER9 and ARMv8 with ConnectX-4 Lx, ConnectX-5, ConnectX-6, ConnectX-6 Dx and BlueField. - ``rxq_cqe_pad_en`` parameter [int] @@ -357,9 +357,9 @@ Run-time configuration Supported on: - - x86_64 with ConnectX-4, ConnectX-4 LX, ConnectX-5, ConnectX-6, ConnectX-6 DX + - x86_64 with ConnectX-4, ConnectX-4 Lx, ConnectX-5, ConnectX-6, ConnectX-6 Dx and BlueField. - - POWER8 and ARMv8 with ConnectX-4 LX, ConnectX-5, ConnectX-6, ConnectX-6 DX + - POWER8 and ARMv8 with ConnectX-4 Lx, ConnectX-5, ConnectX-6, ConnectX-6 Dx and BlueField. - ``mprq_en`` parameter [int] @@ -462,14 +462,14 @@ Run-time configuration If ``txq_inline_min`` key is not present, the value may be queried by the driver from the NIC via DevX if this feature is available. If there is no DevX enabled/supported the value 18 (supposing L2 header including VLAN) is set - for ConnectX-4 and ConnectX-4LX, and 0 is set by default for ConnectX-5 + for ConnectX-4 and ConnectX-4 Lx, and 0 is set by default for ConnectX-5 and newer NICs. If packet is shorter the ``txq_inline_min`` value, the entire packet is inlined. For ConnectX-4 NIC, driver does not allow specifying value below 18 (minimal L2 header, including VLAN), error will be raised. - For ConnectX-4LX NIC, it is allowed to specify values below 18, but + For ConnectX-4 Lx NIC, it is allowed to specify values below 18, but it is not recommended and may prevent NIC from sending packets over some configurations. @@ -552,7 +552,7 @@ Run-time configuration - ``txq_mpw_en`` parameter [int] A nonzero value enables Enhanced Multi-Packet Write (eMPW) for ConnectX-5, - ConnectX-6, ConnectX-6 DX and BlueField. eMPW allows the TX burst function to pack + ConnectX-6, ConnectX-6 Dx and BlueField. eMPW allows the TX burst function to pack up multiple packets in a single descriptor session in order to save PCI bandwidth and improve performance at the cost of a slightly higher CPU usage. When ``txq_inline_mpw`` is set along with ``txq_mpw_en``, TX burst function copies @@ -598,7 +598,7 @@ Run-time configuration - ``tx_vec_en`` parameter [int] - A nonzero value enables Tx vector on ConnectX-5, ConnectX-6, ConnectX-6 DX + A nonzero value enables Tx vector on ConnectX-5, ConnectX-6, ConnectX-6 Dx and BlueField NICs if the number of global Tx queues on the port is less than ``txqs_max_vec``. The parameter is deprecated and ignored. @@ -899,7 +899,7 @@ Mellanox OFED/EN - ConnectX-5: **16.21.1000** and above. - ConnectX-5 Ex: **16.21.1000** and above. - ConnectX-6: **20.99.5374** and above. - - ConnectX-6 DX: **22.
Re: [dpdk-dev] [PATCH] maintainers: resign from virtio and vhost
> -Original Message- > From: Bie, Tiwei > Sent: Friday, February 21, 2020 9:29 PM > To: dev@dpdk.org > Cc: maxime.coque...@redhat.com; Wang, Zhihong > ; tho...@monjalon.net > Subject: [PATCH] maintainers: resign from virtio and vhost > > I'm leaving Intel, and I'm not sure when I could dedicate enough > time to DPDK in the future. So I'm removing my name from the > MAINTAINERS file. > > Signed-off-by: Tiwei Bie > --- > Xiaolong has been an active and experienced -next tree maintainer > for a long time. He also knows and loves virtio/vhost. I would > recommend him as my replacement. > > --- > I really appreciate the helps and supports from Maxime, Zhihong, > Thomas and the community! Thank you all so much! Tiwei, Thanks for your brilliant work in DPDK over the past years. All the best! > > MAINTAINERS | 4 > 1 file changed, 4 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 762c13bd6..9c22c3eb4 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -51,7 +51,6 @@ T: git://dpdk.org/next/dpdk-next-net-mlx > > Next-virtio Tree > M: Maxime Coquelin > -M: Tiwei Bie > T: git://dpdk.org/next/dpdk-next-virtio > > Next-crypto Tree > @@ -855,7 +854,6 @@ F: doc/guides/nics/features/vmxnet3.ini > > Vhost-user > M: Maxime Coquelin > -M: Tiwei Bie > M: Zhihong Wang > T: git://dpdk.org/next/dpdk-next-virtio > F: lib/librte_vhost/ > @@ -870,7 +868,6 @@ F: doc/guides/sample_app_ug/vdpa.rst > > Vhost PMD > M: Maxime Coquelin > -M: Tiwei Bie > M: Zhihong Wang > T: git://dpdk.org/next/dpdk-next-virtio > F: drivers/net/vhost/ > @@ -879,7 +876,6 @@ F: doc/guides/nics/features/vhost.ini > > Virtio PMD > M: Maxime Coquelin > -M: Tiwei Bie > M: Zhihong Wang > T: git://dpdk.org/next/dpdk-next-virtio > F: drivers/net/virtio/ > -- > 2.24.1
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
On Thu, Feb 20, 2020 at 8:55 PM Ferruh Yigit wrote:
>
> The problem occurred when workaround that makes soname two digits
> applied. With this change for the ABI version "20.0.1" the experimental
> library version become ".so.2001".
> After workaround removed in ABI version 21.0, the experimental library
> version will become ".so.210".
> "2001" is bigger value than "201" although it is a previous version of
> the library version, this can break the version comparisons.
>
> To fix this, introducing a temporary sub level versioning for the
> experimental libraries, so that minor version comparison will continue
> to work.
>
> After change experimental libraries will follow below versioning:
>
> DPDK version ABI version soname library name
> --- --
> DPDK 19.11 20.0.so.0.200.so.0.200
> DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1
> DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2
> DPDK 20.11 21.0.so.0.210.so.0.210
> DPDK 21.02 21.1.so.0.211.so.0.211
>
> Note: After workaround removed in DPDK 20.11 and soname switch back to
> single digit this patch won't work and needs to be updated.
>
> Fixes: f26c2b39b271 ("build: fix soname info for 19.11 compatibility")
>
> Signed-off-by: Ferruh Yigit
The soname change breaks existing applications like testpmd (linked to
various experimental libraries).
I have the full details if needed in a pastebin (v19.11, master, patch_applied).
$ LD_LIBRARY_PATH=$HOME/builds/x86_64-native-linux-gcc+shared+kmods/install/lib
$HOME/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd
/home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd:
error while loading shared libraries: librte_flow_classify.so.0.200:
cannot open shared object file: No such file or directory
libabigail reports this change as an error, so if it is intended, we
need to bypass the check for those libraries.
Functions changes summary: 0 Removed, 0 Changed (2 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed (7 filtered out), 0
Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
SONAME changed from 'librte_flow_classify.so.0.200' to
'librte_flow_classify.so.0.200.1'
Error: ABI issue reported for 'abidiff --suppr
/home/dmarchan/dpdk/devtools/libabigail.abignore --no-added-syms
--headers-dir1
/home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/include
--headers-dir2
/home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/include
/home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/dump/librte_flow_classify.dump
/home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/dump/librte_flow_classify.dump'
--
David Marchand
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
On 2/21/2020 3:24 PM, David Marchand wrote:
> On Thu, Feb 20, 2020 at 8:55 PM Ferruh Yigit wrote:
>>
>> The problem occurred when workaround that makes soname two digits
>> applied. With this change for the ABI version "20.0.1" the experimental
>> library version become ".so.2001".
>> After workaround removed in ABI version 21.0, the experimental library
>> version will become ".so.210".
>> "2001" is bigger value than "201" although it is a previous version of
>> the library version, this can break the version comparisons.
>>
>> To fix this, introducing a temporary sub level versioning for the
>> experimental libraries, so that minor version comparison will continue
>> to work.
>>
>> After change experimental libraries will follow below versioning:
>>
>> DPDK version ABI version soname library name
>> --- --
>> DPDK 19.11 20.0.so.0.200.so.0.200
>> DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1
>> DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2
>> DPDK 20.11 21.0.so.0.210.so.0.210
>> DPDK 21.02 21.1.so.0.211.so.0.211
>>
>> Note: After workaround removed in DPDK 20.11 and soname switch back to
>> single digit this patch won't work and needs to be updated.
>>
>> Fixes: f26c2b39b271 ("build: fix soname info for 19.11 compatibility")
>>
>> Signed-off-by: Ferruh Yigit
>
> The soname change breaks existing applications like testpmd (linked to
> various experimental libraries).
> I have the full details if needed in a pastebin (v19.11, master,
> patch_applied).
>
> $
> LD_LIBRARY_PATH=$HOME/builds/x86_64-native-linux-gcc+shared+kmods/install/lib
> $HOME/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd
> /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/bin/testpmd:
> error while loading shared libraries: librte_flow_classify.so.0.200:
> cannot open shared object file: No such file or directory
>
>
> libabigail reports this change as an error, so if it is intended, we
> need to bypass the check for those libraries.
soname change was intended, we don't provide any ABI compatibility in the
experimental libraries, keeping same soname may mislead as if we do.
The impact of it is, any application linked against experimental library will
need to recompile in new release.
Can we add exception to the the libabigail for experimental libraries?
>
> Functions changes summary: 0 Removed, 0 Changed (2 filtered out), 0
> Added functions
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> ELF SONAME changed
> Functions changes summary: 0 Removed, 0 Changed (7 filtered out), 0
> Added functions
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> SONAME changed from 'librte_flow_classify.so.0.200' to
> 'librte_flow_classify.so.0.200.1'
> Error: ABI issue reported for 'abidiff --suppr
> /home/dmarchan/dpdk/devtools/libabigail.abignore --no-added-syms
> --headers-dir1
> /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/include
> --headers-dir2
> /home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/include
> /home/dmarchan/abi/v19.11/x86_64-native-linux-gcc+shared+kmods/dump/librte_flow_classify.dump
> /home/dmarchan/builds/x86_64-native-linux-gcc+shared+kmods/install/dump/librte_flow_classify.dump'
>
>
>
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
On 2020-02-21 12:10, Thomas Monjalon wrote: > 21/02/2020 11:30, Jerin Jacob: >> On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: >>> On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon wrote: >>> Thanks for starting this discussion now. It is an interesting >>> discussion. Some thoughts below. >>> We can decide based on community consensus and follow a single rule >>> across the components. >> Thomas, >> >> No feedback yet on the below questions. > Indeed. I was waiting for opininons from others. > >> If there no consensus in the email, I would like to propose this topic >> to the 26th Feb TB meeting. > I gave my opinion below. > If a consensus cannot be reached, I agree with the request to the techboard. > > 17/02/2020 08:19, Jerin Jacob: > I got initial comments from Ray and Stephen on this RFC[1]. Thanks for > the comments. > > Is anyone else planning to have an architecture level or API usage > level review or any review of other top-level aspects? If we add rte_graph to DPDK, we will have 2 similar libraries. I already proposed several times to move rte_pipeline in a separate repository for two reasons: 1/ it is acting at a higher API layer level >>> We need to define what is the higher layer API. Is it processing beyond L2? > My opinion is that any API which is implemented differently > for different hardware should be in DPDK. > Hardware devices can offload protocol processing higher than L2, > so L2 does not look to be a good limit from my point of view. > If you assume the capability of networking hardware will grow, and you want to unify different networking hardware with varying capabilities (and also include software-only implementations) under one API, then you might well end up growing DPDK into the software stack you mention below. Soft implementations of complex protocols will require operating system-like support services like timers, RCU, various lock-less data structures, deferred work mechanism, counter handling frameworks, control plane interfaces, etc. Coupling should always be avoided of course, but DPDK would inevitably no longer be a pick-and-choose smörgåsbord library - at least as long as the consumer wants to utilize this higher-layer functionality. This would make DPDK more of a packet processing run-time or a special-purpose, networking operating system than the "a bunch of Ethernet drivers in user space" as it started out as. I'm not saying that's a bad thing. In fact, I think it sounds like an interesting option, although also a very challenging one. From what I can see, DPDK has already set out along this route already. If this is a conscious decision or not, I don't know. Add to this, if Linux expands further with AF_XDP-like features, beyond simply packet I/O, it might not only try to take over DPDK's original concerns, but also more of the current ones. >>> In the context of Graph library, it is a framework, not using any of >>> the substem API >>> other than EAL and it is under lib/librte_graph. >>> Nodes library using graph and other subsystem components such as ethdev and >>> it is under lib/lib_node/ >>> >>> >>> Another interesting question would what would be an issue in DPDK supporting >>> beyond L2. Or higher level protocols? > Definitely higher than L2 is OK in DPDK as long as it is related to hardware > capabilities, not software stack (which can be a DPDK application). > > 2/ there can be different solutions in this layer >>> Is there any issue with that? >>> There is overlap with the distributor library and eventdev as well. >>> ethdev and SW traffic manager libraries as well. That list goes on. > I don't know how much it is an issue. > But I think it shows that at least one implementation is not generic enough. > > I think 1/ was commonly agreed in the community. Now we see one more proof of the reason 2/. I believe it is time to move rte_pipeline (Packet Framework) in a separate repository, and welcome rte_graph as well in another separate repository. >>> What would be gain out of this? > The gain is to be clear about what should be the focus for contributors > working on the main DPDK repository. > What is expected to be maintained, tested, etc. > > >>> My concerns are: >>> # Like packet-gen, The new code will be filled with unnecessary DPDK >>> version checks >>> and unnecessary compatibility issues. >>> # Anything is not in main dpdk repo, it is a second class citizen. >>> # Customer has the pain to use two repos and two releases. Internally, >>> it can be two different >>> repo but release needs to go through one repo. >>> >>> If we are focusing ONLY on the driver API then how can DPDK grow >>> further? If linux kernel >>> would be thought only have just the kernel and networking/storage as >>> different repo it would >>> not have grown up? > Linux kernel is selecting what can enter in the focus or not. > And I wonder what is the d
[dpdk-dev] [Bug 403] i40e: cannot add 2 rte_flows with one matching TCP sport and the other dport
https://bugs.dpdk.org/show_bug.cgi?id=403 Bug ID: 403 Summary: i40e: cannot add 2 rte_flows with one matching TCP sport and the other dport Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: maxime.le...@6wind.com Target Milestone: --- With dpdk master (commit id d0e160a00233), I got the following error when I try to create one rte_flow matching TCP dport and one matching TCP sport: ./build/app/testpmd --legacy-mem -c 1f -n 4 -w :85:00.1 -- -i --rxq=1 --txq=1 --total-num-mbufs=1 EAL: Detected 40 lcore(s) EAL: Detected 2 NUMA nodes EAL: Static memory layout is selected, amount of reserved memory can be adjusted with -m or --socket-mem EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: No available hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device :85:00.1 on NUMA socket 1 EAL: probe driver: 8086:1583 net_i40e EAL: using IOMMU type 1 (Type 1) Interactive-mode selected ... testpmd> flow create 0 ingress pattern eth / ipv4 / tcp dst is 179 / end actions queue index 0 / end Flow rule #0 created testpmd> flow create 0 ingress pattern eth / ipv4 / tcp src is 180 / end actions queue index 0 / end port_flow_complain(): Caught PMD error type 13 (specific pattern item): cause: 0x2001582a0, Conflict with the first rule's input set.: Invalid argument The message error is not very useful. Because these rules doesn't conflict. These rules are working perfectly fine with other nic. Is It an hardware limitation or a software limitation ? Are there any documentation to know what is supported by the i40e nic with rte_flow API ? -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
On Fri, Feb 21, 2020 at 4:40 PM Thomas Monjalon wrote: > > 21/02/2020 11:30, Jerin Jacob: > > On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: > > > On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon > > > wrote: > > > Thanks for starting this discussion now. It is an interesting > > > discussion. Some thoughts below. > > > We can decide based on community consensus and follow a single rule > > > across the components. > > > > Thomas, > > > > No feedback yet on the below questions. > > Indeed. I was waiting for opininons from others. Me too. > > > If there no consensus in the email, I would like to propose this topic > > to the 26th Feb TB meeting. > > I gave my opinion below. > If a consensus cannot be reached, I agree with the request to the techboard. OK. > > > > > > 17/02/2020 08:19, Jerin Jacob: > > > > > I got initial comments from Ray and Stephen on this RFC[1]. Thanks for > > > > > the comments. > > > > > > > > > > Is anyone else planning to have an architecture level or API usage > > > > > level review or any review of other top-level aspects? > > > > > > > > If we add rte_graph to DPDK, we will have 2 similar libraries. > > > > > > > > I already proposed several times to move rte_pipeline in a separate > > > > repository for two reasons: > > > > 1/ it is acting at a higher API layer level > > > > > > We need to define what is the higher layer API. Is it processing beyond > > > L2? > > My opinion is that any API which is implemented differently > for different hardware should be in DPDK. We need to define SIMD optimization(not HW specific to but architecture-specific) treatment as well, as the graph and node library will have SIMD optimization as well. In general, by the above policy enforced, we need to split DPDK like below, dpdk.git -- librte_compressdev librte_bbdev librte_eventdev librte_pci librte_rawdev librte_eal librte_security librte_mempool librte_mbuf librte_cryptodev librte_ethdev other repo(s). librte_cmdline librte_cfgfile librte_bitratestats librte_efd librte_latencystats librte_kvargs librte_jobstats librte_gso librte_gro librte_flow_classify librte_pipeline librte_net librte_metrics librte_meter librte_member librte_table librte_stack librte_sched librte_rib librte_reorder librte_rcu librte_power librte_distributor librte_bpf librte_ip_frag librte_hash librte_fib librte_timer librte_telemetry librte_port librte_pdump librte_kni librte_acl librte_vhost librte_ring librte_lpm librte_ipsec > Hardware devices can offload protocol processing higher than L2, > so L2 does not look to be a good limit from my point of view. The node may use HW specific optimization if needed. > > > > > In the context of Graph library, it is a framework, not using any of > > > the substem API > > > other than EAL and it is under lib/librte_graph. > > > Nodes library using graph and other subsystem components such as ethdev > > > and > > > it is under lib/lib_node/ > > > > > > > > > Another interesting question would what would be an issue in DPDK > > > supporting > > > beyond L2. Or higher level protocols? > > Definitely higher than L2 is OK in DPDK as long as it is related to hardware > capabilities, not software stack (which can be a DPDK application). The software stack is a vague term. librte_ipsec could be a software stack. > > > > > > 2/ there can be different solutions in this layer > > > > > > Is there any issue with that? > > > There is overlap with the distributor library and eventdev as well. > > > ethdev and SW traffic manager libraries as well. That list goes on. > > I don't know how much it is an issue. > But I think it shows that at least one implementation is not generic enough. I don't think, distributor lies there because of eventdev is not generic. In fact, SW traffic manager is hooked to ethdev as well. It can work as both. > > > > > > I think 1/ was commonly agreed in the community. > > > > Now we see one more proof of the reason 2/. > > > > > > > > I believe it is time to move rte_pipeline (Packet Framework) > > > > in a separate repository, and welcome rte_graph as well in another > > > > separate repository. > > > > > > What would be gain out of this? > > The gain is to be clear about what should be the focus for contributors > working on the main DPDK repository. Not sure how it can defocus if there is another code in the repo. If that case, the Linux kernel is not focused at all. > What is expected to be maintained, tested, etc. We need to maintain and test other code in OTHER dpdk repo as well. > > > > > My concerns are: > > > # Like packet-gen, The new code will be filled with unnecessary DPDK > > > version checks > > > and unnecessary compatibility issues. > > > # Anything is not in main dpdk repo, it is a second class citizen. > > > # Customer has the pain to use two repos and two releases. Internally, > > > it can be two different > > > repo but release needs to go through one repo. > > > > > > If we are foc
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
21/02/2020 16:53, d...@barachs.net: > I can share a data-point with respect to constructing a reasonably functional > network stack. Original work on the project which eventually became fd.io vpp > started in 2002. I've worked on the vpp code base full-time for 18 years. > > In terms of lines of code: the vpp graph subsystem is a minuscule fraction of > the project as a whole. We've rewritten performance-critical bits of the vpp > netstack multiple times. Please could you elaborate? It would be nice to read more about your thoughts and experience.
[dpdk-dev] [PATCH] devtools: skip experimental libraries in ABI check
We don't provide ABI compatibility for experimental libraries.
Skip those libraries by catching a soname containing a version starting
with '0.'.
Align the special case for the glue libraries by using the soname too.
Once libabigail has support for it, we will have a single type of rule.
Fixes: 777014e56d07 ("devtools: add ABI checks")
Signed-off-by: David Marchand
---
devtools/check-abi.sh | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index 0b4d1a37e..dd9120e69 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -40,8 +40,13 @@ for dump in $(find $refdir -name "*.dump"); do
# skip glue drivers, example librte_pmd_mlx5_glue.dump
# We can't rely on a suppression rule for now:
# https://sourceware.org/bugzilla/show_bug.cgi?id=25480
- if [ "$name" != "${name%%_glue.dump}" ]; then
- echo "Skipping ${dump}..."
+ if grep -qE "\
[dpdk-dev] [Bug 404] i40e: "i40e_res_pool_free(): Failed to find entry" error when rte_flow are flushed
https://bugs.dpdk.org/show_bug.cgi?id=404
Bug ID: 404
Summary: i40e: "i40e_res_pool_free(): Failed to find entry"
error when rte_flow are flushed
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: maxime.le...@6wind.com
Target Milestone: ---
With dpdk master (commit id d0e160a00233), I got the following error when I try
to flush a rte_flow a second time (i.e. create a flow, delete, recreate and
then delete).
./build/app/testpmd --legacy-mem -c 1f -n 4 -w :85:00.1 -- -i --rxq=1
--txq=1 --total-num-mbufs=1
EAL: Detected 40 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Static memory layout is selected, amount of reserved memory can be
adjusted with -m or --socket-mem
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :85:00.1 on NUMA socket 1
EAL: probe driver: 8086:1583 net_i40e
EAL: using IOMMU type 1 (Type 1)
Interactive-mode selected
...
testpmd> flow create 0 ingress pattern eth / ipv4 / tcp dst is 179 / end
actions queue index 0 / end
Flow rule #0 created
testpmd> flow flush 0
testpmd> flow create 0 ingress pattern eth / ipv4 / tcp dst is 179 / end
actions queue index 0 / end
Flow rule #0 created
testpmd> flow flush 0
i40e_res_pool_free(): Failed to find entry
testpmd>
The error happens in i40e_res_pool_free:
4951│ /* Not find, return */
4952│ if (valid_entry == NULL) {
4953├>PMD_DRV_LOG(ERR, "Failed to find entry");
4954│ return -EINVAL;
4955│ }
4956│
(gdb) bt
#0 i40e_res_pool_free (pool=0x112c3fe510, base=0) at
/root/dpdk/drivers/net/i40e/i40e_ethdev.c:4953
#1 0x55718b6fa489 in i40e_vsi_release (vsi=0x20015ab80) at
/root/dpdk/drivers/net/i40e/i40e_ethdev.c:5426
#2 0x55718b8c6c8c in i40e_fdir_teardown (pf=0x112c3fe4f8) at
/root/dpdk/drivers/net/i40e/i40e_fdir.c:286
#3 0x55718b97dc8e in i40e_flow_flush_fdir_filter (pf=0x112c3fe4f8) at
/root/dpdk/drivers/net/i40e/i40e_flow.c:5186
#4 0x55718b97da24 in i40e_flow_flush (dev=0x55718e4e9300
, error=0x7fffd7360320) at
/root/dpdk/drivers/net/i40e/i40e_flow.c:5114
#5 0x55718acc91dc in rte_flow_flush (port_id=0, error=0x7fffd7360320) at
/root/dpdk/lib/librte_ethdev/rte_flow.c:412
..
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [dpdk-dev] [PATCH] devtools: skip experimental libraries in ABI check
On 2/21/2020 4:10 PM, David Marchand wrote:
> We don't provide ABI compatibility for experimental libraries.
> Skip those libraries by catching a soname containing a version starting
> with '0.'.
I am not familiar with the script and how libabigail works, but +1 to the idea.
>
> Align the special case for the glue libraries by using the soname too.
> Once libabigail has support for it, we will have a single type of rule.
>
> Fixes: 777014e56d07 ("devtools: add ABI checks")
>
> Signed-off-by: David Marchand
> ---
> devtools/check-abi.sh | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index 0b4d1a37e..dd9120e69 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -40,8 +40,13 @@ for dump in $(find $refdir -name "*.dump"); do
> # skip glue drivers, example librte_pmd_mlx5_glue.dump
> # We can't rely on a suppression rule for now:
> # https://sourceware.org/bugzilla/show_bug.cgi?id=25480
> - if [ "$name" != "${name%%_glue.dump}" ]; then
> - echo "Skipping ${dump}..."
> + if grep -qE "\ + echo "Skipped glue library $name."
> + continue
> + fi
> + # skip experimental libraries, with a sover starting with 0.
> + if grep -qE "\ + echo "Skipped experimental library $name."
> continue
> fi
> dump2=$(find $newdir -name $name)
>
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
21/02/2020 16:56, Jerin Jacob: > On Fri, Feb 21, 2020 at 4:40 PM Thomas Monjalon wrote: > > 21/02/2020 11:30, Jerin Jacob: > > > On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: > > > > On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon > > > > wrote: > > > > > If we add rte_graph to DPDK, we will have 2 similar libraries. > > > > > > > > > > I already proposed several times to move rte_pipeline in a separate > > > > > repository for two reasons: > > > > > 1/ it is acting at a higher API layer level > > > > > > > > We need to define what is the higher layer API. Is it processing beyond > > > > L2? > > > > My opinion is that any API which is implemented differently > > for different hardware should be in DPDK. > > We need to define SIMD optimization(not HW specific to but > architecture-specific) > treatment as well, as the graph and node library will have SIMD > optimization as well. I think SIMD optimization is generic to any performance-related project, not specific to DPDK. > In general, by the above policy enforced, we need to split DPDK like below, > dpdk.git > -- > librte_compressdev > librte_bbdev > librte_eventdev > librte_pci > librte_rawdev > librte_eal > librte_security > librte_mempool > librte_mbuf > librte_cryptodev > librte_ethdev > > other repo(s). > > librte_cmdline > librte_cfgfile > librte_bitratestats > librte_efd > librte_latencystats > librte_kvargs > librte_jobstats > librte_gso > librte_gro > librte_flow_classify > librte_pipeline > librte_net > librte_metrics > librte_meter > librte_member > librte_table > librte_stack > librte_sched > librte_rib > librte_reorder > librte_rcu > librte_power > librte_distributor > librte_bpf > librte_ip_frag > librte_hash > librte_fib > librte_timer > librte_telemetry > librte_port > librte_pdump > librte_kni > librte_acl > librte_vhost > librte_ring > librte_lpm > librte_ipsec I think it is a fair conclusion of the scope I am arguing, yes. > > Hardware devices can offload protocol processing higher than L2, > > so L2 does not look to be a good limit from my point of view. > > The node may use HW specific optimization if needed. That's an interesting argument. > > > > In the context of Graph library, it is a framework, not using any of > > > > the substem API > > > > other than EAL and it is under lib/librte_graph. > > > > Nodes library using graph and other subsystem components such as ethdev > > > > and > > > > it is under lib/lib_node/ > > > > > > > > > > > > Another interesting question would what would be an issue in DPDK > > > > supporting > > > > beyond L2. Or higher level protocols? > > > > Definitely higher than L2 is OK in DPDK as long as it is related to hardware > > capabilities, not software stack (which can be a DPDK application). > > The software stack is a vague term. librte_ipsec could be a software stack. I agree. > > > > > 2/ there can be different solutions in this layer > > > > > > > > Is there any issue with that? > > > > There is overlap with the distributor library and eventdev as well. > > > > ethdev and SW traffic manager libraries as well. That list goes on. > > > > I don't know how much it is an issue. > > But I think it shows that at least one implementation is not generic enough. > > I don't think, distributor lies there because of eventdev is not generic. > In fact, SW traffic manager is hooked to ethdev as well. It can work as both. > > > > > > > > > I think 1/ was commonly agreed in the community. > > > > > Now we see one more proof of the reason 2/. > > > > > > > > > > I believe it is time to move rte_pipeline (Packet Framework) > > > > > in a separate repository, and welcome rte_graph as well in another > > > > > separate repository. > > > > > > > > What would be gain out of this? > > > > The gain is to be clear about what should be the focus for contributors > > working on the main DPDK repository. > > Not sure how it can defocus if there is another code in the repo. > If that case, the Linux kernel is not focused at all. I see your point. > > What is expected to be maintained, tested, etc. > > We need to maintain and test other code in OTHER dpdk repo as well. Yes but the ones responsible are not the same. > > > > My concerns are: > > > > # Like packet-gen, The new code will be filled with unnecessary DPDK > > > > version checks > > > > and unnecessary compatibility issues. > > > > # Anything is not in main dpdk repo, it is a second class citizen. > > > > # Customer has the pain to use two repos and two releases. Internally, > > > > it can be two different > > > > repo but release needs to go through one repo. > > > > > > > > If we are focusing ONLY on the driver API then how can DPDK grow > > > > further? If linux kernel > > > > would be thought only have just the kernel and networking/storage as > > > > different repo it would > > > > not have grown up? > > > > Linux kernel is selecting what can enter in the focus or not. > > Sorry. This
[dpdk-dev] [Bug 405] mlx5: the guest driver doesn't enforce the MTU set by rte_eth_dev_set_mtu()
https://bugs.dpdk.org/show_bug.cgi?id=405 Bug ID: 405 Summary: mlx5: the guest driver doesn't enforce the MTU set by rte_eth_dev_set_mtu() Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: critical Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: scott_was...@affirmednetworks.com Target Milestone: --- On our guest VM, we are seeing packets that exceed the configured MTU are not dropped by the mlx5 driver, and the packet scribbles past the end of the buffer and overwrites the next struct rte_mbuf in memory. The Openstack host’s MTU is 9000 on the PF. Any large value will do. The guest has buffers that are all 2250 bytes in payload size. The guest calls rte_eth_dev_set_mtu() with a value of 2250 on a given VF. We send an ICMP echo packet of size 3000 bytes, and it is not dropped by the driver. Instead, the 3000-byte packet is written into a 2250-byte buffer, having ignored the setting from rte_eth_dev_set_mtu (which had returned “success”), and causes corruption of the next struct rte_mbuf in memory, and a crash very soon thereafter. When we reduce the host’s MTU on the PF to a value <= 2250, then the problem goes away. But we see this is a work-around, not a fix. If the guest is in fact unable to change the MTU due to hardware architectural limitations, it would be prudent to return the error (-ENOTSUP) to indicate that the guest is unable to perform the request. Also generate a log message describing the reason for the error, to provide the community with sufficient information to understand the problem. But this is speculation, we don't know for certain that the mlx5 guest driver is architecturally unable to enforce MTU. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH] devtools: skip experimental libraries in ABI check
21/02/2020 17:13, Ferruh Yigit:
> On 2/21/2020 4:10 PM, David Marchand wrote:
> > We don't provide ABI compatibility for experimental libraries.
> > Skip those libraries by catching a soname containing a version starting
> > with '0.'.
>
> I am not familiar with the script and how libabigail works, but +1 to the
> idea.
>
> >
> > Align the special case for the glue libraries by using the soname too.
> > Once libabigail has support for it, we will have a single type of rule.
> >
> > Fixes: 777014e56d07 ("devtools: add ABI checks")
> >
> > Signed-off-by: David Marchand
Acked-by: Thomas Monjalon
Re: [dpdk-dev] [PATCH v2] eal/windows: fix out-of-memory check
18/02/2020 22:52, Ranjit Menon:
> On 2/17/2020 3:56 PM, Dmitry Kozlyuk wrote:
> > Check vsnprintf() result to prevent calling malloc() with negative size.
> > Check actual malloc() result and terminate asprintf() with documented
> > error code to prevent the use of NULL pointer.
> >
> > Fixes: e8428a9d8 ("eal/windows: add some basic functions and macros")
> >
> > Signed-off-by: Dmitry Kozlyuk
> > ---
> > lib/librte_eal/windows/eal/include/rte_os.h | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > v2 Changes:
> > Check vsnprintf() value before appending place for '\0'.
> >
> Acked-by: Ranjit Menon
Applied, thanks.
Note: adding "in asprintf" to the title in order to give context.
Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
On Fri, 21 Feb 2020 09:48:58 -0500 Aaron Conole wrote: > David Marchand writes: > > > On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang wrote: > > > >> > >> [AMD Official Use Only - Internal Distribution Only] > > > > Please, get this header removed. > > This is a public mailing list. > > > > > >> Thanks Thomas for bringing this up. > >> I consider this is not a new feature, but rather a fix to address > >> the issue with statically assigned maximum lcore limit on > >> high-density CPU platform such as AMD Epyc. > >> As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11, > >> and they have 1~2 yrs of lifetime left, we like to backport this to > >> LTS 18.11 & 19.11 at least. > > > > It is not a fix. > > > > The use of static arrays is a design choice that goes back to the > > early days in dpdk. > > The addition of --lcores came in after this, but it was introduced for > > a different use case than placing lcores on any physical core. > > And there was no claim that a core > RTE_MAX_LCORE would be usable. > > > > > > When testing on a new hardware, it is normal to observe some limitations. > > Running DPDK on those platforms should be possible: "should be" > > because I do not have access to this hardware and saw neither tests > > reports nor performance numbers. > > Before this patch, the limitation is that on Epyc, cores > > > RTE_MAX_LCORE are not usable. > > > > > > Now, this change is quite constrained. > > If we backport it, I don't expect issues in the main dpdk components > > (based on code review and ovs tests with a RTE_MAX_LCORE set to 16 on > > a 24 cores system). > > There might be issues in some examples or not widely used library > > which uses a physical core id instead of a lcore id. > > > > > > This is the same recurring question "do we allow new features in a > > stable branch?". > > Usually, the answer is 'no'. But we do allow some "new" things to be > backported (pci ids, etc) that might be required to enable older > functionality. Additionally, I'm sure if some feature were required to > mitigate a CVE, we'd rather favor backporting it. > > I guess we could pose a litmus test: > > 1. Is the problem this feature solves so widespread that it needs to > be addressed ASAP? > 2. Is there a known workaround to the problem this is solving? > 3. How intrusive is the feature? > 4. Is it shown to be stable in the mainline (number of fixes, testing, > etc)? > 5. Is it constrained enough that we know we can support it with even > higher priority than other things? > > Probably other questions that will need to be asked. > > And even in that list of question, I'm not sure I'd be able to advocate > backporting this in the upstream branches - it hasn't had much testing. > It's unstable. It's "difficult" to use. It is not widespread that > people have so many cores. The workaround is much simpler than > supporting this (recompile). > > > > > -- > > David Marchand > RTE_MAX_LCORES is exposed in API/ABI to application. Many applications use that to size internal data structures. Having rte_lcore_id() potentially return a larger value would cause out of bounds access (and crash) in that application.
Re: [dpdk-dev] [PATCH] devtools: skip experimental libraries in ABI check
On Fri, Feb 21, 2020 at 5:30 PM Thomas Monjalon wrote:
>
> 21/02/2020 17:13, Ferruh Yigit:
> > On 2/21/2020 4:10 PM, David Marchand wrote:
> > > We don't provide ABI compatibility for experimental libraries.
> > > Skip those libraries by catching a soname containing a version starting
> > > with '0.'.
> >
> > I am not familiar with the script and how libabigail works, but +1 to the
> > idea.
> >
> > >
> > > Align the special case for the glue libraries by using the soname too.
> > > Once libabigail has support for it, we will have a single type of rule.
> > >
> > > Fixes: 777014e56d07 ("devtools: add ABI checks")
> > >
> > > Signed-off-by: David Marchand
>
> Acked-by: Thomas Monjalon
Applied.
--
David Marchand
Re: [dpdk-dev] [PATCH] build: fix experimental library versioning
On Thu, Feb 20, 2020 at 8:55 PM Ferruh Yigit wrote:
>
> The problem occurred when workaround that makes soname two digits
> applied. With this change for the ABI version "20.0.1" the experimental
> library version become ".so.2001".
> After workaround removed in ABI version 21.0, the experimental library
> version will become ".so.210".
> "2001" is bigger value than "201" although it is a previous version of
> the library version, this can break the version comparisons.
>
> To fix this, introducing a temporary sub level versioning for the
> experimental libraries, so that minor version comparison will continue
> to work.
>
> After change experimental libraries will follow below versioning:
>
> DPDK version ABI version soname library name
> --- --
> DPDK 19.11 20.0.so.0.200.so.0.200
> DPDK 20.02 20.0.1 .so.0.200.1 .so.0.200.1
> DPDK 20.05 20.0.2 .so.0.200.2 .so.0.200.2
> DPDK 20.11 21.0.so.0.210.so.0.210
> DPDK 21.02 21.1.so.0.211.so.0.211
>
> Note: After workaround removed in DPDK 20.11 and soname switch back to
> single digit this patch won't work and needs to be updated.
>
> Fixes: f26c2b39b271 ("build: fix soname info for 19.11 compatibility")
>
> Signed-off-by: Ferruh Yigit
Acked-by: Luca Boccassi
Acked-by: Ray Kinsella
Applied.
--
David Marchand
Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
[AMD Official Use Only - Internal Distribution Only] Thanks Thomas for bringing this up. I consider this is not a new feature, but rather a fix to address the issue with statically assigned maximum lcore limit on high-density CPU platform such as AMD Epyc. As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11, and they have 1~2 yrs of lifetime left, we like to backport this to LTS 18.11 & 19.11 at least. -Original Message- From: Thomas Monjalon Sent: Friday, February 21, 2020 12:04 AM To: David Marchand Cc: dev@dpdk.org; acon...@redhat.com; ferruh.yi...@intel.com; Song, Keesang ; bl...@debian.org; ktray...@redhat.com; bruce.richard...@intel.com; honnappa.nagaraha...@arm.com; d...@linux.vnet.ibm.com; sta...@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE [CAUTION: External Email] Hi, 21/01/2020 01:24, Thomas Monjalon: > 02/12/2019 16:35, David Marchand: > > We are currently stuck with no option but recompile a DPDK if the > > system has more cores than RTE_MAX_LCORE. > > A bit of a pity when you get a system with more than 200+ cores and > > your testpmd has been built and packaged with RTE_MAX_LCORE == 128. > > > > The --lcores does not need to care about the underlying cores, > > remove this limitation. > > > David Marchand (4): > > eal/windows: fix cpuset macro name > > eal: do not cache lcore detection state > > eal: display all detected cores at startup > > eal: remove limitation on cpuset with --lcores > > The patches look good but it is very hard to review parsing code (last patch). > We will better experience corner cases after merging. > > Applied for -rc1, thanks This patch was merged in 20.02. We don't have any feedback about issues so it's probably working fine. It is solving a problem for running DPDK on machines having a lot of cores. Now the difficult question: is it a new feature or a fix? Should we backport this patchset?
Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem
I can share a data-point with respect to constructing a reasonably functional network stack. Original work on the project which eventually became fd.io vpp started in 2002. I've worked on the vpp code base full-time for 18 years. In terms of lines of code: the vpp graph subsystem is a minuscule fraction of the project as a whole. We've rewritten performance-critical bits of the vpp netstack multiple times. FWIW... Dave -Original Message- From: Mattias Rönnblom Sent: Friday, February 21, 2020 10:39 AM To: Thomas Monjalon ; Jerin Jacob Cc: Jerin Jacob ; Ray Kinsella ; dpdk-dev ; Prasun Kapoor ; Nithin Dabilpuram ; Kiran Kumar K ; Pavan Nikhilesh ; Narayana Prasad ; nsax...@marvell.com; sshankarn...@marvell.com; Honnappa Nagarahalli ; David Marchand ; Ferruh Yigit ; Andrew Rybchenko ; Ajit Khaparde ; Ye, Xiaolong ; Raslan Darawsheh ; Maxime Coquelin ; Akhil Goyal ; Cristian Dumitrescu ; John McNamara ; Richardson, Bruce ; Anatoly Burakov ; Gavin Hu ; David Christensen ; Ananyev, Konstantin ; Pallavi Kadam ; Olivier Matz ; Gage Eads ; Rao, Nikhil ; Erik Gabriel Carrillo ; Hemant Agrawal ; Artem V. Andreev ; Stephen Hemminger ; Shahaf Shuler ; Wiles, Keith ; Jasvinder Singh ; Vladimir Medvedkin ; techbo...@dpdk.org; Stephen Hemminger ; d...@barachs.net Subject: Re: [dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem On 2020-02-21 12:10, Thomas Monjalon wrote: > 21/02/2020 11:30, Jerin Jacob: >> On Mon, Feb 17, 2020 at 4:28 PM Jerin Jacob wrote: >>> On Mon, Feb 17, 2020 at 2:08 PM Thomas Monjalon wrote: >>> Thanks for starting this discussion now. It is an interesting >>> discussion. Some thoughts below. >>> We can decide based on community consensus and follow a single rule >>> across the components. >> Thomas, >> >> No feedback yet on the below questions. > Indeed. I was waiting for opininons from others. > >> If there no consensus in the email, I would like to propose this >> topic to the 26th Feb TB meeting. > I gave my opinion below. > If a consensus cannot be reached, I agree with the request to the techboard. > > 17/02/2020 08:19, Jerin Jacob: > I got initial comments from Ray and Stephen on this RFC[1]. Thanks > for the comments. > > Is anyone else planning to have an architecture level or API usage > level review or any review of other top-level aspects? If we add rte_graph to DPDK, we will have 2 similar libraries. I already proposed several times to move rte_pipeline in a separate repository for two reasons: 1/ it is acting at a higher API layer level >>> We need to define what is the higher layer API. Is it processing beyond L2? > My opinion is that any API which is implemented differently for > different hardware should be in DPDK. > Hardware devices can offload protocol processing higher than L2, so L2 > does not look to be a good limit from my point of view. > If you assume the capability of networking hardware will grow, and you want to unify different networking hardware with varying capabilities (and also include software-only implementations) under one API, then you might well end up growing DPDK into the software stack you mention below. Soft implementations of complex protocols will require operating system-like support services like timers, RCU, various lock-less data structures, deferred work mechanism, counter handling frameworks, control plane interfaces, etc. Coupling should always be avoided of course, but DPDK would inevitably no longer be a pick-and-choose smörgåsbord library - at least as long as the consumer wants to utilize this higher-layer functionality. This would make DPDK more of a packet processing run-time or a special-purpose, networking operating system than the "a bunch of Ethernet drivers in user space" as it started out as. I'm not saying that's a bad thing. In fact, I think it sounds like an interesting option, although also a very challenging one. From what I can see, DPDK has already set out along this route already. If this is a conscious decision or not, I don't know. Add to this, if Linux expands further with AF_XDP-like features, beyond simply packet I/O, it might not only try to take over DPDK's original concerns, but also more of the current ones. >>> In the context of Graph library, it is a framework, not using any of >>> the substem API other than EAL and it is under lib/librte_graph. >>> Nodes library using graph and other subsystem components such as >>> ethdev and it is under lib/lib_node/ >>> >>> >>> Another interesting question would what would be an issue in DPDK >>> supporting beyond L2. Or higher level protocols? > Definitely higher than L2 is OK in DPDK as long as it is related to > hardware capabilities, not software stack (which can be a DPDK application). > > 2/ there can be different solutions in this layer >>> Is there any issue with that? >>> There is overlap with the distributor library
Re: [dpdk-dev] ABI version of experimental libraries
19/02/2020 14:50, Ray Kinsella: > On 19/02/2020 12:43, Thomas Monjalon wrote: > > 19/02/2020 12:43, Neil Horman: > >> On Tue, Feb 18, 2020 at 10:50:09AM +0100, Thomas Monjalon wrote: > >>> 18/02/2020 10:42, Bruce Richardson: > On Tue, Feb 18, 2020 at 12:15:56AM +0100, Thomas Monjalon wrote: > > Hi, > > > > I would like to remind everybody our mistake when defining ABI versions. > > It has been "fixed" in this commit: > > http://git.dpdk.org/dpdk/commit/?id=f26c2b39 > > > > Please let's think about the consequence for the experimental libraries. > > > > In DPDK 19.11, we use the ABI version 0.200 with soname 0.20 In DPDK > > 20.02, we use the ABI version 0.2001 with soname 0.201 Numbers are > > increasing, that's fine. When we'll switch to the new major ABI and use > > a normal numbering: In DPDK 20.11, we will use the ABI version 0.210 > > with > > soname 0.21 Numbers are dropping. > > > > In short, for experimental libs, ABI 20.1 > ABI 21.0 > > > > Are we OK with this or do we prefer reverting to normal numbering for > > experimental libraries in DPDK 20.02? > > > Personally, I would not be too concerned about the verions of > experimental > libs, so long as they don't conflict across versions and have some > similarity to the major ABI version for the release. > >>> > >>> You think sorting of the version numbers is not important? > >>> If we don't care comparing experimental version numbers, > >>> then OK, let's drop this patch. But please we need a small vote. > >>> > >>> Note: there would be no problem if we did not vote for having > >>> a special numbering for pure experimental libraries (I am still against). > >>> > >> I don't understand. Why would we change the ABI_VERSION at all in an LTS > >> release at > >> all? This operation is meant to take an an experimental API and mark it as > >> stable by promoting its version number to the next major releases number. > >> As > >> such, in the LTS release, we should keep the soname the same, as there > >> should be > >> no other ABI changes in the promoted API. > > > > The library version number is updated because we add new symbols. > > > > > > So while experimental library version numbers are not "important". > I do agree with Thomas they should be sane, increase and should have a > consistent format. > > Should we always just pad them to 4 places as the simple solution? > i.e. > > DPDK 19.11 ... 0.20 (needs to remain 0.20). > DPDK 20.02 ... 0.2001 > DPDK 20.11 ... 0.2100 > DPDK 21.02 ... 0.2101 A patch from Ferruh got merged. It is adding a dot to keep versioning consistent. Marking this patch as rejected.
Re: [dpdk-dev] [EXTERNAL] [PATCH] kernel: remove unused directory for Windows
20/02/2020 23:10, Narcisa Ana Maria Vasile: > On 2/17/2020 8:58 AM, Thomas Monjalon wrote: > > The netuio driver will be hosted in a separate repository: > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.dpdk.org%2Fdpdk-kmods%2F&data=02%7C01%7CNarcisa.Vasile%40microsoft.com%7Cdd318aa4159444af328308d7b3caa6c8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63717271490035&sdata=SItke0nCL%2FqT1vXI0amC83DV4%2FQPLF2Z8Or3PgQX5fU%3D&reserved=0 > > > > Signed-off-by: Thomas Monjalon > > --- > > MAINTAINERS| 1 - > > kernel/windows/meson.build | 4 > > 2 files changed, 5 deletions(-) > > delete mode 100644 kernel/windows/meson.build > > > Reviewed-by: Narcisa Vasile > > Acked-by: Narcisa Vasile Applied
Re: [dpdk-dev] [PATCH v4] doc: alias to experimental tag for stable apis
On 2/18/2020 10:46 AM, Ray Kinsella wrote: > When a maintainer is promoting an API to become part of the next major ABI > version by removing the experimental tag, possibly a few releases in > advance of the declaration of the next ABI version. The maintainer may > choose to offer an alias to the experimental tag, as removing the tag > before the declaration of the next major ABI version, would cause an ABI > breakage for applications using the API. > > Signed-off-by: Ray Kinsella > --- > doc/guides/contributing/abi_policy.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/doc/guides/contributing/abi_policy.rst > b/doc/guides/contributing/abi_policy.rst > index 05ca959..7ae7de7 100644 > --- a/doc/guides/contributing/abi_policy.rst > +++ b/doc/guides/contributing/abi_policy.rst > @@ -159,6 +159,11 @@ The requirements for changing the ABI are: > ``experimental``, as described in the section on :ref:`Experimental APIs > and Libraries `. > > + - In situations in which an ``experimental`` API has been stable for some > + time. When promoting the API to become part of the next ABI version, the > + maintainer may choose to provide an alias to the ``experimental`` tag, > so > + as not to break consuming applications. > + > #. If a newly proposed API functionally replaces an existing one, when the > new > API becomes non-experimental, then the old one is marked with > ``__rte_deprecated``. > @@ -317,6 +322,11 @@ not required. Though, an API should remain in > experimental state for at least > one release. Thereafter, the normal process of posting patch for review to > mailing list can be followed. > > +After the experimental tag has been formally removed, a tree/sub-tree > maintainer > +may choose to offer an alias to the experimental tag so as not to break > +applications using the API. The alias is then dropped at the declaration of > next > +major ABI version. > + > Libraries > ~ > > This leaves the decision to author/maintainer, I am more for making this a requirement, but at least this enables it and better than nothing ;) Acked-by: Ferruh Yigit
Re: [dpdk-dev] [dpdk-stable] [PATCH] doc: fix octeontx2 eventdev devargs
21/02/2020 11:13, Jerin Jacob:
> On Wed, Feb 19, 2020 at 12:25 PM wrote:
> >
> > From: Pavan Nikhilesh
> >
> > Fix OCTEON TX2 event device devargs examples.
> >
> > Fixes: 55e778ca4648 ("event/octeontx2: add devargs for inflight buffer
> > count")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Pavan Nikhilesh
>
> Reviewed-by: Jerin Jacob
Applied, thanks
Re: [dpdk-dev] [dpdk-stable] [PATCH v4 1/2] doc/rcu: correct quiescent state description
19/02/2020 22:05, Honnappa Nagarahalli:
> The quiescent state description refers to an incorrect
> thread.
>
> Fixes: 64994b56cfd7 ("rcu: add RCU library supporting QSBR mechanism")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Prateek Agarwal
> Signed-off-by: Honnappa Nagarahalli
Series applied, thanks
Re: [dpdk-dev] [PATCH v2] doc: rework vm power manager user guide
17/02/2020 11:48, David Hunt: > Review and re-work of vm_power_manager documentation. Hopefully this > is clearer, easier to follow. > > Signed-off-by: David Hunt > > --- > changes in v2 > * Fixed typos. Typos not found even with checkpatch from kernel 5.5.4, but > when the codespell package is installed, the typos are magically > revealed! > * Moved the text blocks from within the high level image out into normal > text for easier future maintenance. Applied, thanks
Re: [dpdk-dev] [PATCH] doc/mlx5: clarify memory write combining attribute
20/02/2020 13:44, Viacheslav Ovsiienko: > Just add the words about write combining attribute. > > Signed-off-by: Viacheslav Ovsiienko Applied, thanks
Re: [dpdk-dev] [PATCH] examples/vhost_blk: use common macros for min/max
20/02/2020 03:52, Tiwei Bie: > On Wed, Feb 19, 2020 at 11:39:22AM +0100, Thomas Monjalon wrote: > > The macros RTE_MIN and RTE_MAX can be used in DPDK applications. Only RTE_MIN is used in this patch. The title is wrong as well. > > This change implies fixing the sign of used_len as size_t > > as defined in vhost_strcpy_pad(). > > > > Signed-off-by: Thomas Monjalon > > --- > > examples/vhost_blk/blk.c | 4 ++-- > > examples/vhost_blk/vhost_blk.h| 2 -- > > examples/vhost_blk/vhost_blk_compat.c | 2 +- > > 3 files changed, 3 insertions(+), 5 deletions(-) > > Reviewed-by: Tiwei Bie
Re: [dpdk-dev] [PATCH v6] doc: introduce openwrt how-to guide
17/02/2020 03:47, Xiaolong Ye: > This doc describes how to enable DPDK on Openwrt in both virtual and > physical x86 environment. > > Signed-off-by: Xiaolong Ye > Acked-by: John McNamara Applied, thanks I hope we'll be able to drop this how-to soon, in favor of a DPDK package well integrated in OpenWrt :-)
Re: [dpdk-dev] [PATCH] maintainers: resign from virtio and vhost
On Fri, Feb 21, 2020 at 11:19:31PM +0800, Wang, Zhihong wrote: > > -Original Message- > > From: Bie, Tiwei > > Sent: Friday, February 21, 2020 9:29 PM > > To: dev@dpdk.org > > Cc: maxime.coque...@redhat.com; Wang, Zhihong > > ; tho...@monjalon.net > > Subject: [PATCH] maintainers: resign from virtio and vhost > > > > I'm leaving Intel, and I'm not sure when I could dedicate enough > > time to DPDK in the future. So I'm removing my name from the > > MAINTAINERS file. > > > > Signed-off-by: Tiwei Bie > > --- > > Xiaolong has been an active and experienced -next tree maintainer > > for a long time. He also knows and loves virtio/vhost. I would > > recommend him as my replacement. > > > > --- > > I really appreciate the helps and supports from Maxime, Zhihong, > > Thomas and the community! Thank you all so much! > > Tiwei, > Thanks for your brilliant work in DPDK over the past years. > All the best! Thanks, Zhihong! :-) > > > > > MAINTAINERS | 4 > > 1 file changed, 4 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 762c13bd6..9c22c3eb4 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -51,7 +51,6 @@ T: git://dpdk.org/next/dpdk-next-net-mlx > > > > Next-virtio Tree > > M: Maxime Coquelin > > -M: Tiwei Bie > > T: git://dpdk.org/next/dpdk-next-virtio > > > > Next-crypto Tree > > @@ -855,7 +854,6 @@ F: doc/guides/nics/features/vmxnet3.ini > > > > Vhost-user > > M: Maxime Coquelin > > -M: Tiwei Bie > > M: Zhihong Wang > > T: git://dpdk.org/next/dpdk-next-virtio > > F: lib/librte_vhost/ > > @@ -870,7 +868,6 @@ F: doc/guides/sample_app_ug/vdpa.rst > > > > Vhost PMD > > M: Maxime Coquelin > > -M: Tiwei Bie > > M: Zhihong Wang > > T: git://dpdk.org/next/dpdk-next-virtio > > F: drivers/net/vhost/ > > @@ -879,7 +876,6 @@ F: doc/guides/nics/features/vhost.ini > > > > Virtio PMD > > M: Maxime Coquelin > > -M: Tiwei Bie > > M: Zhihong Wang > > T: git://dpdk.org/next/dpdk-next-virtio > > F: drivers/net/virtio/ > > -- > > 2.24.1 >
Re: [dpdk-dev] [PATCH] doc: add note on build issues with gcc < 5.0
18/02/2020 09:30, Mcnamara, John: > > From: De Lara Guarch, Pablo > > > > The following crypto PMDs use the Intel Multi-buffer library: > > - AESNI MB PMD > > - AESNI GCM PMD > > - ZUC PMD > > - KASUMI PMD > > - SNOW3G PMD > > > > When this library is built with gcc < 5.0, it might throw some compilation > > issues. A workaround has been added in the repo of this library, so a note > > on this has been added to the documentation of these PMDs. > > Acked-by: John McNamara Applied, thanks
Re: [dpdk-dev] [PATCH] examples/vhost_blk: use common macros for min/max
On Fri, Feb 21, 2020 at 07:29:13PM +0100, Thomas Monjalon wrote: > 20/02/2020 03:52, Tiwei Bie: > > On Wed, Feb 19, 2020 at 11:39:22AM +0100, Thomas Monjalon wrote: > > > The macros RTE_MIN and RTE_MAX can be used in DPDK applications. > > Only RTE_MIN is used in this patch. The title is wrong as well. Make sense! The commit log should describe what's changed by the patch exactly. > > > > > This change implies fixing the sign of used_len as size_t > > > as defined in vhost_strcpy_pad(). > > > > > > Signed-off-by: Thomas Monjalon > > > --- > > > examples/vhost_blk/blk.c | 4 ++-- > > > examples/vhost_blk/vhost_blk.h| 2 -- > > > examples/vhost_blk/vhost_blk_compat.c | 2 +- > > > 3 files changed, 3 insertions(+), 5 deletions(-) > > > > Reviewed-by: Tiwei Bie > > >
[dpdk-dev] [PATCH v1 1/2] doc/failsafe: improve fail-safe documentation
Reading the fail-safe doc with a few years added, a few phrasing choices are ambiguous or confusing. Signed-off-by: Gaetan Rivet --- doc/guides/nics/fail_safe.rst | 107 +- 1 file changed, 66 insertions(+), 41 deletions(-) diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst index 6c02d7ef6..3ce2f8bee 100644 --- a/doc/guides/nics/fail_safe.rst +++ b/doc/guides/nics/fail_safe.rst @@ -4,13 +4,14 @@ Fail-safe poll mode driver library == -The Fail-safe poll mode driver library (**librte_pmd_failsafe**) is a virtual -device that allows using any device supporting hotplug (sudden device removal -and plugging on its bus), without modifying other components relying on such -device (application, other PMDs). +The Fail-safe poll mode driver library (**librte_pmd_failsafe**) implements a +virtual device that allows using device supporting hotplug, without modifying +other components relying on such device (application, other PMDs). +In this context, hotplug support is meant as plugging or removing a device +from its bus suddenly. Additionally to the Seamless Hotplug feature, the Fail-safe PMD offers the -ability to redirect operations to secondary devices when the primary has been +ability to redirect operations to a secondary device when the primary has been removed from the system. .. note:: @@ -23,24 +24,23 @@ Features The Fail-safe PMD only supports a limited set of features. If you plan to use a device underneath the Fail-safe PMD with a specific feature, this feature must -be supported by the Fail-safe PMD to avoid throwing any error. +also be supported by the Fail-safe PMD. -A notable exception is the device removal feature. The fail-safe PMD being a -virtual device, it cannot currently be removed in the sense of a specific bus -hotplug, like for PCI for example. It will however enable this feature for its -sub-device automatically, detecting those that are capable and register the -relevant callback for such event. +A notable exception is the device removal feature. The fail-safe PMD is not +meant to be removed itself, unlike its sub-devices which should support it. +If a sub-device supports hotplugging, the fail-safe PMD will enable its use +automatically by detecting capable devices and registering the relevant handler. Check the feature matrix for the complete set of supported features. Compilation option -- -This option can be modified in the ``$RTE_TARGET/build/.config`` file. +Available options within the ``$RTE_TARGET/build/.config`` file: - ``CONFIG_RTE_LIBRTE_PMD_FAILSAFE`` (default **y**) - Toggle compiling librte_pmd_failsafe. + This option enables or disables compiling librte_pmd_failsafe. Using the Fail-safe PMD from the EAL command line - @@ -51,8 +51,7 @@ must start with the *net_failsafe* prefix, followed by numbers or letters. This name must be unique for each device. Each fail-safe instance must have at least one sub-device, up to ``RTE_MAX_ETHPORTS-1``. -A sub-device can be any legal DPDK device, including possibly another fail-safe -instance. +A sub-device can be any DPDK device, including possibly another fail-safe device. Fail-safe command line parameters ~ @@ -60,20 +59,23 @@ Fail-safe command line parameters - **dev()** parameter This parameter allows the user to define a sub-device. The part of - this parameter must be a valid device definition. It could be the argument - provided to any ``-w`` device specification or the argument that would be - given to a ``--vdev`` parameter (including a fail-safe). - Enclosing the device definition within parenthesis here allows using + this parameter must be a valid device definition. It follows the same format + provided to any ``-w`` or ``--vdev`` options. + + Enclosing the device definition within parentheses here allows using additional sub-device parameters if need be. They will be passed on to the sub-device. .. note:: - In case of whitelist sub-device probed by EAL, fail-safe PMD will take the device - as is, which means that EAL device options are taken in this case. - When trying to use a PCI device automatically probed in blacklist mode, - the syntax for the fail-safe must be with the full PCI id: - Domain:Bus:Device.Function. See the usage example section. + In case where the sub-device is also used as a whitelist device, using ``-w`` + on the EAL command line, the fail-safe PMD will use the device with the + options provided to the EAL instead of its own parameters. + + When trying to use a PCI device automatically probed by the blacklist mode, + the name for the fail-safe sub-device must be the full PCI id: + Domain:Bus:Device.Function, *i.e.* ``00:00:00.0`` instead of ``00:00.0``, + as the second form is historically accepted by the DPDK. - **e
[dpdk-dev] [PATCH v1 0/2] failsafe: improve documentation
The fail-safe documentation is subpar. It can be improved (1), and an error is present from the beginning (2). Gaetan Rivet (2): doc/failsafe: improve fail-safe documentation doc/failsafe: fix incorrect statement regarding number of sub-device doc/guides/nics/fail_safe.rst | 109 +- 1 file changed, 67 insertions(+), 42 deletions(-) -- 2.25.0
[dpdk-dev] [PATCH v1 2/2] doc/failsafe: fix incorrect statement regarding number of sub-device
Supporting more than 2 sub-device is a remnant from earlier fail-safe
design, that was never actually published.
Fixes: a46f8d584eb8 ("net/failsafe: add fail-safe PMD")
Cc: sta...@dpdk.org
Signed-off-by: Gaetan Rivet
---
doc/guides/nics/fail_safe.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index 3ce2f8bee..b4a92f663 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -49,7 +49,7 @@ The Fail-safe PMD can be used like most other DPDK virtual
devices, by passing a
``--vdev`` parameter to the EAL when starting the application. The device name
must start with the *net_failsafe* prefix, followed by numbers or letters. This
name must be unique for each device. Each fail-safe instance must have at
least one
-sub-device, up to ``RTE_MAX_ETHPORTS-1``.
+sub-device, and at most two.
A sub-device can be any DPDK device, including possibly another fail-safe
device.
--
2.25.0
