Re: [dpdk-dev] running dpdk application on the same machine with other none dpdk application
Hi Shirley, > Do you know if the PF_NO_SETAFFINITY flag can help in any way? AFAIK, this will not work for kernel thread. For example, with 4.8.13-1 kernel: Display all kernel threads with ps aux | grep "\["n (as kernel threads are enclosed in square brackets, [ ]) And pick one of them and try: taskset -pc 7 521 pid 521's current affinity list: 0-15 taskset: failed to set pid 521's affinity: Invalid argument Regards, Rami Rosen
[dpdk-dev] [PATCH] net/ice: fix segment fault
Fix segment fault when detach a device due to some redundant function
call in ice_dev_uninit.
Fixes: f9cf4f864150 ("net/ice: support device initialization")
Signed-off-by: Qi Zhang
---
drivers/net/ice/ice_ethdev.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 6ab66faeb..6b0113b37 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -1458,15 +1458,14 @@ ice_dev_close(struct rte_eth_dev *dev)
ice_res_pool_destroy(&pf->msix_pool);
ice_release_vsi(pf->main_vsi);
-
+ ice_sched_cleanup_all(hw);
+ rte_free(hw->port_info);
ice_shutdown_all_ctrlq(hw);
}
static int
ice_dev_uninit(struct rte_eth_dev *dev)
{
- struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
@@ -1486,11 +1485,6 @@ ice_dev_uninit(struct rte_eth_dev *dev)
rte_intr_callback_unregister(intr_handle,
ice_interrupt_handler, dev);
- ice_release_vsi(pf->main_vsi);
- ice_sched_cleanup_all(hw);
- rte_free(hw->port_info);
- ice_shutdown_all_ctrlq(hw);
-
return 0;
}
--
2.13.6
Re: [dpdk-dev] running dpdk application on the same machine with other none dpdk application
Hi Rami, This is correct but that is because the default value of the PF_NO_SETAFFINITY flags does not allow to set affinity to kernel threads from user space. I was looking for a way to change the kernel and recompile it to be able to block kernel threads from running on the cpu isolated cores. (same as user space threads). BR, Shirley. On Wed, Jan 30, 2019 at 10:18 AM Rami Rosen wrote: > Hi Shirley, > > > Do you know if the PF_NO_SETAFFINITY flag can help in any way? > > AFAIK, this will not work for kernel thread. > > For example, with 4.8.13-1 kernel: > Display all kernel threads with > ps aux | grep "\["n > > (as kernel threads are enclosed in square brackets, [ ]) > And pick one of them and try: > taskset -pc 7 521 > pid 521's current affinity list: 0-15 > taskset: failed to set pid 521's affinity: Invalid argument > Regards, > Rami Rosen > >
Re: [dpdk-dev] running dpdk application on the same machine with other none dpdk application
Perhaps by modifying the function set_cpus_allowed() which sets the kernel threads flag with PF_NO_SETAFFINITY. To remark it in the kernel code and to recompile the code. On Wed, Jan 30, 2019 at 10:27 AM Shirley Avishour wrote: > Hi Rami, > This is correct but that is because the default value of the PF_NO_SETAFFINITY > flags does not allow to set affinity to kernel threads from user space. > I was looking for a way to change the kernel and recompile it to be able > to block kernel threads from running on the cpu isolated cores. (same as > user space threads). > > BR, > Shirley. > > > > On Wed, Jan 30, 2019 at 10:18 AM Rami Rosen wrote: > >> Hi Shirley, >> >> > Do you know if the PF_NO_SETAFFINITY flag can help in any way? >> >> AFAIK, this will not work for kernel thread. >> >> For example, with 4.8.13-1 kernel: >> Display all kernel threads with >> ps aux | grep "\["n >> >> (as kernel threads are enclosed in square brackets, [ ]) >> And pick one of them and try: >> taskset -pc 7 521 >> pid 521's current affinity list: 0-15 >> taskset: failed to set pid 521's affinity: Invalid argument >> Regards, >> Rami Rosen >> >>
Re: [dpdk-dev] running dpdk application on the same machine with other none dpdk application
Hi Shirley, Hi, It could be that this will work, but as I assume you know - This requires providing a patched kernel to end customers, some will not like it, some will maybe not accept it - It could be that a kernel patch to the Kernel Mailing list for enabling such functionality (globally or per kernel thread for example) via a sysf entry or a kernel parameter will be accepted, though. You may try Regards, Rami Rosen
Re: [dpdk-dev] running dpdk application on the same machine with other none dpdk application
Hi, I will consider that. Thanks again for your help. Shirley. On Wed, Jan 30, 2019 at 10:40 AM Rami Rosen wrote: > Hi Shirley, > > Hi, > It could be that this will work, but as I assume you know - > > This requires providing a patched kernel to end customers, some will not > like it, some > will maybe not accept it > > - It could be that a kernel patch to the Kernel Mailing list for enabling > such functionality (globally or per kernel thread for example) > via a sysf entry or a kernel parameter will be accepted, though. You may > try > > Regards, > Rami Rosen > > > >
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On Tue, Jan 29, 2019 at 7:07 PM Ferruh Yigit wrote:
> On 1/29/2019 5:34 PM, David Marchand wrote:
> > On Tue, Jan 29, 2019 at 4:31 PM Ferruh Yigit
> wrote:
> >
> >> Fixes line commit id length defined as 12 in fixline alias:
> >> fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'
> >>
> >> Check if the Fixes line commit id length matches the defined value.
> >>
> >
> > Can't git decide to report a longer string in case of collisions of
> > abbreviated id ?
> >
> > Tried this for 2 characters, and git forcefully reported 5 chars:
> > $ git log -1 --abbrev=2 origin/master --format='Fixes: %h (\"%s\")'
> > Fixes: a2f9c (\"version: 19.02-rc4\")
> >
> > I did not find any collisions with 12 characters abbreviated commitid,
> but
> > I am not sure enforcing the check on exactly 12 characters is a good idea
> > in the long run.
>
> Yes git can report a longer string in case of collisions, but I don't
> expect to
> have one with 12 characters.
>
> This is mainly for some cases either people use full 40 chars or small
> ones.
>
> Indeed in background I am (and most probably Thomas too) fixing them while
> merging, I thought it is better idea to integrate that into script so that
> developers can be aware of the syntax issue and fix it before sending.
>
I can understand you want to avoid such edits yes, and so this patch.
However, I think we can do one more thing.
The contributing guide does indicate you are supposed to run both
checkpatches.sh and check-git-log.sh.
I am pretty sure I missed this second step in the past..
How about calling check-git-log.sh from checkpatches.sh ?
check-git-log.sh does not support patch files as input, so it would need
support for it.
> >
> >
> >> Signed-off-by: Ferruh Yigit
> >> ---
> >> Cc: Qi Zhang
> >> ---
> >> devtools/check-git-log.sh | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh
> >> index d39064f9d..f4d6c1fba 100755
> >> --- a/devtools/check-git-log.sh
> >> +++ b/devtools/check-git-log.sh
> >> @@ -177,6 +177,11 @@ bad=$(for fixtag in $fixtags ; do
> >> done | sed 's,^,\t,')
> >> [ -z "$bad" ] || printf "Wrong 'Fixes' reference:\n$bad\n"
> >>
> >> +bad=$(for fixtag in $fixtags ; do
> >>
> > + echo $fixtag | awk '{print $2}' | awk 'length != 12 {print}'
> >>
> > +done)
> >>
> >
> > Not an awk expert (this could be done in pure shell, but this is a
> > different story :-p), but I would see something like:
> >
> > for fixtag in $fixtags; do
> > echo $fixtag | awk 'length($2) < 12 { print $2 }';
> > done
>
> Yes, looks better, I will update the script.
>
> And no specific preference on shell or awk implementation, there is no
> performance concern in this script and awk already used by it, I am good
> as long
> as it is functional.
>
Well, I've seen Thomas reply, looks even better ;-).
--
David Marchand
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On 1/29/2019 8:41 PM, Thomas Monjalon wrote:
> 29/01/2019 16:30, Ferruh Yigit:
>> Fixes line commit id length defined as 12 in fixline alias:
>> fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'
>>
>> Check if the Fixes line commit id length matches the defined value.
>
> This check was missing on purpose, in order to not be too strict.
> I think it's OK if the length of the SHA1 is not always the same.
That is OK, if we don't want to be strict on this, I will update patch as
rejected.
>
>> --- a/devtools/check-git-log.sh
>> +++ b/devtools/check-git-log.sh
>> @@ -177,6 +177,11 @@ bad=$(for fixtag in $fixtags ; do
>> done | sed 's,^,\t,')
>> [ -z "$bad" ] || printf "Wrong 'Fixes' reference:\n$bad\n"
>>
>> +bad=$(for fixtag in $fixtags ; do
>> +echo $fixtag | awk '{print $2}' | awk 'length != 12 {print}'
>> +done)
>> +[ -z "$bad" ] || printf "Wrong 'Fixes' syntax:\n$bad\n"
>> +
>> # check Cc: sta...@dpdk.org for fixes
>> bad=$(for fix in $stablefixes ; do
>> git log --format='%b' -1 $fix | grep -qi '^Cc: *sta...@dpdk.org' ||
>
> If you really want to be that strict, it can be done simpler:
>
> bad=$(for fixtag in $fixtags ; do
> hash=$(echo "$fixtag" | sed 's,^Fixes: \([0-9a-f]*\).*,\1,')
> if git branch --contains $hash 2>&- | grep -q '^\*' ; then
> - good="Fixes: $hash "$(git log --format='("%s")' -1 $hash 2>&-)
> + good=$(git log --abbrev=12 --format='Fixes: %h ("%s")' -1
> $hash 2>&-)
> else
> good="reference not in current branch"
> fi
>
>
>
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On 1/30/2019 9:58 AM, David Marchand wrote:
> On Tue, Jan 29, 2019 at 7:07 PM Ferruh Yigit wrote:
>
>> On 1/29/2019 5:34 PM, David Marchand wrote:
>>> On Tue, Jan 29, 2019 at 4:31 PM Ferruh Yigit
>> wrote:
>>>
Fixes line commit id length defined as 12 in fixline alias:
fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'
Check if the Fixes line commit id length matches the defined value.
>>>
>>> Can't git decide to report a longer string in case of collisions of
>>> abbreviated id ?
>>>
>>> Tried this for 2 characters, and git forcefully reported 5 chars:
>>> $ git log -1 --abbrev=2 origin/master --format='Fixes: %h (\"%s\")'
>>> Fixes: a2f9c (\"version: 19.02-rc4\")
>>>
>>> I did not find any collisions with 12 characters abbreviated commitid,
>> but
>>> I am not sure enforcing the check on exactly 12 characters is a good idea
>>> in the long run.
>>
>> Yes git can report a longer string in case of collisions, but I don't
>> expect to
>> have one with 12 characters.
>>
>> This is mainly for some cases either people use full 40 chars or small
>> ones.
>>
>> Indeed in background I am (and most probably Thomas too) fixing them while
>> merging, I thought it is better idea to integrate that into script so that
>> developers can be aware of the syntax issue and fix it before sending.
>>
>
> I can understand you want to avoid such edits yes, and so this patch.
>
> However, I think we can do one more thing.
> The contributing guide does indicate you are supposed to run both
> checkpatches.sh and check-git-log.sh.
> I am pretty sure I missed this second step in the past..
>
> How about calling check-git-log.sh from checkpatches.sh ?
> check-git-log.sh does not support patch files as input, so it would need
> support for it.
That sounds good idea to have single script to run.
>
>
>
>>>
>>>
Signed-off-by: Ferruh Yigit
---
Cc: Qi Zhang
---
devtools/check-git-log.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh
index d39064f9d..f4d6c1fba 100755
--- a/devtools/check-git-log.sh
+++ b/devtools/check-git-log.sh
@@ -177,6 +177,11 @@ bad=$(for fixtag in $fixtags ; do
done | sed 's,^,\t,')
[ -z "$bad" ] || printf "Wrong 'Fixes' reference:\n$bad\n"
+bad=$(for fixtag in $fixtags ; do
>>> + echo $fixtag | awk '{print $2}' | awk 'length != 12 {print}'
>>> +done)
>>>
>>> Not an awk expert (this could be done in pure shell, but this is a
>>> different story :-p), but I would see something like:
>>>
>>> for fixtag in $fixtags; do
>>> echo $fixtag | awk 'length($2) < 12 { print $2 }';
>>> done
>>
>> Yes, looks better, I will update the script.
>>
>> And no specific preference on shell or awk implementation, there is no
>> performance concern in this script and awk already used by it, I am good
>> as long
>> as it is functional.
>>
>
> Well, I've seen Thomas reply, looks even better ;-).
>
>
[dpdk-dev] [PATCH 0/3] more doc about isolated mode and bifurcated model
The flow isolated mode lacks some advertisement in the docs, especially in association with flow bifurcation. There was also a miss in flow bifurcation howto for Mellanox case. Thomas Monjalon (3): doc: remove useless anchor for flow API guide doc: add references to flow isolated mode in NICs guide doc: improve Mellanox bifurcated model description doc/guides/howto/flow_bifurcation.rst | 26 ++ doc/guides/howto/rte_flow.rst | 2 +- doc/guides/linux_gsg/linux_drivers.rst | 7 ++- doc/guides/nics/mlx4.rst | 2 ++ doc/guides/nics/mlx5.rst | 2 +- doc/guides/nics/mvpp2.rst | 5 - doc/guides/nics/sfc_efx.rst| 2 ++ doc/guides/prog_guide/rte_flow.rst | 8 doc/guides/rel_notes/release_17_02.rst | 3 +-- 9 files changed, 47 insertions(+), 10 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH 3/3] doc: improve Mellanox bifurcated model description
In the howto guide about flow bifurcation, the Mellanox case (which does not require specific details) was missing in the landscape. In the Linux drivers guide, it was not clear that the flow bifurcation is performed in the NIC hardware. References to flow isolated mode are also inserted in those contexts. Signed-off-by: Thomas Monjalon --- doc/guides/howto/flow_bifurcation.rst | 26 ++ doc/guides/linux_gsg/linux_drivers.rst | 7 ++- 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/doc/guides/howto/flow_bifurcation.rst b/doc/guides/howto/flow_bifurcation.rst index eabf4d730..a36126472 100644 --- a/doc/guides/howto/flow_bifurcation.rst +++ b/doc/guides/howto/flow_bifurcation.rst @@ -44,6 +44,32 @@ module. Flow Bifurcation Overview +Using Flow Bifurcation on Mellanox ConnectX +--- + +The Mellanox devices are :ref:`natively bifurcated `, +so there is no need to split into SR-IOV PF/VF +in order to get the flow bifurcation mechanism. +The full device is already shared with the kernel driver. + +The DPDK application can setup some flow steering rules, +and let the rest go to the kernel stack. +In order to define the filters strictly with flow rules, +the :ref:`flow_isolated_mode` can be configured. + +There is no specific instructions to follow. +The recommended reading is the :doc:`../prog_guide/rte_flow` guide. +Below is an example of testpmd commands +for receiving VXLAN 42 in 4 queues of the DPDK port 0, +while all other packets go to the kernel: + +.. code-block:: console + + testpmd> flow isolate 0 true + testpmd> flow create 0 ingress pattern eth / ipv4 / udp / vxlan vni is 42 / end \ +actions rss queues 0 1 2 3 end / end + + Using Flow Bifurcation on IXGBE in Linux diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst index 8da6a31be..695edbb13 100644 --- a/doc/guides/linux_gsg/linux_drivers.rst +++ b/doc/guides/linux_gsg/linux_drivers.rst @@ -85,6 +85,8 @@ This can be done by using the DPDK setup script (called dpdk-setup.sh and locate VFIO can be used without IOMMU. While this is just as unsafe as using UIO, it does make it possible for the user to keep the degree of device access and programming that VFIO has, in situations where IOMMU is not available. +.. _bifurcated_driver: + Bifurcated Driver - @@ -99,7 +101,10 @@ Such model has the following benefits: - It enables the user to use legacy linux tools such as ``ethtool`` or ``ifconfig`` while running DPDK application on the same network ports. - It enables the DPDK application to filter only part of the traffic, - While the rest will be directed and handled by the kernel driver. + while the rest will be directed and handled by the kernel driver. + The flow bifurcation is performed by the NIC hardware. + As an example, using :ref:`flow_isolated_mode` allows to choose + strictly what is received in DPDK. More about the bifurcated driver can be found in `Mellanox Bifurcated DPDK PMD -- 2.20.1
[dpdk-dev] [PATCH 1/3] doc: remove useless anchor for flow API guide
A doc page (.rst file) can be referenced with :doc: syntax instead of :ref: to .. anchor. Signed-off-by: Thomas Monjalon --- doc/guides/howto/rte_flow.rst | 2 +- doc/guides/nics/mvpp2.rst | 2 +- doc/guides/prog_guide/rte_flow.rst | 2 -- doc/guides/rel_notes/release_17_02.rst | 3 +-- 4 files changed, 3 insertions(+), 6 deletions(-) diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst index 6a8534d98..3dcda6cb1 100644 --- a/doc/guides/howto/rte_flow.rst +++ b/doc/guides/howto/rte_flow.rst @@ -8,7 +8,7 @@ This document demonstrates some concrete examples for programming flow rules with the ``rte_flow`` APIs. * Detail of the rte_flow APIs can be found in the following link: - :ref:`Generic flow API ` . + :doc:`../prog_guide/rte_flow`. * Details of the TestPMD commands to set the flow rules can be found in the following link: :ref:`TestPMD Flow rules ` diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst index b2ddeab50..9dcb93dd9 100644 --- a/doc/guides/nics/mvpp2.rst +++ b/doc/guides/nics/mvpp2.rst @@ -410,7 +410,7 @@ Flow API PPv2 offers packet classification capabilities via classifier engine which can be configured via generic flow API offered by DPDK. -For an additional description please refer to DPDK :ref:`Generic flow API `. +For an additional description please refer to DPDK :doc:`../prog_guide/rte_flow`. Supported flow actions ~~ diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index dbf4999aa..472dcef47 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -2,8 +2,6 @@ Copyright 2016 6WIND S.A. Copyright 2016 Mellanox Technologies, Ltd -.. _Generic_flow_API: - Generic flow API (rte_flow) === diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst index d6c1c5670..2244d27f9 100644 --- a/doc/guides/rel_notes/release_17_02.rst +++ b/doc/guides/rel_notes/release_17_02.rst @@ -77,8 +77,7 @@ New Features higher-level than the legacy filtering framework, which it encompasses and supersedes (including all functions and filter types) . - See the :ref:`Generic flow API ` documentation for more - information. + See the :doc:`../prog_guide/rte_flow` documentation for more information. * **Added firmware version get API.** -- 2.20.1
[dpdk-dev] [PATCH 2/3] doc: add references to flow isolated mode in NICs guide
Some drivers (mlx, mvpp2, sfc) support the flow isolated mode, but the feature was not advertised. A reference to the feature description is added for each driver. Signed-off-by: Thomas Monjalon --- doc/guides/nics/mlx4.rst | 2 ++ doc/guides/nics/mlx5.rst | 2 +- doc/guides/nics/mvpp2.rst | 3 +++ doc/guides/nics/sfc_efx.rst| 2 ++ doc/guides/prog_guide/rte_flow.rst | 6 -- 5 files changed, 12 insertions(+), 3 deletions(-) diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index 4d4842cde..4ad361a2c 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -46,6 +46,8 @@ This capability allows the PMD to coexist with kernel network interfaces which remain functional, although they stop receiving unicast packets as long as they share the same MAC address. +The :ref:`flow_isolated_mode` is supported. + Compiling librte_pmd_mlx4 causes DPDK to be linked against libibverbs. Configuration diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 3f168b161..aa3a884b9 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -67,7 +67,7 @@ Features - Hardware checksum offloads. - Flow director (RTE_FDIR_MODE_PERFECT, RTE_FDIR_MODE_PERFECT_MAC_VLAN and RTE_ETH_FDIR_REJECT). -- Flow API. +- Flow API, including :ref:`flow_isolated_mode`. - Multiple process. - KVM and VMware ESX SR-IOV modes are supported. - RSS hash result is supported. diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst index 9dcb93dd9..4101d2d89 100644 --- a/doc/guides/nics/mvpp2.rst +++ b/doc/guides/nics/mvpp2.rst @@ -410,6 +410,9 @@ Flow API PPv2 offers packet classification capabilities via classifier engine which can be configured via generic flow API offered by DPDK. + +The :ref:`flow_isolated_mode` is supported. + For an additional description please refer to DPDK :doc:`../prog_guide/rte_flow`. Supported flow actions diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst index 40065284b..028c92cc3 100644 --- a/doc/guides/nics/sfc_efx.rst +++ b/doc/guides/nics/sfc_efx.rst @@ -207,6 +207,8 @@ Supported actions: Validating flow rules depends on the firmware variant. +The :ref:`flow_isolated_mode` is supported. + Ethernet destinaton individual/group match ~~ diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 472dcef47..0203f4f61 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -2557,8 +2557,10 @@ Return values: - 0 on success, a negative errno value otherwise and ``rte_errno`` is set. -Isolated mode -- +.. _flow_isolated_mode: + +Flow isolated mode +-- The general expectation for ingress traffic is that flow rules process it first; the remaining unmatched or pass-through traffic usually ends up in a -- 2.20.1
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On Wed, Jan 30, 2019 at 11:17:00AM +, Ferruh Yigit wrote: > On 1/30/2019 9:58 AM, David Marchand wrote: > > On Tue, Jan 29, 2019 at 7:07 PM Ferruh Yigit wrote: > > > >> On 1/29/2019 5:34 PM, David Marchand wrote: > >>> On Tue, Jan 29, 2019 at 4:31 PM Ferruh Yigit > >> wrote: > >>> > Fixes line commit id length defined as 12 in fixline alias: > fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae' > > Check if the Fixes line commit id length matches the defined value. > > >>> > >>> Can't git decide to report a longer string in case of collisions of > >>> abbreviated id ? > >>> > >>> Tried this for 2 characters, and git forcefully reported 5 chars: > >>> $ git log -1 --abbrev=2 origin/master --format='Fixes: %h (\"%s\")' > >>> Fixes: a2f9c (\"version: 19.02-rc4\") > >>> > >>> I did not find any collisions with 12 characters abbreviated commitid, > >> but > >>> I am not sure enforcing the check on exactly 12 characters is a good idea > >>> in the long run. > >> > >> Yes git can report a longer string in case of collisions, but I don't > >> expect to > >> have one with 12 characters. > >> > >> This is mainly for some cases either people use full 40 chars or small > >> ones. > >> > >> Indeed in background I am (and most probably Thomas too) fixing them while > >> merging, I thought it is better idea to integrate that into script so that > >> developers can be aware of the syntax issue and fix it before sending. > >> > > > > I can understand you want to avoid such edits yes, and so this patch. > > > > However, I think we can do one more thing. > > The contributing guide does indicate you are supposed to run both > > checkpatches.sh and check-git-log.sh. > > I am pretty sure I missed this second step in the past.. > > > > How about calling check-git-log.sh from checkpatches.sh ? > > check-git-log.sh does not support patch files as input, so it would need > > support for it. > > That sounds good idea to have single script to run. > +1 to this
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
30/01/2019 12:17, Ferruh Yigit: > On 1/30/2019 9:58 AM, David Marchand wrote: > > The contributing guide does indicate you are supposed to run both > > checkpatches.sh and check-git-log.sh. > > I am pretty sure I missed this second step in the past.. > > > > How about calling check-git-log.sh from checkpatches.sh ? > > check-git-log.sh does not support patch files as input, so it would need > > support for it. > > That sounds good idea to have single script to run. It will never be only one script to run. There are more scripts in devtools and I plan to add more. Some checks can be done only once for a group of commits, and will be really too slow if run for each patch when merging a branch. About check-git-log, some tests cannot be possible outside of a git tree. Do you want to run it when checkpatches is run on git tree? Wouldn't it be confusing?
Re: [dpdk-dev] [PATCH] net/pcap: fix memory leak
On 1/30/2019 1:08 AM, Qi Zhang wrote:
> Fix potential memory leak due to kvlist not be freed.
>
> Fixes: 0d0dd2d9d8ff ("net/pcap: enable data path for secondary process")
> Cc: sta...@dpdk.org
>
> Reported-by: Gage Eads
> Signed-off-by: Qi Zhang
Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On Wed, Jan 30, 2019 at 11:15:44AM +, Ferruh Yigit wrote: > On 1/29/2019 8:41 PM, Thomas Monjalon wrote: > > 29/01/2019 16:30, Ferruh Yigit: > >> Fixes line commit id length defined as 12 in fixline alias: > >> fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae' > >> > >> Check if the Fixes line commit id length matches the defined value. > > > > This check was missing on purpose, in order to not be too strict. > > I think it's OK if the length of the SHA1 is not always the same. > > That is OK, if we don't want to be strict on this, I will update patch as > rejected. > I think having this check is still good. It's not enforcing the rule, just warning when violated. In 99% of cases this warning should be fixed IMHO, especially if you guys are fixing these manually anyway. /Bruce
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
30/01/2019 12:29, Bruce Richardson: > On Wed, Jan 30, 2019 at 11:15:44AM +, Ferruh Yigit wrote: > > On 1/29/2019 8:41 PM, Thomas Monjalon wrote: > > > 29/01/2019 16:30, Ferruh Yigit: > > >> Fixes line commit id length defined as 12 in fixline alias: > > >> fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae' > > >> > > >> Check if the Fixes line commit id length matches the defined value. > > > > > > This check was missing on purpose, in order to not be too strict. > > > I think it's OK if the length of the SHA1 is not always the same. > > > > That is OK, if we don't want to be strict on this, I will update patch as > > rejected. > > > I think having this check is still good. It's not enforcing the rule, just > warning when violated. In 99% of cases this warning should be fixed IMHO, > especially if you guys are fixing these manually anyway. I don't fix it manually. I think SHA1 length has no importance. Why do you think it should be fixed?
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On Wed, Jan 30, 2019 at 12:27:58PM +0100, Thomas Monjalon wrote: > 30/01/2019 12:17, Ferruh Yigit: > > On 1/30/2019 9:58 AM, David Marchand wrote: > > > The contributing guide does indicate you are supposed to run both > > > checkpatches.sh and check-git-log.sh. > > > I am pretty sure I missed this second step in the past.. > > > > > > How about calling check-git-log.sh from checkpatches.sh ? > > > check-git-log.sh does not support patch files as input, so it would need > > > support for it. > > > > That sounds good idea to have single script to run. > > It will never be only one script to run. > There are more scripts in devtools and I plan to add more. > Some checks can be done only once for a group of commits, > and will be really too slow if run for each patch when merging a branch. > > About check-git-log, some tests cannot be possible outside of a git tree. > Do you want to run it when checkpatches is run on git tree? > Wouldn't it be confusing? > Possibly, but we can print out a warning when not run, saying "check-git-log skipped because we are not running on git tree". I think the benefit of having all checks done by one script is greater than the downside of a little confusion. /Bruce
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
On Wed, Jan 30, 2019 at 12:31:21PM +0100, Thomas Monjalon wrote: > 30/01/2019 12:29, Bruce Richardson: > > On Wed, Jan 30, 2019 at 11:15:44AM +, Ferruh Yigit wrote: > > > On 1/29/2019 8:41 PM, Thomas Monjalon wrote: > > > > 29/01/2019 16:30, Ferruh Yigit: > > > >> Fixes line commit id length defined as 12 in fixline alias: > > > >> fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae' > > > >> > > > >> Check if the Fixes line commit id length matches the defined value. > > > > > > > > This check was missing on purpose, in order to not be too strict. > > > > I think it's OK if the length of the SHA1 is not always the same. > > > > > > That is OK, if we don't want to be strict on this, I will update patch as > > > rejected. > > > > > I think having this check is still good. It's not enforcing the rule, just > > warning when violated. In 99% of cases this warning should be fixed IMHO, > > especially if you guys are fixing these manually anyway. > > I don't fix it manually. I think SHA1 length has no importance. > Why do you think it should be fixed? > Neatness and consistency. Since we provide on the site the expected syntax for the fixes line, why not check for its use? /Bruce
Re: [dpdk-dev] [RFC] lfring: lock-free ring buffer
On Wed, 2019-01-30 at 05:17 +, Eads, Gage wrote:
>
> > > 2. On the plus side, the enqueue function design that allows it to use
> > > 1/2 the atomics of mine appears to be independent of reserving ring
> > > slots, and should transfer over fairly cleanly. I'm a little concerned
> > > about the performance variability it introduces (i.e. if the thread
> > > gets into "catch up" mode),
> > If a thread has to catch up, it means it is using a stale (head/tail) index
> > (more
> > than one ring lap behaind). Better to try to load a fresh value (if one is
> > available) than to iterate over the ring until it has caught up. So I think
> > this is the
> > better/faster design.
> >
> > Catch up mode is not triggered by finding an occupied slot for the current
> > lap
> > (that was just written by some other thread). Or at least this is the idea.
> > If we
> > find a freshly written slot, we just move to the next slot.
> >
> > >
> > > particularly for larger rings, since real-time software values
> > > predictability.
> > > What if the reload criteria was instead something like:
> > >
> > > #define ENQ_RETRY_LIMIT 32 //arbitrary
> > >
> > > if (old.e.idx != tail - size) {
> > > if (++fail_cnt < ENQ_RETRY_LIMIT) {
> > > tail++;
> > > } else {
> > > fail_cnt = 0;
> > > tail = rte_lfring_reload(...);
> > > }
> > > goto restart;
> > > }
> > > fail_cnt = 0;
> > There are three cases (slot index must be between q->tail and q->head + q-
> > >
> > > size):
> > slot.idx == tail - size: slot is free, try to write it slot.idx == tail:
> > slot has just been
> > written (by other thread), skip to next slot (tail++) none of the above:
> > thread is
> > behind (at least one lap), re-load tail from q-
> > >
> > > tail
> > I think using the retry count actually delays catching up to a fresh
> > position.
> >
> Miscommunication here -- by "catch up", I meant the case where the thread is
> behind but by less than one lap (the second case you describe). In the worst
> case, the thread would have to read N-1 (N = ring size) entries before
> reaching the next available entry, and N could easily be in the thousands.
> That's the performance variability I was referring to, and why I suggested
> capping the failed slot reads at 32. Maintaining a local fail_cnt variable is
> a small price to pay (relative to a CAS) to prevent a ring enqueue latency
> spike.
OK, I misunderstood. We can reload the private tail from the shared ring buffer
tail earlier. You could actually do this on every failed CAS but I think that
would be overkill. Your design with a retry limit is better, we need to find out
what is a suitable value for the retry limit.
>
> But you're right that we should still catch the 1+ lap behind case, so the
> reload criteria could be:
>
> #define ENQ_RETRY_LIMIT 32 //arbitrary
>
> if (old.e.idx != tail - size) {
> if (++fail_cnt < ENQ_RETRY_LIMIT && old.e.idx == tail) {
> tail++;
> } else {
> fail_cnt = 0;
> tail = rte_lfring_reload(...);
> }
> goto restart;
> }
> fail_cnt = 0;
Agree.
>
> >
> > >
> > >
> > > 3. Using a zero-length array to mark the start of the ring is a nice
> > > approach
> > > -- I'll incorporate that into the patchset.
> > >
> > > At an algorithm level, I don't see any other differences.
> > > Implementation-wise, we'll need to nail the memory ordering flags to
> > > best support weak consistency machines, as you pointed out elsewhere.
> > There is no pre-acquisition of slots in enqueue and dequeue. That separate
> > step
> > makes lock-freedom impossible (I think).
> >
> Can you elaborate?
I think lock-freedom is impossible with the initial acquisition of elements.
This acquisition creates a side effect that cannot be undone or helped by other
threads.
You can still implement a "non-blocking" ring buffer (like your original
design) which hides any delay in threads that access the ring buffer but isn't
properly lock-free (which could be considered unnecessary in a DPDK
environment, threads may get delayed but shouldn't die or block forever).
> I don't currently see any other way to support rte_ring bulk semantics, which
> is necessary for creating a non-blocking mempool handler, so we should clear
> up any doubt.
OK, I wasn't aware of this strict dependency on bulk enqueue and dequeue. Bulk
dequeue (mempool allocates buffers from the ring) should be easy to support
though. Bulk enqueue (mempool frees buffers to the ring) will work as long as
the ring is large enough to hold all free buffers so it can never become full
(need to reload head/tail pointers at the appropriate places to avoid spurious
full/empty status). I assume this is the case, initially all free buffers will
be stored in the ring?
>
> In the NB ring patchset each thread reserves a number of slots before
> performing the enq/deq, but doesn't reserve *specific* slots (unlike
> rte_ring). This reservation is atomic, so that we never over-su
Re: [dpdk-dev] [PATCH] qat/compress: fix qat comp setup inter_buffers
> -Original Message-
> From: Kovacevic, Marko
> Sent: Thursday, January 24, 2019 3:03 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Yigit, Ferruh ;
> ktray...@redhat.com; Kovacevic, Marko
> ; Trahe, Fiona
> Subject: [PATCH] qat/compress: fix qat comp setup inter_buffers
>
> This patch fixes qat comp setup inter_buffers
> memory allocation size to a broader size
> then just 2MB
>
> Fixes: a124830a6f00 ("compress/qat: enable dynamic huffman encoding")
> Cc: fiona.tr...@intel.com
>
> Signed-off-by: Marko Kovacevic
Acked-by:
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
30/01/2019 12:35, Bruce Richardson: > On Wed, Jan 30, 2019 at 12:31:21PM +0100, Thomas Monjalon wrote: > > 30/01/2019 12:29, Bruce Richardson: > > > On Wed, Jan 30, 2019 at 11:15:44AM +, Ferruh Yigit wrote: > > > > On 1/29/2019 8:41 PM, Thomas Monjalon wrote: > > > > > 29/01/2019 16:30, Ferruh Yigit: > > > > >> Fixes line commit id length defined as 12 in fixline alias: > > > > >> fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae' > > > > >> > > > > >> Check if the Fixes line commit id length matches the defined value. > > > > > > > > > > This check was missing on purpose, in order to not be too strict. > > > > > I think it's OK if the length of the SHA1 is not always the same. > > > > > > > > That is OK, if we don't want to be strict on this, I will update patch > > > > as rejected. > > > > > > > I think having this check is still good. It's not enforcing the rule, just > > > warning when violated. In 99% of cases this warning should be fixed IMHO, > > > especially if you guys are fixing these manually anyway. > > > > I don't fix it manually. I think SHA1 length has no importance. > > Why do you think it should be fixed? > > > Neatness and consistency. Since we provide on the site the expected syntax > for the fixes line, why not check for its use? OK, I'm not against the check.
Re: [dpdk-dev] [PATCH] devtools: check commit log fixes syntax
30/01/2019 12:31, Bruce Richardson: > On Wed, Jan 30, 2019 at 12:27:58PM +0100, Thomas Monjalon wrote: > > 30/01/2019 12:17, Ferruh Yigit: > > > On 1/30/2019 9:58 AM, David Marchand wrote: > > > > The contributing guide does indicate you are supposed to run both > > > > checkpatches.sh and check-git-log.sh. > > > > I am pretty sure I missed this second step in the past.. > > > > > > > > How about calling check-git-log.sh from checkpatches.sh ? > > > > check-git-log.sh does not support patch files as input, so it would need > > > > support for it. > > > > > > That sounds good idea to have single script to run. > > > > It will never be only one script to run. > > There are more scripts in devtools and I plan to add more. > > Some checks can be done only once for a group of commits, > > and will be really too slow if run for each patch when merging a branch. > > > > About check-git-log, some tests cannot be possible outside of a git tree. > > Do you want to run it when checkpatches is run on git tree? > > Wouldn't it be confusing? > > > Possibly, but we can print out a warning when not run, saying > "check-git-log skipped because we are not running on git tree". I think the > benefit of having all checks done by one script is greater than the > downside of a little confusion. OK
Re: [dpdk-dev] Compiler for Windows
08/01/2019 11:24, Burakov, Anatoly: > On 07-Jan-19 5:08 PM, Thomas Monjalon wrote: > > 07/01/2019 18:00, Bruce Richardson: > >> I think for windows we probably want to start with the MS compiler first, > >> since from my understanding it's probably the default go-to compiler for > >> developers on windows, and look at alternatives from there. > > > > Not sure. I feel clang is a better option. > > This is the purpose of this thread: which compiler can work > > with the DPDK code base? Which modifications of code are acceptable? > > > > Unfortunately we lost my original attempt of getting some facts. > > i'm developing on a Windows machine, and use clang as code analyzer. so > while the compiling and linking may take some effort, the bulk of it > appears to be working without too much complaints from clang. it's easy > to install as well - just install LLVM and you're good to go. This discussion continued in a private thread (for no good reason). Let's conclude here publicly. About the compiler, - cygwin is not native -> no go - mingw-w64 (latest) brings a specific DLL -> one more unknown piece - icc is not free -> no go - msvc supports not all C99 and GNU extensions -> difficult to support - clang is now native on Windows -> best choice http://releases.llvm.org/7.0.1/LLVM-7.0.1-win64.exe About the build system, - DPDK makefiles are not Windows-friendly and will be removed - meson is supported on Windows and can generate VS project https://github.com/mesonbuild/meson/releases/download/0.49.1/meson-0.49.1-64.msi About the Linux/BSD code, - we can use some #ifdef - most of the specific code should be in EAL - it must be tried to share a maximum of common code About the steps, 1/ meson files must be prepared for Windows target 2/ EAL for Windows must be an empty stub first 3/ The core libraries must compile with meson+clang 4/ Documentation for Windows must be started 5/ EAL for Windows can be completed with real code 6/ PMDs can be tested on Windows 7/ Examples should compile on Windows Please restart from a fresh 19.02 branch in the draft repository and submit the steps one by one on the mailing list. We need to validate the steps and approve the choices. If some choices are done, they must be explained in the commit logs. The commits must be small enough to be reviewed. If some issues are encountered, we'll fix them as a community. Thanks for facilitating community adoption of Windows port.
[dpdk-dev] [PATCH] net/virtio: set offload flag for jumbo frames
Port configuration fails when offload flags don't match the expected
value, e.g. when max-pkt-len is set to a value that should enable
receive port offloading but doesn't.
This can be triggered by running testpmd e.g. with --max-pkt-len=2000.
It will fail with "Ethdev port_id=0 requested Rx offloads 0x800 doesn't
match Rx offloads capabilities 0x20d in rte_eth_dev_configure()"
To fix this there are two cases to consider:
1. VIRTIO_NET_F_MTU is negotiated. Then we need to check if the
requested max. packet length fits into the MTU. If yes we set the
offload flag.
2. VIRTIO_NET_F_MTU is not negotiated. We can set the offload flag.
Signed-off-by: Jens Freimann
---
drivers/net/virtio/virtio_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 7c4c1df00..e0d6542d4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2351,6 +2351,17 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
if ((host_features & tso_mask) == tso_mask)
dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TCP_LRO;
+ if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
+ struct virtio_net_config config;
+ vtpci_read_dev_config(hw,
+ offsetof(struct virtio_net_config, mtu),
+ &config.mtu, sizeof(config.mtu));
+ if (dev->data->dev_conf.rxmode.max_rx_pkt_len <= config.mtu)
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ } else {
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ }
+
dev_info->tx_offload_capa = DEV_TX_OFFLOAD_MULTI_SEGS |
DEV_TX_OFFLOAD_VLAN_INSERT;
if (host_features & (1ULL << VIRTIO_NET_F_CSUM)) {
--
2.17.2
Re: [dpdk-dev] [PATCH] net/virtio: set offload flag for jumbo frames
On 1/30/19 4:26 PM, Jens Freimann wrote:
Port configuration fails when offload flags don't match the expected
value, e.g. when max-pkt-len is set to a value that should enable
receive port offloading but doesn't.
This can be triggered by running testpmd e.g. with --max-pkt-len=2000.
It will fail with "Ethdev port_id=0 requested Rx offloads 0x800 doesn't
match Rx offloads capabilities 0x20d in rte_eth_dev_configure()"
To fix this there are two cases to consider:
1. VIRTIO_NET_F_MTU is negotiated. Then we need to check if the
requested max. packet length fits into the MTU. If yes we set the
offload flag.
2. VIRTIO_NET_F_MTU is not negotiated. We can set the offload flag.
I think we need to Cc: stable and point to the commit introducing the
regression. I think it is the one introducing the use of
DEV_RX_OFFLOAD_JUMBO_FRAME in Virtio PMD.
Signed-off-by: Jens Freimann
---
drivers/net/virtio/virtio_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 7c4c1df00..e0d6542d4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2351,6 +2351,17 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
if ((host_features & tso_mask) == tso_mask)
dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TCP_LRO;
+ if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
+ struct virtio_net_config config;
+ vtpci_read_dev_config(hw,
+ offsetof(struct virtio_net_config, mtu),
+ &config.mtu, sizeof(config.mtu));
+ if (dev->data->dev_conf.rxmode.max_rx_pkt_len <= config.mtu)
That is not exactly right, MTU does not take into account the Ethernet
header, the VLAN tag and the virtio-net header.
See virtio_mtu_set() for example.
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ } else {
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ }
+
dev_info->tx_offload_capa = DEV_TX_OFFLOAD_MULTI_SEGS |
DEV_TX_OFFLOAD_VLAN_INSERT;
if (host_features & (1ULL << VIRTIO_NET_F_CSUM)) {
Re: [dpdk-dev] [PATCH] net/virtio: set offload flag for jumbo frames
On Wed, Jan 30, 2019 at 04:41:55PM +0100, Maxime Coquelin wrote:
On 1/30/19 4:26 PM, Jens Freimann wrote:
Port configuration fails when offload flags don't match the expected
value, e.g. when max-pkt-len is set to a value that should enable
receive port offloading but doesn't.
This can be triggered by running testpmd e.g. with --max-pkt-len=2000.
It will fail with "Ethdev port_id=0 requested Rx offloads 0x800 doesn't
match Rx offloads capabilities 0x20d in rte_eth_dev_configure()"
To fix this there are two cases to consider:
1. VIRTIO_NET_F_MTU is negotiated. Then we need to check if the
requested max. packet length fits into the MTU. If yes we set the
offload flag.
2. VIRTIO_NET_F_MTU is not negotiated. We can set the offload flag.
I think we need to Cc: stable and point to the commit introducing the
regression. I think it is the one introducing the use of
DEV_RX_OFFLOAD_JUMBO_FRAME in Virtio PMD.
ok
Signed-off-by: Jens Freimann
---
drivers/net/virtio/virtio_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 7c4c1df00..e0d6542d4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2351,6 +2351,17 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
if ((host_features & tso_mask) == tso_mask)
dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TCP_LRO;
+ if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
+ struct virtio_net_config config;
+ vtpci_read_dev_config(hw,
+ offsetof(struct virtio_net_config, mtu),
+ &config.mtu, sizeof(config.mtu));
+ if (dev->data->dev_conf.rxmode.max_rx_pkt_len <= config.mtu)
That is not exactly right, MTU does not take into account the Ethernet
header, the VLAN tag and the virtio-net header.
See virtio_mtu_set() for example.
I wasn't sure about it, will send a v2. Thanks for the review!
regards,
Jens
[dpdk-dev] 18.08.1 patches review and test
Hi all, Here is a list of patches targeted for stable release 18.08.1. Please help review and test. The tentative date for the final release is 28, February. Before that, please shout if anyone has objections with these patches being applied. Also for the companies committed to running regression tests, please run the tests and report any issue before the release date. A release candidate tarball can be found at: https://dpdk.org/browse/dpdk-stable/tag/?id=v18.08.1-rc3 These patches are located at branch 18.08 of dpdk-stable repo: https://dpdk.org/browse/dpdk-stable/ Thanks. Kevin Traynor --- Adrien Mazarguil (1): net/mlx5: fix artificial L4 limitation on switch flow rules Agalya Babu RadhaKrishnan (4): vfio: disable in FreeBSD build with meson net/nfp: disable in FreeBSD build with meson net/avp: disable in FreeBSD build with meson net/softnic: disable in FreeBSD build with meson Ajit Khaparde (4): net/bnxt: fix MTU setting net/bnxt: set MAC filtering as outer for non tunnel frames net/bnxt: set a VNIC as default only once net/bnxt: remove excess log messages Akash Saxena (1): crypto/openssl: fix RSA verify operation Alejandro Lucero (6): ethdev: fix MAC changes when live change not supported net/nfp: fix live MAC changes not supported net/nfp: fix mbuf flags with checksum good ethdev: fix error handling in create function net/nfp: fix RSS bus/pci: compare kernel driver instead of interrupt handler Ali Alnubani (4): net/mlx4: fix minor typo net/mlx5: fix minor typos net/mlx4: fix initialization of struct members net/mlx5: fix initialization of struct members Anatoly Burakov (10): fbarray: fix detach in --no-shconf mode eal: do not allow legacy mode with --in-memory mode mem: fix undefined behavior in NUMA-aware mapping mem: improve segment list preallocation mem: fix resource leak ipc: remove panic in async request malloc: fix adjacency check to also include segment list usertools: check for lspci dependency ipc: fix access after async request failure mem: fix division by zero in no-NUMA mode Andrew Rybchenko (2): net/sfc/base: fix build because of no declaration net/sfc: receive prepared packets even in Rx exception case Andy Moreton (4): net/sfc/base: properly align on line continuation net/sfc/base: add space after sizeof net/sfc/base: fix ID retrieval in v3 licensing net/sfc/base: fix MAC Tx stats for less or equal to 64 bytes Anoob Joseph (5): examples/ipsec-secgw: fix wrong session size app/test-crypto-perf: fix check for auth key app/test-crypto-perf: fix check for cipher IV app/test-crypto-perf: fix double allocation of memory net/octeontx: fix failures when available ports > queues Asaf Penso (1): net/mlx5: fix function documentation Bei Sun (1): net/bnxt: set VLAN strip mode before default VNIC cfg Beilei Xing (5): net/e1000: fix queue number in RSS configuration net/avf: remove keeping CRC configuration net/i40e: update Tx offload mask net/i40e: fix Rx instability with vector mode net/i40e: fix X710 Rx after reading some registers Brian Archbold (1): app/testpmd: fix duplicate exit Bruce Richardson (3): compat: fix symbol version support with meson net/avf: fix unused variables and label net/avf: fix missing compiler error flags Chaitanya Babu Talluri (1): efd: fix write unlock during ring creation Chas Williams (2): net/bonding: fix Rx slave fairness net/virtio: do not re-enter clean up routines Cristian Dumitrescu (1): examples/ip_pipeline: fix port and table stats read Damjan Marion (1): net/i40e: fix 25G AOC and ACC cable detection on XXV710 Darek Stojaczyk (4): malloc: check size hint when reserving the biggest element vfio: fix read of freed memory on getting container fd vfio: share default container in multi-process vfio: do not needlessly setup device in secondary process Dariusz Stojaczyk (2): ipc: fix undefined behavior in no-shconf mode vfio: check if group fd is already open David Hunt (1): examples/vm_power: respect maximum CPUs David Marchand (1): devtools: fix symbol check when adding experimental section Dekel Peled (3): ethdev: fix missing names in Tx offload name array net/mlx5: fix packet type for MPLS in UDP net/mlx5: fix validation of Rx queue number Dharmik Thakkar (1): test/hash: fix build Didier Pallard (7): net: fix Intel prepare function for IP checksum offload net/e1000: fix missing Tx multi-segs capability net/fm10k: fix missing Tx multi-segs capability net/i40e: fix missing Tx multi-segs capability net/ixgbe: fix missing Tx multi-segs capability drivers/net: fix several Tx prepare fu
Re: [dpdk-dev] Compiler for Windows
Thank you for the direction, Thomas and Tech Board members. If clang-win64 has support for GCC extensions (__attribute(constructor/align/etc...)), then the changes to common DPDK code should be minimal. Also, Jeff got meson to output VS project files to compile with MSVC - we'll just need to make sure that they can compile with clang-win64. Thanks, Bruce for helping us out here. ranjit m. -Original Message- From: Thomas Monjalon Sent: Wednesday, January 30, 2019 6:21 AM To: 'Jason Messer' ; 'Harini Ramakrishnan' ; 'Omar Cardona' ; Menon, Ranjit Cc: dev@dpdk.org; Burakov, Anatoly ; Richardson, Bruce ; Stephen Hemminger ; 'Mattias Rönnblom' ; Shaw, Jeffrey B ; techbo...@dpdk.org Subject: Re: [dpdk-dev] Compiler for Windows 08/01/2019 11:24, Burakov, Anatoly: > On 07-Jan-19 5:08 PM, Thomas Monjalon wrote: > > 07/01/2019 18:00, Bruce Richardson: > >> I think for windows we probably want to start with the MS compiler > >> first, since from my understanding it's probably the default go-to > >> compiler for developers on windows, and look at alternatives from there. > > > > Not sure. I feel clang is a better option. > > This is the purpose of this thread: which compiler can work with the > > DPDK code base? Which modifications of code are acceptable? > > > > Unfortunately we lost my original attempt of getting some facts. > > i'm developing on a Windows machine, and use clang as code analyzer. > so while the compiling and linking may take some effort, the bulk of > it appears to be working without too much complaints from clang. it's > easy to install as well - just install LLVM and you're good to go. This discussion continued in a private thread (for no good reason). Let's conclude here publicly. About the compiler, - cygwin is not native -> no go - mingw-w64 (latest) brings a specific DLL -> one more unknown piece - icc is not free -> no go - msvc supports not all C99 and GNU extensions -> difficult to support - clang is now native on Windows -> best choice http://releases.llvm.org/7.0.1/LLVM-7.0.1-win64.exe About the build system, - DPDK makefiles are not Windows-friendly and will be removed - meson is supported on Windows and can generate VS project https://github.com/mesonbuild/meson/releases/download/0.49.1/meson-0.49.1-64.msi About the Linux/BSD code, - we can use some #ifdef - most of the specific code should be in EAL - it must be tried to share a maximum of common code About the steps, 1/ meson files must be prepared for Windows target 2/ EAL for Windows must be an empty stub first 3/ The core libraries must compile with meson+clang 4/ Documentation for Windows must be started 5/ EAL for Windows can be completed with real code 6/ PMDs can be tested on Windows 7/ Examples should compile on Windows Please restart from a fresh 19.02 branch in the draft repository and submit the steps one by one on the mailing list. We need to validate the steps and approve the choices. If some choices are done, they must be explained in the commit logs. The commits must be small enough to be reviewed. If some issues are encountered, we'll fix them as a community. Thanks for facilitating community adoption of Windows port.
[dpdk-dev] [RFC,v2] lfring: lock-free ring buffer
Lock-free MP/MC ring buffer with SP/SC options.
The ring buffer metadata only maintains one set of head and tail
indexes. Tail is updated on enqueue, head is updated on dequeue.
The ring slots between head and tail always contains valid (unconsumed)
slots.
Each ring slot consists of a struct of data pointer ("ptr") and lap
counter ("lap"). Slot.lap is only updated on enqueue with the new lap
counter (ring index / ring size). The slot lap conuter is used to ensure
that slots are written sequentially (important for FIFO ordering). It is
also used to synchronise multiple producers.
MP enqueue scans the ring from the tail until head+size, looking for an
empty slot as indicated by slot.lap equaling the lap counter of
the previous lap ((index - ring size) / ring size). The empty slot is
written (.ptr = data, .lap = index / ring size) using CAS. If CAS fails,
some other thread wrote the slot and the thread continues with the next slot.
There is some logic to detect that the thread has fallen behind and should
reload the shared tail index instead of just trying the next slot.
When all elements have been enqueued or if the ring buffer is full, the
thread updates the ring buffer tail index (unless this has not already
been updated by some other thread). The test is using "sequence number
arithmetic". Thus this thread will help other threads that have written
ring slots but not yet updated the shared tail index.
If a slot with a lap counter different from current or previous lap is
found, it is assumed that the thread has fallen behind (e.g. been preempted)
and the local tail index is (conditionally) updated from the ring buffer
metadata in order to quickly catch up.
MP dequeue ensures at least N elements are available and reads the slots
from the shared head index and attempts to commit the operation using
CAS on the shared head index.
Enqueue N elements: N+1 CAS operations (but the last CAS operation might
not be necessary during contention as producers will help each other)
Dequeue N elements: 1 CAS operation
Single-threaded (SP/SC) enqueue and dequeue operations will inter-operate
with MT-safe (MP/MC) operations but it is the responsibility of the user
to ensure single-threaded operations are safe to use.
128-bit lock-free atomic compare exchange operations for AArch64
(ARMv8.0) and x86-64 are provided in lockfree16.h. I expect these
functions to find a different home and possibly a different API.
Note that a 'frail' version atomic_compare_exchange is implemented,
this means that in the case of failure, the old value returned is
not guaranteed to be atomically read (as this is not possible on ARMv8.0
without also writing to the location). Atomically read values are
often not necessary, it is a successful compare and exchange operation
which provides atomicity.
Changes from v1:
* Fix check-patch warnings
* Use lap counter instead of ring index in ring slots
* Support for 32-bit architectures
* Prepend '_' to internal functions in rte_lfring.h
* Change name of public MP/MC/SP/SC bulk enqueue/dequeue functions to
match rte_ring pattern
* Perform only fixed amount of retries in enqueue before reloading
shared ring buffer tail index to (hopefully) quicker catch up
* Reload shared ring buffer tail on every iteration in dequeue in order
to avoid spurious queue empty situations
* Dequeue requires nelems element to be available in order to do bulk
dequeue.
* Use rte_smp_rmb() + atomic store (or cas)-relaxed instead of store
(or cas)-release in dequeue functions as we only read shared data.
This avoids ordering stores to private data.
Signed-off-by: Ola Liljedahl
---
config/common_base | 5 +
lib/Makefile | 2 +
lib/librte_lfring/Makefile | 22 ++
lib/librte_lfring/lockfree16.h | 143 +++
lib/librte_lfring/meson.build| 6 +
lib/librte_lfring/rte_lfring.c | 264 +
lib/librte_lfring/rte_lfring.h | 621 +++
lib/librte_lfring/rte_lfring_version.map | 19 +
8 files changed, 1082 insertions(+)
create mode 100644 lib/librte_lfring/Makefile
create mode 100644 lib/librte_lfring/lockfree16.h
create mode 100644 lib/librte_lfring/meson.build
create mode 100644 lib/librte_lfring/rte_lfring.c
create mode 100644 lib/librte_lfring/rte_lfring.h
create mode 100644 lib/librte_lfring/rte_lfring_version.map
diff --git a/config/common_base b/config/common_base
index 7c6da51..375f9c3 100644
--- a/config/common_base
+++ b/config/common_base
@@ -719,6 +719,11 @@ CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV=y
CONFIG_RTE_LIBRTE_RING=y
#
+# Compile librte_lfring
+#
+CONFIG_RTE_LIBRTE_LFRING=y
+
+#
# Compile librte_mempool
#
CONFIG_RTE_LIBRTE_MEMPOOL=y
diff --git a/lib/Makefile b/lib/Makefile
index d6239d2..cd46339 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -12,6 +12,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_PCI) += librte_pci
DEPDIRS-librte_pci := librte_eal
DIRS-$(CONFIG_R
[dpdk-dev] [PATCH] doc: remove note about meson being experimental
At this stage, meson builds are widely supported for DPDK, and so the build system should be no longer called out as experimental. NOTE: this does not imply it's the primary build system, just that it's safe to use for day-to-day work and for packaging if so desired. Signed-off-by: Bruce Richardson --- doc/build-sdk-meson.txt | 5 - 1 file changed, 5 deletions(-) diff --git a/doc/build-sdk-meson.txt b/doc/build-sdk-meson.txt index 29a8bd387..0a3316386 100644 --- a/doc/build-sdk-meson.txt +++ b/doc/build-sdk-meson.txt @@ -1,11 +1,6 @@ INSTALLING DPDK USING THE MESON BUILD SYSTEM - -NOTE: Compiling and installing DPDK using ``meson`` and ``ninja``, rather -than using ``make`` (GNU make) is EXPERIMENTAL. Official builds of DPDK -should always be done using ``make``, as described in the ``Getting Started -Guide`` documentation, and at "http://core.dpdk.org/doc/quick-start";. - Summary For many platforms, compiling and installing DPDK should work using the -- 2.20.1
[dpdk-dev] [PATCH v2] net/virtio: set offload flag for jumbo frames
Port configuration fails because offload flags don't match the expected
value when max-pkt-len is set to a value that should enable receive port
offloading but doesn't.
There are two cases to consider:
1. VIRTIO_NET_F_MTU is set. Then we need to check if the requested
max-pkt-len fits into the MTU plus header. If yes we set the offload flag.
2. VIRTIO_NET_F_MTU is not set. We can set the offload flag.
Fixes: a4996bd89c42 (""ethdev: new Rx/Tx offloads API)
Cc: sta...@dpdk.org
Signed-off-by: Jens Freimann
---
v1->v2:
* include virtnet hdr, ethernet header, vlan tag when comparing against
max-rx-pkt-len (Maxime)
drivers/net/virtio/virtio_ethdev.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 7c4c1df00..863fbe909 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2351,6 +2351,20 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
if ((host_features & tso_mask) == tso_mask)
dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TCP_LRO;
+ if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
+ struct virtio_net_config config;
+ uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
+ hw->vtnet_hdr_size;
+ vtpci_read_dev_config(hw,
+ offsetof(struct virtio_net_config, mtu),
+ &config.mtu, sizeof(config.mtu));
+ if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=
+ (config.mtu + ether_hdr_len))
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ } else {
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ }
+
dev_info->tx_offload_capa = DEV_TX_OFFLOAD_MULTI_SEGS |
DEV_TX_OFFLOAD_VLAN_INSERT;
if (host_features & (1ULL << VIRTIO_NET_F_CSUM)) {
--
2.17.2
[dpdk-dev] [PATCH v2 1/2] examples/vhost_scsi: Don't build without virtio_scsi.h
From: Aaron Conole
The vhost_scsi example code is set to build, even if the requisite header
file virtio_scsi.h isn't available. This happens on some Ubuntu systems
when some versions of the libc-dev package aren't available.
Check whether the virtio_scsi.h file exists, and if not, set the build
flag to false.
Signed-off-by: Aaron Conole
---
v2:
Introduced.
examples/vhost_scsi/meson.build | 6 ++
1 file changed, 6 insertions(+)
diff --git a/examples/vhost_scsi/meson.build b/examples/vhost_scsi/meson.build
index 2303bcaed..3bff05c81 100644
--- a/examples/vhost_scsi/meson.build
+++ b/examples/vhost_scsi/meson.build
@@ -9,6 +9,12 @@
if host_machine.system() != 'linux'
build = false
endif
+
+cc = meson.get_compiler('c')
+if not cc.has_header('virtio_scsi.h')
+ build = false
+endif
+
deps += 'vhost'
cflags += ['-D_FILE_OFFSET_BITS=64']
sources = files(
--
2.19.1
[dpdk-dev] [PATCH v2 0/2] Introduce travis support
This series introduces the ability for any github mirrors of the DPDK project, including developer mirrors, to kick off builds under the travis CI infrastructure. For now, this just means compilation - no other kinds of automated run exists yet. In the future, this can be expanded to execute and report results for any test-suites that might exist. The series includes support for both the 'classic make' style builds (which are set to be deprecated at some undetermined point in the future), as well as the modern meson+ninja build system. Additionally, there is support for building the ARM64 target with both the meson and make systems. The files added under .ci/ exist so that in the future, other CI support platforms (such as cirrus, appveyor, etc.) could have a common place to put their requisite scripts without polluting the main tree. Some documentation is updated, making developers aware of the new travis integration. The integration can also be included on the official DPDK mirror. Build reports can be enabled by subscribing the travis build email to the test-reports mailing list (this can be done independent of this series being applied). v1 -> v2: - Added patch 1/2, "examples/vhost_scsi: don't build..." - Included arm64 builds - Included multiple meson+ninja builds (full library, minimal library) - Included multiple 'classic make' builds Aaron Conole (2): examples/vhost_scsi: Don't build without virtio_scsi.h ci: Introduce travis builds for github repositories .ci/linux-build.sh | 88 +++ .ci/linux-setup.sh | 31 ++ .travis.yml | 160 MAINTAINERS | 7 ++ doc/guides/contributing/patches.rst | 4 + examples/vhost_scsi/meson.build | 6 ++ meson_cross_aarch64_gcc.txt | 12 +++ 7 files changed, 308 insertions(+) create mode 100755 .ci/linux-build.sh create mode 100755 .ci/linux-setup.sh create mode 100644 .travis.yml create mode 100644 meson_cross_aarch64_gcc.txt -- 2.19.1
[dpdk-dev] [PATCH v2 2/2] ci: Introduce travis builds for github repositories
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole
Signed-off-by: Michael Santana
---
v2:
- Added aarch64 build
- Added multiple meson options for builds
- Added multiple make/config options for builds
.ci/linux-build.sh | 88 +++
.ci/linux-setup.sh | 31 ++
.travis.yml | 159
MAINTAINERS | 7 ++
doc/guides/contributing/patches.rst | 4 +
meson_cross_aarch64_gcc.txt | 12 +++
6 files changed, 301 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
create mode 100644 meson_cross_aarch64_gcc.txt
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 0..66d031a21
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+
+# check for whether we're clang or gcc
+# setup the right options depending on the environment variables
+# run the build
+
+# Just used for the 'classic' configuration system (ie: make)
+set_conf() {
+echo "[BUILT WITH $2 SET TO $3]"
+c="$1/.config"
+shift
+
+if grep -q "$1" "$c"; then
+sed -i "s:^$1=.*$:$1=$2:g" $c
+else
+echo $1=$2 >> "$c"
+fi
+}
+
+BUILD_ARCH="x86_64-native-linuxapp-"
+
+if [ "${ARM64}" == "1" ]; then
+# convert the arch specifier
+BUILD_ARCH="arm64-armv8a-linuxapp-"
+ARM64_TOOL="linaro-arm-tool"
+export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+fi
+
+
+if [ "${NINJABUILD}" == "1" ]; then
+OPTS=""
+
+DEF_LIB="static"
+if [ "${SHARED}" == "1" ]; then
+DEF_LIB="shared"
+fi
+
+if [ "${KERNEL}" == "1" ]; then
+OPTS="-Denable_kmods=false"
+fi
+
+if [ "${ARM64}" == "1" ]; then
+OPTS="${OPTS} --cross-file meson_cross_aarch64_${CC}.txt"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all ${OPTS}
+ninja -C build
+else
+EXTRA_OPTS=""
+
+make config T="${BUILD_ARCH}${CC}"
+
+set_conf build CONFIG_RTE_KNI_KMOD n
+set_conf build CONFIG_RTE_EAL_IGB_UIO n
+
+if dpkg --list | grep -q zlib1g ; then
+set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
+fi
+
+if dpkg --list | grep -q libpcap-dev ; then
+set_conf build CONFIG_RTE_PORT_PCAP y
+fi
+
+if [ "${SHARED}" == "1" ]; then
+set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
+fi
+
+if [ "${KERNEL}" == "1" ]; then
+echo Unsupported kernel builds at the moment
+fi
+
+if [ "${ARM64}" == "1" ]; then
+EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
+
+# need to turn off these extras
+set_conf build CONFIG_RTE_PORT_PCAP n
+set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
+
+# convert the CC/CXX variables
+export CC=aarch64-linux-gnu-${CC}
+export CXX=aarch64-linux-gnu-${CXX}
+export AR=aarch64-linux-gnu-ar
+export STRIP=aarch64-linux-gnu-strip
+fi
+
+make all ${EXTRA_OPTS}
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 0..7d6478ef9
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+python3.5 -m pip install --upgrade meson --user
+
+echo "ARM64 is [ ${ARM64} ]"
+
+if [ "${ARM64}" == "1" ]; then
+# need to build & install libnuma
+# This will only be minimal support for now.
+
ARM64_TOOL_URL='https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz'
+ARM64_TOOL="linaro-arm-tool"
+NUMA_GIT_URL="https://github.com/numactl/numactl.git";
+
+wget -O "${ARM64_TOOL}.tar.xz" "${ARM64_TOOL_URL}"
+tar -xf "${ARM64_TOOL}.tar.xz"
+mv gcc-linaro* "${ARM64_TOOL}"
+export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+git clone "${NUMA_GIT_URL}"
+cd numactl
+git checkout v2.0.11
+./autogen.sh
+autoconf -i
+mkdir numa_bin
+./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
+--prefix=$(pwd)/numa_bin
+make install # install numa
+cd ..
+cp numactl/numa_bin/include/numa*.h
"${ARM64_TOOL}/aarch64-linux-gnu/libc/usr/include/"
+cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/aarch64-linux-gnu/lib64/"
+cp numactl
[dpdk-dev] [PATCH] build: add option to override max ethports
Allow users and packagers to override the default RTE_MAX_ETHPORTS.
This adds a new meson option, max_ethports which defaults to the
current value.
Signed-off-by: Chas Williams <3ch...@gmail.com>
---
config/meson.build | 1 +
config/rte_config.h | 1 -
meson_options.txt | 2 ++
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/config/meson.build b/config/meson.build
index db32499b3..e59507065 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -103,6 +103,7 @@ endforeach
# set other values pulled from the build options
dpdk_conf.set('RTE_MAX_LCORE', get_option('max_lcores'))
dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes'))
+dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
dpdk_conf.set('RTE_EAL_ALLOW_INV_SOCKET_ID',
get_option('allow_invalid_socket_id'))
# values which have defaults which may be overridden
diff --git a/config/rte_config.h b/config/rte_config.h
index d3732e953..7606f5d7b 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -51,7 +51,6 @@
#define RTE_PKTMBUF_HEADROOM 128
/* ether defines */
-#define RTE_MAX_ETHPORTS 32
#define RTE_MAX_QUEUES_PER_PORT 1024
#define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
#define RTE_ETHDEV_RXTX_CALLBACKS 1
diff --git a/meson_options.txt b/meson_options.txt
index 574054597..e54eedc66 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -28,3 +28,5 @@ option('use_hpet', type: 'boolean', value: false,
description: 'use HPET timer in EAL')
option('tests', type: 'boolean', value: true,
description: 'build unit tests')
+option('max_ethports', type: 'string', value: '32',
+ description: 'maximum number of Ethernet devices in EAL')
--
2.17.2
Re: [dpdk-dev] [PATCH 1/1] eal: add 128-bit cmpset (x86-64 only)
>
> This operation can be used for non-blocking algorithms, such as a non-
> blocking stack or ring.
>
> Signed-off-by: Gage Eads
> ---
> .../common/include/arch/x86/rte_atomic_64.h| 31 +++
> lib/librte_eal/common/include/generic/rte_atomic.h | 65
> ++
> 2 files changed, 96 insertions(+)
>
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> index fd2ec9c53..b7b90b83e 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> @@ -34,6 +34,7 @@
> /*
> * Inspired from FreeBSD src/sys/amd64/include/atomic.h
> * Copyright (c) 1998 Doug Rabson
> + * Copyright (c) 2019 Intel Corporation
> * All rights reserved.
> */
>
> @@ -46,6 +47,7 @@
>
> #include
> #include
> +#include
> #include
>
> /*- 64 bit atomic operations
> -*/ @@ -
> 208,4 +210,33 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v) }
> #endif
>
> +static inline int __rte_experimental
> +rte_atomic128_cmpset(volatile rte_int128_t *dst,
Does it make sense to call is rte_atomic128_compare_exchange (or ..._cmp_xchg)
to indicate it is a compare-exchange operation?
> + rte_int128_t *exp, rte_int128_t *src,
> + unsigned int weak,
> + enum rte_atomic_memmodel_t success,
> + enum rte_atomic_memmodel_t failure) {
> + RTE_SET_USED(weak);
> + RTE_SET_USED(success);
> + RTE_SET_USED(failure);
> + uint8_t res;
> +
> + asm volatile (
> + MPLOCKED
> + "cmpxchg16b %[dst];"
> + " sete %[res]"
> + : [dst] "=m" (dst->val[0]),
> + "=A" (exp->val[0]),
> + [res] "=r" (res)
> + : "c" (src->val[1]),
> + "b" (src->val[0]),
> + "m" (dst->val[0]),
> + "d" (exp->val[1]),
> + "a" (exp->val[0])
> + : "memory");
> +
> + return res;
> +}
> +
> #endif /* _RTE_ATOMIC_X86_64_H_ */
> diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h
> b/lib/librte_eal/common/include/generic/rte_atomic.h
> index b99ba4688..8d612d566 100644
> --- a/lib/librte_eal/common/include/generic/rte_atomic.h
> +++ b/lib/librte_eal/common/include/generic/rte_atomic.h
> @@ -14,6 +14,7 @@
>
> #include
> #include
> +#include
>
> #ifdef __DOXYGEN__
>
> @@ -1082,4 +1083,68 @@ static inline void
> rte_atomic64_clear(rte_atomic64_t *v) } #endif
>
> +/* 128 bit atomic operations
> +-*/
> +
> +/**
> + * 128-bit integer structure.
> + */
> +typedef struct {
> + uint64_t val[2];
> +} __rte_aligned(16) rte_int128_t;
It looks like '__int128' is available from gcc 4.6. I think we should use
'__int128'. We can have it as an internal structure for ease of programming.
> +
> +/**
> + * Memory consistency models used in atomic operations. These control
> +the
> + * behavior of the operation with respect to memory barriers and
> + * thread synchronization.
> + *
> + * These directly match those in the C++11 standard; for details on
> +their
> + * behavior, refer to the standard.
> + */
> +enum rte_atomic_memmodel_t {
> + RTE_ATOMIC_RELAXED,
> + RTE_ATOMIC_CONSUME,
> + RTE_ATOMIC_ACQUIRE,
> + RTE_ATOMIC_RELEASE,
> + RTE_ATOMIC_ACQ_REL,
> + RTE_ATOMIC_SEQ_CST,
> +};
IMO, we can use the GCC provided names. I do not see any advantage to defining
our own.
> +
> +/* Only implemented on x86-64 currently. The ifdef prevents compilation
> +from
> + * failing for architectures without a definition of this function.
> + */
Minor comment. We can skip the above comments, the #if below is pretty obvious.
> +#if defined(RTE_ARCH_X86_64)
> +/**
> + * An atomic compare and set function used by the mutex functions.
> + * (atomic) equivalent to:
> + * if (*dst == exp)
> + * *dst = src (all 128-bit words)
> + *
> + * @param dst
> + * The destination into which the value will be written.
> + * @param exp
> + * Pointer to the expected value. If the operation fails, this memory is
> + * updated with the actual value.
> + * @param src
> + * Pointer to the new value.
> + * @param weak
> + * A value of true allows the comparison to spuriously fail.
> Implementations
> + * may ignore this argument and only implement the strong variant.
> + * @param success
> + * If successful, the operation's memory behavior conforms to this (or a
> + * stronger) model.
> + * @param failure
> + * If unsuccessful, the operation's memory behavior conforms to this (or a
> + * stronger) model. This argument cannot be RTE_ATOMIC_RELEASE,
> + * RTE_ATOMIC_ACQ_REL, or a stronger model than success.
> + * @return
> + * Non-zero on success; 0 on failure.
> + */
> +
Re: [dpdk-dev] [PATCH 0/3] more doc about isolated mode and bifurcated model
Wednesday, January 30, 2019 1:20 PM, Thomas Monjalon: > Subject: [dpdk-dev] [PATCH 0/3] more doc about isolated mode and > bifurcated model > > The flow isolated mode lacks some advertisement in the docs, especially in > association with flow bifurcation. > There was also a miss in flow bifurcation howto for Mellanox case. > > Thomas Monjalon (3): > doc: remove useless anchor for flow API guide > doc: add references to flow isolated mode in NICs guide > doc: improve Mellanox bifurcated model description For the series - Acked-by: Shahaf Shuler > > doc/guides/howto/flow_bifurcation.rst | 26 > ++ > doc/guides/howto/rte_flow.rst | 2 +- > doc/guides/linux_gsg/linux_drivers.rst | 7 ++- > doc/guides/nics/mlx4.rst | 2 ++ > doc/guides/nics/mlx5.rst | 2 +- > doc/guides/nics/mvpp2.rst | 5 - > doc/guides/nics/sfc_efx.rst| 2 ++ > doc/guides/prog_guide/rte_flow.rst | 8 > doc/guides/rel_notes/release_17_02.rst | 3 +-- > 9 files changed, 47 insertions(+), 10 deletions(-) > > -- > 2.20.1
Re: [dpdk-dev] [PATCH 1/3] doc: add mlx5 note for Bluefield build configuration
Wednesday, January 30, 2019 9:53 AM, Yongseok Koh:
> Subject: [dpdk-dev] [PATCH 1/3] doc: add mlx5 note for Bluefield build
> configuration
>
> Fixes: d14e4e976f65 ("config: add Mellanox BlueField armv8 SoC")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yongseok Koh
For the series - Acked-by: Shahaf Shuler
> ---
> doc/guides/nics/mlx5.rst | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> 3f168b1613..62de860d0a 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -221,6 +221,13 @@ These options can be modified in the ``.config`` file.
>adds additional run-time checks and debugging messages at the cost of
>lower performance.
>
> +.. note::
> +
> + For Bluefield, target should be set to ``arm64-bluefield-linuxapp-gcc``.
> This
> + will enable ``CONFIG_RTE_LIBRTE_MLX5_PMD`` and set
> ``RTE_CACHE_LINE_SIZE`` to
> + 64. Default armv8a configuration of make build and meson build set it to
> 128
> + then brings performance degradation.
> +
> Environment variables
> ~
>
> --
> 2.11.0
