Re: [dpdk-dev] [patch v3] doc: announce API change in ethdev offload flags
> From: Pavan Nikhilesh > > Add new offload flags ``DEV_RX_OFFLOAD_PTYPE``, > ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``. > > Signed-off-by: Pavan Nikhilesh > Acked-by: Andrew Rybchenko > Acked-by: Jerin Jacob Acked-by: Hemant Agrawal
[dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags
From: Pavan Nikhilesh Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``. Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to set specific ptypes to be updated in ``rte_mbuf::packet_type`` Signed-off-by: Pavan Nikhilesh Acked-by: Andrew Rybchenko Acked-by: Jerin Jacob Acked-by: Hemant Agrawal --- doc/guides/rel_notes/deprecation.rst | 23 +++ 1 file changed, 23 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 37b8592b6..e4e2a85d7 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -78,3 +78,26 @@ Deprecation Notices to set new power environment if power environment was already initialized. In this case the function will return -1 unless the environment is unset first (using ``rte_power_unset_env``). Other function usage scenarios will not change. + +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and ``DEV_RX_OFFLOAD_FLOW_MARK`` + will be added in 19.11. + This will allow application to enable or disable PMDs from updating + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. + In 19.11 PMDs will still update the fields even when the offloads are not + enabled. + +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be added in + 19.11. + This will allow application to request PMD to set specific ptypes defined + through ``rte_eth_dev_set_supported_ptypes`` in ``rte_mbuf::packet_type``. + If application doesn't want any ptype information it can call + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD can + return ``rte_mbuf::packet_type`` with ``rte_eth_dev_get_supported_ptypes``. + If application is interested only in L2/L3 layer, it can inform the PMD to update + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK)``. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. -- 2.17.1
Re: [dpdk-dev] [patch v3] doc: announce API change in ethdev offload flags
Hi Jerin, > > > > > Since application has two knobs rte_eth_dev_get_supported_ptypes() > > > > > and DEV_RX_OFFLOAD_PTYPE. We may not need to new ol_flags for > > this > > > > change. Right? > > > > > i.e if application sets the DEV_RX_OFFLOAD_PTYPE, The application > > > > > will get the parsed ptypes by the driver(= > > > > rte_eth_dev_get_supported_ptypes()). > > > > > So there is no scope ambiguity. Right? > > > > > > > > I still think there is: > > > > Imagine user has 2 eth devices, one does support > > > > DEV_RX_OFFLOAD_PTYPE, second doesn't. Now he has a mix of packets > > > > from both devices, that you want t process. > > > > How would he figure out for which of them ptype values are valid, > > > > and for each are not? > > > > Trace back from what port he has received them? > > > > Not very convenient, and not always possible. > > > > > > I thought so. But in that case, application can always set > > > DEV_RX_OFFLOAD_PTYPE Flags for all the ethdev ports. Right? Rather > > > having any complicated ol_flags or port based parsing. If limit the > > _contract_ to following, we are good. Right? > > > # when DEV_RX_OFFLOAD_PTYPE is set, mbuf.packet_type will be valid > > and > > > mbuf.packet_type will have parsed packet type > > > > Yes sure in principle user can calculate smallest common subset of RX > > offloads supported by all devs in the system and use only them. > > Then he can use some global value for ol_flags that will be setup at > > initialization time, instead of checking ol_flags for every mbuf. > > Though inside DPDK we don't use that method for other offloads (cksum, > > vlan, rss). > > Why we should do different here? > > I agree. We don't need to. > > > Again how to deal with hot-plugged devices with such approach? > > > > > > > > or the negative offload(This contract is pretty clear, I don't think > > > any ambiguity at all) # when DEV_RX_OFFLOAD_NO_PTYPE(something > > > similar) is set, mbuf.packet_type will be invalid. > > > > > > > I think we need either to introduce new ol_flag value (as we usually > > > > do for other RX offloads), or force PMD to always set ptype value. > > > > > > Setting new ol_flag value may effect performance for existing drivers > > > which don't planning to use this offload > > > > If the driver doesn't support DEV_RX_OFFLOAD_PTYPE, it wouldn't need to > > set anything (neither ol_flags, neither packet_type). > > Yes > > > > > > and it complicates the > > > application to have additional check based on ol_flag. If you see any > > > corner case with above section, > > > > > > How about just setting as ptype as 0 incase it is not parsed by driver. > > > > As I said above - ok by me. > > AFAIK, this is current behavior, so no changes in PMD will be required. > > > > > Actual lookup is the costly one, writing 0 to pytpe is not costly as > > > there are plenty of writes in Rx and it will be write merged(No CPU > > > stall) > > > > Yes packet_type is at first 64B, so shouldn't cause any extra overhead. > > > > > > > > I did not get the complete picture of > > > "rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t > > ptype_mask); instead of DEV_RX_OFFLOAD_PTYPE? scheme", Does it help? > > > > I thought about it as just a different way to disable(/limit) requested by > > user > > PTYPE support. > > If let say user is not interested in ptype information at all, he can ask > > PMD to > > just always set ptype value to 0: > > rte_eth_dev_set_supported_ptypes(port, RTE_PTYPE_UNKNOWN); > > > > if he is interested just in L2/L3 layer info, he can ask PMD to provide > > ptype > > information only for L2/L3: > > rte_eth_dev_set_supported_ptypes(port, RTE_PTYPE_L2_MASK | > > RTE_PTYPE_L3_MASK); > > > > Or to enable all supported by PMD ptypes: > > rte_eth_dev_set_supported_ptypes(port, UINT32_MAX) > > > The API looks good to me. We need to document the > rte_eth_dev_set_supported_ptypes() > must be called when device is in stop state to allow PMD do slow path > configuration. > > To summarize: > Two options to control PTYPE lookup: > Option 1: > - If DEV_RX_OFFLOAD_PTYPE set, PMD returns mbuf->packet_type with > rte_eth_dev_get_supported_ptypes() > - If DEV_RX_OFFLOAD_PTYPE is not set, PMD still can return mbuf->packet_type > with rte_eth_dev_get_supported_ptypes() > But if PMD can do some optimization, it can avoid ptype lookup and return > mbuf->packet_type as zero. > > Option 2: > - Introduce rte_eth_dev_set_supported_ptypes(port, needed_ptypes). Yes. > > I think, rte_eth_dev_set_supported_ptypes() is better option As Konstantain > suggested to > have selective control of ptype parsing by PMD at the cost of adding new API. > > I think, we can avoid breaking exiting application by, If > rte_eth_dev_set_supported_ptypes() is not called, > PMD must return mbuf->packet_type with rte_eth_dev_get_supported_ptypes(). > If rte_eth_dev_set_supported_ptypes() and successful, PMD must return > mbuf->packet_type with rte_eth_dev_set_supported
Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags
Hi > > From: Pavan Nikhilesh > > Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``. > Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to > set specific ptypes to be updated in ``rte_mbuf::packet_type`` > > Signed-off-by: Pavan Nikhilesh > Acked-by: Andrew Rybchenko > Acked-by: Jerin Jacob > Acked-by: Hemant Agrawal > --- > doc/guides/rel_notes/deprecation.rst | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 37b8592b6..e4e2a85d7 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -78,3 +78,26 @@ Deprecation Notices >to set new power environment if power environment was already initialized. >In this case the function will return -1 unless the environment is unset > first >(using ``rte_power_unset_env``). Other function usage scenarios will not > change. > + > +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and > ``DEV_RX_OFFLOAD_FLOW_MARK`` > + will be added in 19.11. > + This will allow application to enable or disable PMDs from updating > + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. > + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx > and > + thereby improve Rx performance if application wishes do so. > + In 19.11 PMDs will still update the fields even when the offloads are not > + enabled. > + > +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be added in > + 19.11. As I said in my previous mail, I do support the idea, though few nits below. > + This will allow application to request PMD to set specific ptypes defined > + through ``rte_eth_dev_set_supported_ptypes`` in ``rte_mbuf::packet_type``. > + If application doesn't want any ptype information it can call > + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` Probably worth to mention that in that case packet_type will be set to 0 (PMD still need to set the value). > + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD can > + return ``rte_mbuf::packet_type`` with ``rte_eth_dev_get_supported_ptypes``. > + If application is interested only in L2/L3 layer, it can inform the PMD to > update > + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling > + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | > RTE_PTYPE_L3_MASK)``. > + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx > and As I understand, PMD will still need to write ptype value. Though it will help PMD to avoid figuring out ptype values, when user don't need that information. > + thereby improve Rx performance if application wishes do so. > -- > 2.17.1
Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags
Hi, >-Original Message- >From: Ananyev, Konstantin >Sent: Friday, August 9, 2019 2:17 PM >To: Pavan Nikhilesh Bhagavatula ; Jerin >Jacob Kollanukkaran ; >step...@networkplumber.org; arybche...@solarflare.com; >hemant.agra...@nxp.com; tho...@monjalon.net; Yigit, Ferruh >; Richardson, Bruce >; Neil Horman >; Mcnamara, John >; Kovacevic, Marko > >Cc: dev@dpdk.org >Subject: RE: [dpdk-dev] [patch v4] doc: announce API change in >ethdev offload flags >Hi > >> >> From: Pavan Nikhilesh >> >> Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and >``DEV_RX_OFFLOAD_FLOW_MARK``. >> Add new function ``rte_eth_dev_set_supported_ptypes`` to allow >application to >> set specific ptypes to be updated in ``rte_mbuf::packet_type`` >> >> Signed-off-by: Pavan Nikhilesh >> Acked-by: Andrew Rybchenko >> Acked-by: Jerin Jacob >> Acked-by: Hemant Agrawal >> --- >> doc/guides/rel_notes/deprecation.rst | 23 >+++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >b/doc/guides/rel_notes/deprecation.rst >> index 37b8592b6..e4e2a85d7 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -78,3 +78,26 @@ Deprecation Notices >>to set new power environment if power environment was already >initialized. >>In this case the function will return -1 unless the environment is >unset first >>(using ``rte_power_unset_env``). Other function usage scenarios >will not change. >> + >> +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and >``DEV_RX_OFFLOAD_FLOW_MARK`` >> + will be added in 19.11. >> + This will allow application to enable or disable PMDs from updating >> + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. >> + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields >on Rx and >> + thereby improve Rx performance if application wishes do so. >> + In 19.11 PMDs will still update the fields even when the offloads are >not >> + enabled. >> + >> +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will >be added in >> + 19.11. > >As I said in my previous mail, I do support the idea, though few nits >below. > >> + This will allow application to request PMD to set specific ptypes >defined >> + through ``rte_eth_dev_set_supported_ptypes`` in >``rte_mbuf::packet_type``. >> + If application doesn't want any ptype information it can call >> + ``rte_eth_dev_set_supported_ptypes(ethdev_id, >RTE_PTYPE_UNKNOWN)`` > >Probably worth to mention that in that case packet_type will be set to 0 >(PMD still need to set the value). Ack, will update in v5. > >> + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` >PMD can >> + return ``rte_mbuf::packet_type`` with >``rte_eth_dev_get_supported_ptypes``. >> + If application is interested only in L2/L3 layer, it can inform the PMD >to update >> + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling >> + ``rte_eth_dev_set_supported_ptypes(ethdev_id, >RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK)``. >> + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields >on Rx and > >As I understand, PMD will still need to write ptype value. >Though it will help PMD to avoid figuring out ptype values, when user >don't need that information. I will reword to ``will allow PMDs to avoid lookup to internal ptype table``. > >> + thereby improve Rx performance if application wishes do so. >> -- >> 2.17.1 Thanks, Pavan.
Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags
I think the silent breaking is still not solved for DEV_RX_OFFLOAD_RSS_HASH and DEV_RX_OFFLOAD_FLOW_MARK. An old application will still compile without any problem, but the RSS hash will not be written and the app will break... They should be negative. Eg DEV_RX_OFFLOAD_NO_RSS_HASH and DEV_RX_OFFLOAD_NO_FLOW_MARK? Then, regarding the idea, are we sure it's better to add a configuration check/a branch than always copying a few bytes from a warm cache line to a warm cache line? Or some HW could free some internal resources? But drivers are free to ignore it so it is not a problem as opposed to silent breaking. Tom On 2019-08-09 10:17, pbhagavat...@marvell.com wrote: From: Pavan Nikhilesh Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``. Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to set specific ptypes to be updated in ``rte_mbuf::packet_type`` Signed-off-by: Pavan Nikhilesh Acked-by: Andrew Rybchenko Acked-by: Jerin Jacob Acked-by: Hemant Agrawal --- doc/guides/rel_notes/deprecation.rst | 23 +++ 1 file changed, 23 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 37b8592b6..e4e2a85d7 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -78,3 +78,26 @@ Deprecation Notices to set new power environment if power environment was already initialized. In this case the function will return -1 unless the environment is unset first (using ``rte_power_unset_env``). Other function usage scenarios will not change. + +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and ``DEV_RX_OFFLOAD_FLOW_MARK`` + will be added in 19.11. + This will allow application to enable or disable PMDs from updating + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. + In 19.11 PMDs will still update the fields even when the offloads are not + enabled. + +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be added in + 19.11. + This will allow application to request PMD to set specific ptypes defined + through ``rte_eth_dev_set_supported_ptypes`` in ``rte_mbuf::packet_type``. + If application doesn't want any ptype information it can call + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD can + return ``rte_mbuf::packet_type`` with ``rte_eth_dev_get_supported_ptypes``. + If application is interested only in L2/L3 layer, it can inform the PMD to update + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK)``. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. -- 2.17.1
Re: [dpdk-dev] [PATCH] test/interrupt: account for race with callback
On Thu, Aug 8, 2019 at 7:38 PM Aaron Conole wrote:
>
> Because the eal interrupt framework can race when invoking the callback
> and a separate unregister call, the test needs to accommodate the chance
> that the two collide. Do this by checking the return value of unregister
> against the race-condition flag (EAGAIN).
>
> Fixes: f1a6c22424ce ("app/test: update interrupts test")
Not too sure about this tag, but anyway, this is old enough to apply
to every stable releases we have.
Cc: sta...@dpdk.org ?
> Signed-off-by: Aaron Conole
> ---
> NOTE: it's difficult to reproduce this race. I tried a bit, but have
> only seen it sporadically. In Travis environment, the CPU
> resource can be very limited and this test is quite racy.
Managed to reproduce it:
# time (log=/tmp/$$.log; while true; do echo interrupt_autotest
|taskset -c 0-1 ./build-gcc-static/app/test/dpdk-test -l 0-1 >$log
2>&1; grep -q 'Test OK' $log || break; done; cat $log; rm -f $log)
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: PCI device :00:1f.6 on NUMA socket -1
EAL: Invalid NUMA socket, default to 0
EAL: probe driver: 8086:15d7 net_e1000_em
APP: HPET is not enabled, using TSC as default timer
RTE>>interrupt_autotest
Check unknown valid interrupt full path
Check valid UIO interrupt full path
Check valid device event interrupt full path
count=-11 Resource temporarily unavailable
failure occurred during checking valid device event interrupt full path
Clearing for interrupt tests
Test Failed
RTE>>
real0m38.081s
user0m35.836s
sys0m2.171s
>
> app/test/test_interrupts.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/app/test/test_interrupts.c b/app/test/test_interrupts.c
> index d8c2d8124..233b14a70 100644
> --- a/app/test/test_interrupts.c
> +++ b/app/test/test_interrupts.c
> @@ -370,9 +370,13 @@ test_interrupt_full_path_check(enum
> test_interrupt_handle_type intr_type)
> rte_delay_ms(TEST_INTERRUPT_CHECK_INTERVAL);
>
> rte_delay_ms(TEST_INTERRUPT_CHECK_INTERVAL);
> - if (rte_intr_callback_unregister(&test_intr_handle,
> - test_interrupt_callback, &test_intr_handle) < 0)
> - return -1;
> + while ((count =
> + rte_intr_callback_unregister(&test_intr_handle,
> +test_interrupt_callback,
> +&test_intr_handle)) < 0) {
> + if (count != -EAGAIN)
> + return -1;
> + }
>
> if (flag == 0) {
> printf("callback has not been called\n");
> --
> 2.21.0
>
With this patch, my loop has been running for more than 10 minutes now.
Reviewed-by: David Marchand
--
David Marchand
Re: [dpdk-dev] removal of unused DPDK example apps
Regarding rxtx_callbacks, it's the only one featuring the use of hardware timestamping. I would delay its removal until the feature is more known and mature. Tom On 2019-07-18 11:33, Bruce Richardson wrote: A standard item on the agenda of the DPDK technical board meetings has been the number of example apps in DPDK and whether any of them can be removed. The board would therefore like to propose that we deprecate a number of examples in 19.08 and remove them in 19.11. Here is my initial list of suggested apps to remove, and for a couple of them the reasons why I consider them for removal. * exception_path - basically a tun/tap example app, given we have KNI, and a tap PMD, this app is probably unneeded. * l3fwd-vf * load_balancer - functionality covered by distributor and eventdev now * multiprocess/simple_mp - NOTE: not all multi-process apps, just the basic, toy one! * netmap_compat * quota-watermark * rxtx_callbacks * vmdq * vmdq_dcb NOTE: Whatever apps are removed will still be available for people to reference in older releases of DPDK - including our LTS's - as well as in the git repository, they just won't be available in the latest versions, and there will no longer be any guarantees that they will compile as DPDK changes. The benefits from removing any unwanted apps are that we have less code to maintain and test, and we have smaller DPDK packages and faster build times. At this stage, the technical board is seeking feedback on the proposed removal of these applications, or if there are other examples that people feel do not add any value to DPDK and can be removed. All comments welcome. Regards, /Bruce
Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags
On 8/9/19 12:13 PM, Tom Barbette wrote: I think the silent breaking is still not solved for DEV_RX_OFFLOAD_RSS_HASH and DEV_RX_OFFLOAD_FLOW_MARK. An old application will still compile without any problem, but the RSS hash will not be written and the app will break... They should be negative. Eg DEV_RX_OFFLOAD_NO_RSS_HASH and DEV_RX_OFFLOAD_NO_FLOW_MARK? Then, regarding the idea, are we sure it's better to add a configuration check/a branch than always copying a few bytes from a warm cache line to a warm cache line? Or some HW could free some internal resources? But drivers are free to ignore it so it is not a problem as opposed to silent breaking. It could be not delivered from NIC to host saving PCIe bandwidth. E.g. flow mark plus RSS hash is 8 byte and it is more than 10% for small packet. Tom On 2019-08-09 10:17, pbhagavat...@marvell.com wrote: From: Pavan Nikhilesh Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and ``DEV_RX_OFFLOAD_FLOW_MARK``. Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to set specific ptypes to be updated in ``rte_mbuf::packet_type`` Signed-off-by: Pavan Nikhilesh Acked-by: Andrew Rybchenko Acked-by: Jerin Jacob Acked-by: Hemant Agrawal --- doc/guides/rel_notes/deprecation.rst | 23 +++ 1 file changed, 23 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 37b8592b6..e4e2a85d7 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -78,3 +78,26 @@ Deprecation Notices to set new power environment if power environment was already initialized. In this case the function will return -1 unless the environment is unset first (using ``rte_power_unset_env``). Other function usage scenarios will not change. + +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and ``DEV_RX_OFFLOAD_FLOW_MARK`` + will be added in 19.11. + This will allow application to enable or disable PMDs from updating + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. + In 19.11 PMDs will still update the fields even when the offloads are not + enabled. + +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be added in + 19.11. + This will allow application to request PMD to set specific ptypes defined + through ``rte_eth_dev_set_supported_ptypes`` in ``rte_mbuf::packet_type``. + If application doesn't want any ptype information it can call + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD can + return ``rte_mbuf::packet_type`` with ``rte_eth_dev_get_supported_ptypes``. + If application is interested only in L2/L3 layer, it can inform the PMD to update + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK)``. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. -- 2.17.1
Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags
> -Original Message- > From: Tom Barbette > Sent: Friday, August 9, 2019 2:44 PM > To: Pavan Nikhilesh Bhagavatula ; Jerin Jacob > Kollanukkaran ; step...@networkplumber.org; > arybche...@solarflare.com; hemant.agra...@nxp.com; > tho...@monjalon.net; ferruh.yi...@intel.com; > bruce.richard...@intel.com; Neil Horman ; John > McNamara ; Marko Kovacevic > > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [patch v4] doc: announce API change in ethdev > offload flags > > I think the silent breaking is still not solved for DEV_RX_OFFLOAD_RSS_HASH > and DEV_RX_OFFLOAD_FLOW_MARK. Unlike ptype, presence of rss hash and flow_mark will be marked in ol_flags as PKT_RX_RSS_HASH and PKT_RX_FDIR_ID. So NO application contract breakage. > > An old application will still compile without any problem, but the RSS hash > will > not be written and the app will break... They should be negative. Eg > DEV_RX_OFFLOAD_NO_RSS_HASH and > DEV_RX_OFFLOAD_NO_FLOW_MARK? > > Then, regarding the idea, are we sure it's better to add a configuration > check/a branch than always copying a few bytes from a warm cache line to a > warm cache line? Or some HW could free some internal resources? But > drivers are free to ignore it so it is not a problem as opposed to silent > breaking. > > Tom > > On 2019-08-09 10:17, pbhagavat...@marvell.com wrote: > > From: Pavan Nikhilesh > > > > Add new offload flags ``DEV_RX_OFFLOAD_RSS`` and > ``DEV_RX_OFFLOAD_FLOW_MARK``. > > Add new function ``rte_eth_dev_set_supported_ptypes`` to allow > application to > > set specific ptypes to be updated in ``rte_mbuf::packet_type`` > > > > Signed-off-by: Pavan Nikhilesh > > Acked-by: Andrew Rybchenko > > Acked-by: Jerin Jacob > > Acked-by: Hemant Agrawal > > --- > > doc/guides/rel_notes/deprecation.rst | 23 +++ > > 1 file changed, 23 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > > index 37b8592b6..e4e2a85d7 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -78,3 +78,26 @@ Deprecation Notices > > to set new power environment if power environment was already > initialized. > > In this case the function will return -1 unless the environment is unset > first > > (using ``rte_power_unset_env``). Other function usage scenarios will not > change. > > + > > +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and > ``DEV_RX_OFFLOAD_FLOW_MARK`` > > + will be added in 19.11. > > + This will allow application to enable or disable PMDs from updating > > + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. > > + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx > and > > + thereby improve Rx performance if application wishes do so. > > + In 19.11 PMDs will still update the fields even when the offloads are not > > + enabled. > > + > > +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be > added in > > + 19.11. > > + This will allow application to request PMD to set specific ptypes defined > > + through ``rte_eth_dev_set_supported_ptypes`` in > ``rte_mbuf::packet_type``. > > + If application doesn't want any ptype information it can call > > + ``rte_eth_dev_set_supported_ptypes(ethdev_id, > RTE_PTYPE_UNKNOWN)`` > > + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD > can > > + return ``rte_mbuf::packet_type`` with > ``rte_eth_dev_get_supported_ptypes``. > > + If application is interested only in L2/L3 layer, it can inform the PMD > > to > update > > + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling > > + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK > | RTE_PTYPE_L3_MASK)``. > > + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx > and > > + thereby improve Rx performance if application wishes do so. > > -- > > 2.17.1 > >
[dpdk-dev] [PATCH] crypto/qat: fix null auth issues when using vfio_pci
When running auth NULL cases while using vfio_pci, DMAR read/write faults appear. It happens even if digest_length is set to 0. This is caused by auth_res_addr initialized as 0x0. Fixes: 4e0955bddb08 Cc: Fiona Trahe Signed-off-by: Damian Nowak --- drivers/crypto/qat/qat_sym.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c index 46ef27a..6aa514c 100644 --- a/drivers/crypto/qat/qat_sym.c +++ b/drivers/crypto/qat/qat_sym.c @@ -307,9 +307,8 @@ qat_sym_build_request(void *in_op, uint8_t *out_msg, } min_ofs = auth_ofs; - if (likely(ctx->qat_hash_alg != ICP_QAT_HW_AUTH_ALGO_NULL)) - auth_param->auth_res_addr = - op->sym->auth.digest.phys_addr; + auth_param->auth_res_addr = + op->sym->auth.digest.phys_addr; } -- 2.7.4
[dpdk-dev] [PATCH] examples/qos_meter: fix meter color type conversion
In APP_MODE_SRTCM_COLOR_AWARE mode, sample app compilation fails
due to wrong meter color type conversion.
Fixes: fc8a10d8527a ("examples/qos_meter: add color policy")
error log-
/qos_meter/main.c:error: conversion to incomplete type
(enum rte_meter_color) input_color);
Signed-off-by: Jasvinder Singh
Reported-by: Peng Yuan
---
examples/qos_meter/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/qos_meter/main.c b/examples/qos_meter/main.c
index ce1f63dc7..da7afe8be 100644
--- a/examples/qos_meter/main.c
+++ b/examples/qos_meter/main.c
@@ -156,7 +156,7 @@ app_pkt_handle(struct rte_mbuf *pkt, uint64_t time)
&PROFILE,
time,
pkt_len,
- (enum rte_meter_color) input_color);
+ (enum rte_color) input_color);
/* Apply policing and set the output color */
action = policer_table[input_color][output_color];
--
2.21.0
[dpdk-dev] [patch v5] doc: announce API change in ethdev offload flags
From: Pavan Nikhilesh Add new offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and ``DEV_RX_OFFLOAD_FLOW_MARK``. Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application to set specific ptypes to be updated in ``rte_mbuf::packet_type`` Signed-off-by: Pavan Nikhilesh Acked-by: Andrew Rybchenko Acked-by: Jerin Jacob Acked-by: Hemant Agrawal --- v5 Changes: - Reword for clarity. v4 Changes: - Remove DEV_RX_OFFLOAD_PTYPE proposition and replace it with rte_eth_dev_set_supported_ptypes (Konstantin). v3 Changes: - DEV_RX_OFFLOAD_RSS -> DEV_RX_OFFLOAD_RSS_HASH (andrew). v2 Changes: - Reword for clarity. doc/guides/rel_notes/deprecation.rst | 24 1 file changed, 24 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 37b8592b6..b0391366c 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -78,3 +78,27 @@ Deprecation Notices to set new power environment if power environment was already initialized. In this case the function will return -1 unless the environment is unset first (using ``rte_power_unset_env``). Other function usage scenarios will not change. + +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and ``DEV_RX_OFFLOAD_FLOW_MARK`` + will be added in 19.11. + This will allow application to enable or disable PMDs from updating + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and + thereby improve Rx performance if application wishes do so. + In 19.11 PMDs will still update the fields even when the offloads are not + enabled. + +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be added in + 19.11. + This will allow application to request PMD to set specific ptypes defined + through ``rte_eth_dev_set_supported_ptypes`` in ``rte_mbuf::packet_type``. + If application doesn't want any ptype information it can call + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` and PMD + will set ``rte_mbuf::packet_type`` to ``0``. + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD can + return ``rte_mbuf::packet_type`` with ``rte_eth_dev_get_supported_ptypes``. + If application is interested only in L2/L3 layer, it can inform the PMD to update + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK)``. + This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and + thereby improve Rx performance if application wishes do so. -- 2.17.1
Re: [dpdk-dev] [patch v5] doc: announce API change in ethdev offload flags
> Add new offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and > ``DEV_RX_OFFLOAD_FLOW_MARK``. > Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application > to set specific ptypes to be updated in ``rte_mbuf::packet_type`` > > Signed-off-by: Pavan Nikhilesh > Acked-by: Andrew Rybchenko > Acked-by: Jerin Jacob > Acked-by: Hemant Agrawal > --- > v5 Changes: > - Reword for clarity. > > v4 Changes: > - Remove DEV_RX_OFFLOAD_PTYPE proposition and replace it with > rte_eth_dev_set_supported_ptypes (Konstantin). > > v3 Changes: > - DEV_RX_OFFLOAD_RSS -> DEV_RX_OFFLOAD_RSS_HASH (andrew). > > v2 Changes: > - Reword for clarity. > > doc/guides/rel_notes/deprecation.rst | 24 > 1 file changed, 24 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 37b8592b6..b0391366c 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -78,3 +78,27 @@ Deprecation Notices >to set new power environment if power environment was already initialized. >In this case the function will return -1 unless the environment is unset > first >(using ``rte_power_unset_env``). Other function usage scenarios will not > change. > + > +* ethdev: New offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and > ``DEV_RX_OFFLOAD_FLOW_MARK`` > + will be added in 19.11. > + This will allow application to enable or disable PMDs from updating > + ``rte_mbuf::hash::rss`` and ``rte_mbuf::hash::fdir`` respectively. > + This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx > and > + thereby improve Rx performance if application wishes do so. > + In 19.11 PMDs will still update the fields even when the offloads are not > + enabled. > + > +* ethdev: New function ``rte_eth_dev_set_supported_ptypes`` will be added in > + 19.11. > + This will allow application to request PMD to set specific ptypes defined > + through ``rte_eth_dev_set_supported_ptypes`` in ``rte_mbuf::packet_type``. > + If application doesn't want any ptype information it can call > + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN)`` and PMD > + will set ``rte_mbuf::packet_type`` to ``0``. > + If application doesn't call ``rte_eth_dev_set_supported_ptypes`` PMD can > + return ``rte_mbuf::packet_type`` with ``rte_eth_dev_get_supported_ptypes``. > + If application is interested only in L2/L3 layer, it can inform the PMD to > update > + ``rte_mbuf::packet_type`` with L2/L3 ptype by calling > + ``rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_L2_MASK | > RTE_PTYPE_L3_MASK)``. > + This scheme will allow PMDs to avoid lookup to internal ptype table on Rx > and > + thereby improve Rx performance if application wishes do so. > -- Acked-by: Konstantin Ananyev > 2.17.1
Re: [dpdk-dev] [dpdk-stable] [PATCH] examples/ipsec-secgw: fix unchecked return value
>
> 07/08/2019 15:39, Akhil Goyal:
> >
> > >
> > > Check the return value of the rte_eth_dev_rss_hash_conf_get function.
> > >
> > > Coverity issue: 344970
> > > Fixes: 3a690d5a65e2 ("examples/ipsec-secgw: fix first packet with inline
> crypto")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Bernard Iremonger
> > > ---
> > Acked-by: Akhil Goyal
> >
> > Thomas,
> > Could you please take this patch directly to master.
>
> It doesn't look critical at all.
> Why do you want this in DPDK 19.08 without enough time for proper validation
> testing?
Yes this one is not a critical fix. We can defer it to next release.
Re: [dpdk-dev] [PATCH] examples/qos_meter: fix meter color type conversion
> -Original Message-
> From: Singh, Jasvinder
> Sent: Friday, August 9, 2019 10:37 AM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian ; Peng, Yuan
>
> Subject: [PATCH] examples/qos_meter: fix meter color type conversion
>
> In APP_MODE_SRTCM_COLOR_AWARE mode, sample app compilation fails
> due to wrong meter color type conversion.
>
> Fixes: fc8a10d8527a ("examples/qos_meter: add color policy")
>
> error log-
> /qos_meter/main.c:error: conversion to incomplete type
> (enum rte_meter_color) input_color);
>
> Signed-off-by: Jasvinder Singh
> Reported-by: Peng Yuan
> ---
> examples/qos_meter/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/qos_meter/main.c b/examples/qos_meter/main.c
> index ce1f63dc7..da7afe8be 100644
> --- a/examples/qos_meter/main.c
> +++ b/examples/qos_meter/main.c
> @@ -156,7 +156,7 @@ app_pkt_handle(struct rte_mbuf *pkt, uint64_t time)
> &PROFILE,
> time,
> pkt_len,
> - (enum rte_meter_color) input_color);
> + (enum rte_color) input_color);
>
> /* Apply policing and set the output color */
> action = policer_table[input_color][output_color];
> --
> 2.21.0
Acked-by: Cristian Dumitrescu
[dpdk-dev] [PATCH] net/nfb: remove resources when dev is closed
From: Rastislav Cernay
The rte_eth_dev_close() function now handles freeing resources for
devices (e.g., mac_addrs). To conform with the new close() behaviour we
are asserting the RTE_ETH_DEV_CLOSE_REMOVE flag so that
rte_eth_dev_close() releases all device level dynamic memory.
Signed-off-by: Rastislav Cernay
---
drivers/net/nfb/nfb_ethdev.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/nfb/nfb_ethdev.c b/drivers/net/nfb/nfb_ethdev.c
index c3119a0..4a19979 100644
--- a/drivers/net/nfb/nfb_ethdev.c
+++ b/drivers/net/nfb/nfb_ethdev.c
@@ -210,12 +210,17 @@
static void
nfb_eth_dev_close(struct rte_eth_dev *dev)
{
+ struct pmd_internals *internals = (struct pmd_internals *)
+ dev->data->dev_private;
uint16_t i;
uint16_t nb_rx = dev->data->nb_rx_queues;
uint16_t nb_tx = dev->data->nb_tx_queues;
nfb_eth_dev_stop(dev);
+ nfb_nc_rxmac_deinit(internals->rxmac, internals->max_rxmac);
+ nfb_nc_txmac_deinit(internals->txmac, internals->max_txmac);
+
for (i = 0; i < nb_rx; i++) {
nfb_eth_rx_queue_release(dev->data->rx_queues[i]);
dev->data->rx_queues[i] = NULL;
@@ -226,6 +231,9 @@
dev->data->tx_queues[i] = NULL;
}
dev->data->nb_tx_queues = 0;
+
+ rte_free(dev->data->mac_addrs);
+ dev->data->mac_addrs = NULL;
}
/**
@@ -446,6 +454,9 @@
rte_kvargs_free(kvlist);
}
+ /* Let rte_eth_dev_close() release the port resources */
+ dev->data->dev_flags |= RTE_ETH_DEV_CLOSE_REMOVE;
+
/*
* Get number of available DMA RX and TX queues, which is maximum
* number of queues that can be created and store it in private device
@@ -520,15 +531,10 @@
static int
nfb_eth_dev_uninit(struct rte_eth_dev *dev)
{
- struct rte_eth_dev_data *data = dev->data;
- struct pmd_internals *internals = (struct pmd_internals *)
- data->dev_private;
-
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_pci_addr *pci_addr = &pci_dev->addr;
- nfb_nc_rxmac_deinit(internals->rxmac, internals->max_rxmac);
- nfb_nc_txmac_deinit(internals->txmac, internals->max_txmac);
+ nfb_eth_dev_close(dev);
RTE_LOG(INFO, PMD, "NFB device ("
PCI_PRI_FMT ") successfully uninitialized\n",
--
1.8.3.1
Re: [dpdk-dev] [PATCH] net/nfb: remove resources when dev is closed
Acked-by: Jan Remes
On Fri, Aug 9, 2019 at 4:59 PM Rastislav Cernay wrote:
>
> From: Rastislav Cernay
>
> The rte_eth_dev_close() function now handles freeing resources for
> devices (e.g., mac_addrs). To conform with the new close() behaviour we
> are asserting the RTE_ETH_DEV_CLOSE_REMOVE flag so that
> rte_eth_dev_close() releases all device level dynamic memory.
>
> Signed-off-by: Rastislav Cernay
> ---
> drivers/net/nfb/nfb_ethdev.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/nfb/nfb_ethdev.c b/drivers/net/nfb/nfb_ethdev.c
> index c3119a0..4a19979 100644
> --- a/drivers/net/nfb/nfb_ethdev.c
> +++ b/drivers/net/nfb/nfb_ethdev.c
> @@ -210,12 +210,17 @@
> static void
> nfb_eth_dev_close(struct rte_eth_dev *dev)
> {
> + struct pmd_internals *internals = (struct pmd_internals *)
> + dev->data->dev_private;
> uint16_t i;
> uint16_t nb_rx = dev->data->nb_rx_queues;
> uint16_t nb_tx = dev->data->nb_tx_queues;
>
> nfb_eth_dev_stop(dev);
>
> + nfb_nc_rxmac_deinit(internals->rxmac, internals->max_rxmac);
> + nfb_nc_txmac_deinit(internals->txmac, internals->max_txmac);
> +
> for (i = 0; i < nb_rx; i++) {
> nfb_eth_rx_queue_release(dev->data->rx_queues[i]);
> dev->data->rx_queues[i] = NULL;
> @@ -226,6 +231,9 @@
> dev->data->tx_queues[i] = NULL;
> }
> dev->data->nb_tx_queues = 0;
> +
> + rte_free(dev->data->mac_addrs);
> + dev->data->mac_addrs = NULL;
> }
>
> /**
> @@ -446,6 +454,9 @@
> rte_kvargs_free(kvlist);
> }
>
> + /* Let rte_eth_dev_close() release the port resources */
> + dev->data->dev_flags |= RTE_ETH_DEV_CLOSE_REMOVE;
> +
> /*
> * Get number of available DMA RX and TX queues, which is maximum
> * number of queues that can be created and store it in private device
> @@ -520,15 +531,10 @@
> static int
> nfb_eth_dev_uninit(struct rte_eth_dev *dev)
> {
> - struct rte_eth_dev_data *data = dev->data;
> - struct pmd_internals *internals = (struct pmd_internals *)
> - data->dev_private;
> -
> struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> struct rte_pci_addr *pci_addr = &pci_dev->addr;
>
> - nfb_nc_rxmac_deinit(internals->rxmac, internals->max_rxmac);
> - nfb_nc_txmac_deinit(internals->txmac, internals->max_txmac);
> + nfb_eth_dev_close(dev);
>
> RTE_LOG(INFO, PMD, "NFB device ("
> PCI_PRI_FMT ") successfully uninitialized\n",
> --
> 1.8.3.1
>
[dpdk-dev] [PATCH] bpf: fix to allow ptr stack program type
From: Jerin Jacob
bpf_validate does not allow to execute
RTE_BPF_ARG_PTR_STACK for no reason.
Fix it by enhancing the prog_arg.type check.
Fixes: 6e12ec4c4d6d ("bpf: add more checks")
Cc: sta...@dpdk.org
Signed-off-by: Jerin Jacob
---
lib/librte_bpf/bpf_validate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_bpf/bpf_validate.c b/lib/librte_bpf/bpf_validate.c
index 0cf41fa27..c75777b6d 100644
--- a/lib/librte_bpf/bpf_validate.c
+++ b/lib/librte_bpf/bpf_validate.c
@@ -2216,6 +2216,7 @@ bpf_validate(struct rte_bpf *bpf)
/* check input argument type, don't allow mbuf ptr on 32-bit */
if (bpf->prm.prog_arg.type != RTE_BPF_ARG_RAW &&
+ bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR_STACK &&
bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR &&
(sizeof(uint64_t) != sizeof(uintptr_t) ||
bpf->prm.prog_arg.type != RTE_BPF_ARG_PTR_MBUF)) {
--
2.22.0
[dpdk-dev] [PATCH] net/bnxt: revert fix traffic stall on stop/start
This reverts commit aa2c00702bad7b2c742e11a86cb9dbbb8364fd88, which
introduced the possibility of an invalid address exception when running
an application with a stopped receive queue. The issues with rxq stop/start
will be revisited in the 19.11 release timeframe.
Fixes: aa2c00702bad ("net/bnxt: fix traffic stall on Rx queue stop/start")
Signed-off-by: Lance Richardson
---
drivers/net/bnxt/bnxt_ethdev.c | 2 +-
drivers/net/bnxt/bnxt_ring.c | 3 ++-
drivers/net/bnxt/bnxt_rxq.c| 5 -
drivers/net/bnxt/bnxt_txq.c| 1 -
drivers/net/bnxt/bnxt_txr.c| 1 +
5 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 25a345cd4..6685ee7d9 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1754,7 +1754,7 @@ bnxt_rxq_info_get_op(struct rte_eth_dev *dev, uint16_t
queue_id,
qinfo->conf.rx_free_thresh = rxq->rx_free_thresh;
qinfo->conf.rx_drop_en = 0;
- qinfo->conf.rx_deferred_start = rxq->rx_deferred_start;
+ qinfo->conf.rx_deferred_start = 0;
}
static void
diff --git a/drivers/net/bnxt/bnxt_ring.c b/drivers/net/bnxt/bnxt_ring.c
index a9fcdabe8..be15b4bd1 100644
--- a/drivers/net/bnxt/bnxt_ring.c
+++ b/drivers/net/bnxt/bnxt_ring.c
@@ -533,7 +533,8 @@ int bnxt_alloc_hwrm_rx_ring(struct bnxt *bp, int
queue_index)
rxq->rx_buf_use_size = BNXT_MAX_MTU + RTE_ETHER_HDR_LEN +
RTE_ETHER_CRC_LEN + (2 * VLAN_TAG_SIZE);
- if (!rxq->rx_deferred_start) {
+ if (bp->eth_dev->data->rx_queue_state[queue_index] ==
+ RTE_ETH_QUEUE_STATE_STARTED) {
if (bnxt_init_one_rx_ring(rxq)) {
RTE_LOG(ERR, PMD,
"bnxt_init_one_rx_ring failed!\n");
diff --git a/drivers/net/bnxt/bnxt_rxq.c b/drivers/net/bnxt/bnxt_rxq.c
index 723e85f01..1d95f1139 100644
--- a/drivers/net/bnxt/bnxt_rxq.c
+++ b/drivers/net/bnxt/bnxt_rxq.c
@@ -436,9 +436,11 @@ int bnxt_rx_queue_start(struct rte_eth_dev *dev, uint16_t
rx_queue_id)
rc = bnxt_vnic_rss_configure(bp, vnic);
}
- if (rc == 0)
+ if (rc == 0) {
dev->data->rx_queue_state[rx_queue_id] =
RTE_ETH_QUEUE_STATE_STARTED;
+ rxq->rx_deferred_start = false;
+ }
PMD_DRV_LOG(INFO,
"queue %d, rx_deferred_start %d, state %d!\n",
@@ -473,6 +475,7 @@ int bnxt_rx_queue_stop(struct rte_eth_dev *dev, uint16_t
rx_queue_id)
}
dev->data->rx_queue_state[rx_queue_id] = RTE_ETH_QUEUE_STATE_STOPPED;
+ rxq->rx_deferred_start = true;
PMD_DRV_LOG(DEBUG, "Rx queue stopped\n");
if (dev_conf->rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG) {
diff --git a/drivers/net/bnxt/bnxt_txq.c b/drivers/net/bnxt/bnxt_txq.c
index ba8d39063..43b3496c1 100644
--- a/drivers/net/bnxt/bnxt_txq.c
+++ b/drivers/net/bnxt/bnxt_txq.c
@@ -131,7 +131,6 @@ int bnxt_tx_queue_setup_op(struct rte_eth_dev *eth_dev,
txq->queue_id = queue_idx;
txq->port_id = eth_dev->data->port_id;
- txq->tx_deferred_start = tx_conf->tx_deferred_start;
/* Allocate TX ring hardware descriptors */
if (bnxt_alloc_rings(bp, queue_idx, txq, NULL, txq->cp_ring,
diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
index 9adfee368..c71e6f189 100644
--- a/drivers/net/bnxt/bnxt_txr.c
+++ b/drivers/net/bnxt/bnxt_txr.c
@@ -506,6 +506,7 @@ int bnxt_tx_queue_stop(struct rte_eth_dev *dev, uint16_t
tx_queue_id)
bnxt_handle_tx_cp(txq);
dev->data->tx_queue_state[tx_queue_id] = RTE_ETH_QUEUE_STATE_STOPPED;
+ txq->tx_deferred_start = true;
PMD_DRV_LOG(DEBUG, "Tx queue stopped\n");
return 0;
--
2.17.1
Re: [dpdk-dev] [PATCH] net/bnxt: revert fix traffic stall on stop/start
On Fri, Aug 9, 2019 at 10:22 AM Lance Richardson <
lance.richard...@broadcom.com> wrote:
> This reverts commit aa2c00702bad7b2c742e11a86cb9dbbb8364fd88, which
> introduced the possibility of an invalid address exception when running
> an application with a stopped receive queue. The issues with rxq stop/start
> will be revisited in the 19.11 release timeframe.
>
> Fixes: aa2c00702bad ("net/bnxt: fix traffic stall on Rx queue stop/start")
> Signed-off-by: Lance Richardson
>
Acked-by: Ajit Khaparde
> ---
> drivers/net/bnxt/bnxt_ethdev.c | 2 +-
> drivers/net/bnxt/bnxt_ring.c | 3 ++-
> drivers/net/bnxt/bnxt_rxq.c| 5 -
> drivers/net/bnxt/bnxt_txq.c| 1 -
> drivers/net/bnxt/bnxt_txr.c| 1 +
> 5 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c
> b/drivers/net/bnxt/bnxt_ethdev.c
> index 25a345cd4..6685ee7d9 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -1754,7 +1754,7 @@ bnxt_rxq_info_get_op(struct rte_eth_dev *dev,
> uint16_t queue_id,
>
> qinfo->conf.rx_free_thresh = rxq->rx_free_thresh;
> qinfo->conf.rx_drop_en = 0;
> - qinfo->conf.rx_deferred_start = rxq->rx_deferred_start;
> + qinfo->conf.rx_deferred_start = 0;
> }
>
> static void
> diff --git a/drivers/net/bnxt/bnxt_ring.c b/drivers/net/bnxt/bnxt_ring.c
> index a9fcdabe8..be15b4bd1 100644
> --- a/drivers/net/bnxt/bnxt_ring.c
> +++ b/drivers/net/bnxt/bnxt_ring.c
> @@ -533,7 +533,8 @@ int bnxt_alloc_hwrm_rx_ring(struct bnxt *bp, int
> queue_index)
> rxq->rx_buf_use_size = BNXT_MAX_MTU + RTE_ETHER_HDR_LEN +
> RTE_ETHER_CRC_LEN + (2 * VLAN_TAG_SIZE);
>
> - if (!rxq->rx_deferred_start) {
> + if (bp->eth_dev->data->rx_queue_state[queue_index] ==
> + RTE_ETH_QUEUE_STATE_STARTED) {
> if (bnxt_init_one_rx_ring(rxq)) {
> RTE_LOG(ERR, PMD,
> "bnxt_init_one_rx_ring failed!\n");
> diff --git a/drivers/net/bnxt/bnxt_rxq.c b/drivers/net/bnxt/bnxt_rxq.c
> index 723e85f01..1d95f1139 100644
> --- a/drivers/net/bnxt/bnxt_rxq.c
> +++ b/drivers/net/bnxt/bnxt_rxq.c
> @@ -436,9 +436,11 @@ int bnxt_rx_queue_start(struct rte_eth_dev *dev,
> uint16_t rx_queue_id)
> rc = bnxt_vnic_rss_configure(bp, vnic);
> }
>
> - if (rc == 0)
> + if (rc == 0) {
> dev->data->rx_queue_state[rx_queue_id] =
> RTE_ETH_QUEUE_STATE_STARTED;
> + rxq->rx_deferred_start = false;
> + }
>
> PMD_DRV_LOG(INFO,
> "queue %d, rx_deferred_start %d, state %d!\n",
> @@ -473,6 +475,7 @@ int bnxt_rx_queue_stop(struct rte_eth_dev *dev,
> uint16_t rx_queue_id)
> }
>
> dev->data->rx_queue_state[rx_queue_id] =
> RTE_ETH_QUEUE_STATE_STOPPED;
> + rxq->rx_deferred_start = true;
> PMD_DRV_LOG(DEBUG, "Rx queue stopped\n");
>
> if (dev_conf->rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG) {
> diff --git a/drivers/net/bnxt/bnxt_txq.c b/drivers/net/bnxt/bnxt_txq.c
> index ba8d39063..43b3496c1 100644
> --- a/drivers/net/bnxt/bnxt_txq.c
> +++ b/drivers/net/bnxt/bnxt_txq.c
> @@ -131,7 +131,6 @@ int bnxt_tx_queue_setup_op(struct rte_eth_dev *eth_dev,
>
> txq->queue_id = queue_idx;
> txq->port_id = eth_dev->data->port_id;
> - txq->tx_deferred_start = tx_conf->tx_deferred_start;
>
> /* Allocate TX ring hardware descriptors */
> if (bnxt_alloc_rings(bp, queue_idx, txq, NULL, txq->cp_ring,
> diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
> index 9adfee368..c71e6f189 100644
> --- a/drivers/net/bnxt/bnxt_txr.c
> +++ b/drivers/net/bnxt/bnxt_txr.c
> @@ -506,6 +506,7 @@ int bnxt_tx_queue_stop(struct rte_eth_dev *dev,
> uint16_t tx_queue_id)
> bnxt_handle_tx_cp(txq);
>
> dev->data->tx_queue_state[tx_queue_id] =
> RTE_ETH_QUEUE_STATE_STOPPED;
> + txq->tx_deferred_start = true;
> PMD_DRV_LOG(DEBUG, "Tx queue stopped\n");
>
> return 0;
> --
> 2.17.1
>
>
Re: [dpdk-dev] [dpdk-announce] release candidate 19.08-rc4
IBM Power9 testing for v19.08-rc4 Hi- The following describes the test completed for v19.08-rc4 run on IBM Power9 hardware. * Single port stability test using l3fwd (16 cpus) and TRex, tested 64 and 1500 byte packets at a 0.0% drop rate for 4 hours each. No errors or regressions were seen. System tested: - IBM Power9 Model 8335-101 CPU: 2.3 (pvr 004e 1203) Tested NICs: - Mellanox Technologies MT28800 Family [ConnectX-5 Ex] FW Version:16.23.1020 OS Tested - Ubuntu 18.04.2 LTS kernel: 4.15.0-50-generic Latest dpdk tested version: - version(tag): v19.08-rc4-12-g07f08a96f Regards, Thinh Tran On 8/6/2019 5:05 PM, Thomas Monjalon wrote: A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v19.08-rc4 82 patches were integrated. This is the last release candidate for DPDK 19.08. The release notes are complete: http://doc.dpdk.org/guides/rel_notes/release_19_08.html Only the deprecation notices are missing (waiting for comments). This is the right time to do the last checks. Please share some release validation results by replying to this message (at dev@dpdk.org). If no objection, the version 19.08.0 will be out on August 11. If you are preparing the next release cycle, please send your v1 patches before the 19.11 proposal deadline, which will happen on September 6. It is also time to build an estimated roadmap for the next cycles. Thank you everyone
