Re: [dpdk-dev] [PATCH v5 1/2] ethdev: add packet integrity checks
Hello Thomas, Please see my comment on the use of RTE_STD_C11 below. Regards, Gregory. > > > Currently, DPDK application can offload the checksum check, and > > > report it in the mbuf. > > > > > > However, as more and more applications are offloading some or all > > > logic and action to the HW, there is a need to check the packet > > > integrity so the right decision can be taken. > > > > > > The application logic can be positive meaning if the packet is valid > > > jump / do actions, or negative if packet is not valid jump to SW / > > > do actions (like drop) a, and add default flow > > > > There is a typo here. What should it be? > > > Simply remove the a. > > > > (match all in low priority) that will direct the miss packet to the > > > miss path. > > > > > > Since currently rte_flow works in positive way the assumption is > > > that the positive way will be the common way in this case also. > > > > > > When thinking what is the best API to implement such feature, we > > > need to considure the following (in no specific order): > > > > s/considure/consider/ > > > > Will fix. > > > > 1. API breakage. > > > 2. Simplicity. > > > 3. Performance. > > > 4. HW capabilities. > > > 5. rte_flow limitation. > > > 6. Flexibility. > > > > > > First option: Add integrity flags to each of the items. > > > For example add checksum_ok to ipv4 item. > > > > > > Pros: > > > 1. No new rte_flow item. > > > 2. Simple in the way that on each item the app can see what checks > > > are available. > > > > > > Cons: > > > 1. API breakage. > > > 2. increase number of flows, since app can't add global rule and > > >must have dedicated flow for each of the flow combinations, for > example > > >matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will > > >result in 5 flows. > > > > > > Second option: dedicated item > > > > > > Pros: > > > 1. No API breakage, and there will be no for some time due to having > > >extra space. (by using bits) > > > 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / > > >IPv6. > > > 3. Simplicity application can just look at one place to see all possible > > >checks. > > > 4. Allow future support for more tests. > > > > > > Cons: > > > 1. New item, that holds number of fields from different items. > > > > > > For starter the following bits are suggested: > > > 1. packet_ok - means that all HW checks depending on packet layer > have > > >passed. This may mean that in some HW such flow should be splited > to > > >number of flows or fail. > > > 2. l2_ok - all check for layer 2 have passed. > > > 3. l3_ok - all check for layer 3 have passed. If packet doesn't have > > >l3 layer this check should fail. > > > 4. l4_ok - all check for layer 4 have passed. If packet doesn't > > >have l4 layer this check should fail. > > > 5. l2_crc_ok - the layer 2 crc is O.K. > > > 6. ipv4_csum_ok - IPv4 checksum is O.K. it is possible that the > > >IPv4 checksum will be O.K. but the l3_ok will be 0. it is not > > >possible that checksum will be 0 and the l3_ok will be 1. > > > 7. l4_csum_ok - layer 4 checksum is O.K. > > > 8. l3_len_OK - check that the reported layer 3 len is smaller than the > > >frame len. > > > > > > Example of usage: > > > 1. check packets from all possible layers for integrity. > > >flow create integrity spec packet_ok = 1 mask packet_ok = 1 . > > > > > > 2. Check only packet with layer 4 (UDP / TCP) > > >flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 > > > l4_ok = 1 > > > > > > Signed-off-by: Ori Kam > > > --- > > > doc/guides/prog_guide/rte_flow.rst | 20 +++ > > > doc/guides/rel_notes/release_21_05.rst | 5 +++ > > > lib/librte_ethdev/rte_flow.h | 49 > ++ > > > 3 files changed, 74 insertions(+) > > > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > > index e1b93ecedf..1dd2301a07 100644 > > > --- a/doc/guides/prog_guide/rte_flow.rst > > > +++ b/doc/guides/prog_guide/rte_flow.rst > > > @@ -1398,6 +1398,26 @@ Matches a eCPRI header. > > > - ``hdr``: eCPRI header definition (``rte_ecpri.h``). > > > - Default ``mask`` matches nothing, for all eCPRI messages. > > > > > > +Item: ``PACKET_INTEGRITY_CHECKS`` > > > +^ > > > + > > > +Matches packet integrity. > > > +For some devices application needs to enable integration checks in > > > +HW before using this item. > > > + > > > +- ``level``: the encapsulation level that should be checked. level > > > +0 means the > > > + default PMD mode (Can be inner most / outermost). value of 1 > > > +means > > outermost > > > + and higher value means inner header. See also RSS level. > > > +- ``packet_ok``: All HW packet integrity checks have passed based > > > +on the > > max > > > + layer of the packet. > > > +- ``l2_ok``: all layer 2 HW integrity checks passed. > > > +- ``l3_ok``: all layer 3 HW integrity checks passed. > >
Re: [dpdk-dev] [PATCH 00/14] Build file updates
Hi Bruce, > -Original Message- > From: dev On Behalf Of Bruce Richardson > Sent: Saturday, April 17, 2021 1:05 AM > To: dev@dpdk.org > Cc: Bruce Richardson > Subject: [dpdk-dev] [PATCH 00/14] Build file updates > > This RFC contains 5 changes/updates to the DPDK build and build files. > > The changes in this set are: > 1. Use "continue" keyword, new in 0.49 to shorten and reduce indentation > levels >in the foreach loops when building library or driver components. > 2. For libraries, drop support for header-only libraries, which was added just >for the "compat" lib which had a single header, and is now part of EAL. > This >similarly reduces indentation levels and makes the code easier to follow > 3. Since the larger blocks of meson code in our repo is seeing massive >whitespace changes, take the opportunity to switch our indentation style > for >meson files from that of C-files using tabs, to Meson/Python style using >spaces. [More below on this for discussion] > 4. Remove the "librte_" prefix from all our library directories. While as > useful >cleanup, the main driver for this was that it simplifies the matching for > #5 >below. > 5. Add a "disable_libs" build option to allow the user to optionally not build >certain components. Include in this an explicit list of libraries which are >"known safe" to disable in the build. For now this is a short list of three >libs, all of which are safe because they are not buildable on FreeBSD. More >work is needed to expand this list in future. Great feature, very useful for PMD developer who only focus on some specific class driver, most drivers and libs are not relevant, disable them will speed up build process significantly, this always happen when switch release or rebase code. Currently I collected a long disabled driver list for my minimal build, have to update time to time as dpdk community grows quickly. An enable_list might be more efficient here to allow minimal lib/drivers for net, vdpa etc.. plus specific pmd driver for NIC on hand. Alternative way might be Linux ".config" file style which specifies module enable/disable states. Not related this this patch set, off-topic discussion :) Best Regards, Xueming
Re: [dpdk-dev] [PATCH] doc: announce modification in eventdev structure
On Thu, Apr 15, 2021 at 2:39 PM wrote: > > From: Akhil Goyal > > A new field ``ca_enqueue`` is added in ``rte_eventdev`` > in the end to maintain ABI. It needs to be moved above > in the structure to align with other enqueue callbacks. > > Signed-off-by: Akhil Goyal Acked-by: Jerin Jacob > --- > doc/guides/rel_notes/deprecation.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 2afc84c39..a973de4a9 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -127,6 +127,10 @@ Deprecation Notices >values to the function ``rte_event_eth_rx_adapter_queue_add`` using >the structure ``rte_event_eth_rx_adapter_queue_add``. > > +* eventdev: The function pointer ``ca_enqueue`` in structure ``rte_eventdev`` > + will be moved after ``txa_enqueue`` so that all enqueue/dequeue > + function pointers are adjacent to each other. > + > * sched: To allow more traffic classes, flexible mapping of pipe queues to >traffic classes, and subport level configuration of pipes and queues >changes will be made to macros, data structures and API functions defined > -- > 2.25.1 >
Re: [dpdk-dev] Question about enable CBDMA with ioat PMD ?
On Wed, Apr 14, 2021 at 04:33:10PM +0100, Burakov, Anatoly wrote: > On 14-Apr-21 2:45 PM, Liang Ma wrote: > > On Wed, Apr 14, 2021 at 02:21:53PM +0100, Bruce Richardson wrote: > > > On Wed, Apr 14, 2021 at 01:52:14PM +0100, Liang Ma wrote: > > > > On Wed, Apr 14, 2021 at 11:48:03AM +0100, Bruce Richardson wrote: > > > > > On Wed, Apr 14, 2021 at 11:37:48AM +0100, Liang Ma wrote: > > > > > > On Tue, Apr 13, 2021 at 07:24:41PM +0100, Bruce Richardson wrote: > > > > > > > On Tue, Apr 13, 2021 at 06:36:38PM +0100, Liang Ma wrote: > > > > > > > > Hi Bruce, > > > > > > > > I look into current IOAT PMD. I found that looks only > > > > > > > > support the > > > > > > > > latest DSA device which is part of SPR(Please correct me if > > > > > > > > I'm wrong). > > > > > > > > However, there still is lots existing CPU that support > > > > > > > > previous CBDMA > > > > > > > > Intel Quick-DATA technology. SPDK enable those device with > > > > > > > > uio. > > > > > > > > Any hint to enable those CBDMA device with IOAT PMD ? > > > > > > > > > > > > > > Hi Liang, > > > > > > > > > > > > > > These devices are still supported by the driver. In the latest > > > > > > > releases the > > > > > > > new device support was added but no older device support was > > > > > > > removed. > > > > > > > Please let us know if you do hit any problems with running it on > > > > > > > the CBDMA > > > > > > > HW devices, because it should all still be working as before. > > > > > > > > > > > > > > Regards, > > > > > > > /Bruce > > > > > > Hi Bruce, > > > > > > I hit a problem with CBDMA enabling. > > > > > > > > > > > > 1. I follow the DPDK IOAT driver Doc, I bind .04.0 device > > > > > > with > > > > > >dpdk-devbind.py > > > > > > 2. I run dpdk-test without any parameter then dpdk-test > > > > > > complain with > > > > > > > > > > > > EAL: VFIO support initialized > > > > > > EAL: :00:04.0 VFIO group is not viable! Not all devices > > > > > > in IOMMU > > > > > > group bound to VFIO or unbound > > > > > > Requested device :00:04.0 cannot be used > > > > > > > > > > > > 3. kernel boot parameter include the "intel_iommu=on" > > > > > > > > > > > > If I still need some extra iommu settings for CBDMA device ? > > > > > > > > > > > It's an IOMMU limitation, not just for CBDMA but for other devices > > > > > like > > > > > NICs too - you need to ensure all subfunctions on a device are all > > > > > bound to > > > > > the same IOMMU group. So for the CBDMA instance, to use one channel > > > > > with > > > > > vfio, the other channels on the device also need to be bound to vfio, > > > > > or > > > > > else not bound to any driver. If bound to the kernel driver, there > > > > > will be > > > > > IOMMU conflicts as we can't split the channels between kernel and > > > > > userspace > > > > > address spaces. > > > > > > > > > > /Bruce > > > > I bind whole device from 00:04.0 to 00:04.7. ioat PMD complain > > > > with "ioat_rawdev_create(): ioat_rawdev_create: Channel appears > > > > locked". Any hint? > > > > Regards > > > > Liang > > > > > > That should be a warning only, I think and the device should still be > > > available. Is that not the case, or is there a later error? > > > > > > /Bruce > > Good news, that's a warning only message, I checked the code. > > after probe the device, rawdev_autotest all passed ! > > Many thanks for your help ! > > I strongly recommend to add the IOMMU hint of CBDMA(bind whole device) > > into the Doc. I think DSA device don't need to do that right ? > > Best Regards > > Liang > > > > This is documented in our VFIO docs [1]. > > [1] > http://doc.dpdk.org/guides/linux_gsg/linux_drivers.html#binding-and-unbinding-network-ports-to-from-the-kernel-modules Thanks Anatoly.
Re: [dpdk-dev] [PATCH] examples/vhost: fix ioat ring space in callbacks
On Wed, Apr 07, 2021 at 10:43:36AM +0200, Thomas Monjalon wrote: > +Cc more people to start a discussion about a potential DMA API. > If you think it is interesting, we can start a fresh discussion thread. +1 that's ineresting to have a abstract layer of DMA offload engine. I would like join the discussion. please add me in the cc list in the new thread. > 07/04/2021 10:26, Thomas Monjalon: > > 07/04/2021 09:47, Maxime Coquelin: > > > > > > On 3/17/21 6:40 AM, Cheng Jiang wrote: > > > > We use ioat ring space for determining if ioat callbacks can enqueue a > > > > packet to ioat device. But there is one slot can't be used in ioat > > > > ring due to the ioat driver design, so we need to reduce one slot in > > > > ioat ring to prevent ring size mismatch in ioat callbacks. > [...] > > > > --- a/examples/vhost/ioat.c > > > > +++ b/examples/vhost/ioat.c > > > > @@ -113,7 +113,7 @@ open_ioat(const char *value) > > > > goto out; > > > > } > > > > rte_rawdev_start(dev_id); > > > > - cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE; > > > > + cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE - 1; > > > > > > That really comforts me in thinking we need a generic abstraction for > > > DMA devices. How is the application developer supposed to know that > > > the DMA driver has such weird limitations? > > > > Having a generic DMA API may be interesting. > > Do you know any other HW candidate for such an API? > > Do you think rte_memcpy can be used as a SW driver? > > >
[dpdk-dev] [PATCH v6 1/2] ethdev: add packet integrity checks
From: Ori Kam Currently, DPDK application can offload the checksum check, and report it in the mbuf. However, as more and more applications are offloading some or all logic and action to the HW, there is a need to check the packet integrity so the right decision can be taken. The application logic can be positive meaning if the packet is valid jump / do actions, or negative if packet is not valid jump to SW / do actions (like drop) and add default flow (match all in low priority) that will direct the miss packet to the miss path. Since currently rte_flow works in positive way the assumption is that the positive way will be the common way in this case also. When thinking what is the best API to implement such feature, we need to consider the following (in no specific order): 1. API breakage. 2. Simplicity. 3. Performance. 4. HW capabilities. 5. rte_flow limitation. 6. Flexibility. First option: Add integrity flags to each of the items. For example add checksum_ok to ipv4 item. Pros: 1. No new rte_flow item. 2. Simple in the way that on each item the app can see what checks are available. Cons: 1. API breakage. 2. increase number of flows, since app can't add global rule and must have dedicated flow for each of the flow combinations, for example matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will result in 5 flows. Second option: dedicated item Pros: 1. No API breakage, and there will be no for some time due to having extra space. (by using bits) 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / IPv6. 3. Simplicity application can just look at one place to see all possible checks. 4. Allow future support for more tests. Cons: 1. New item, that holds number of fields from different items. For starter the following bits are suggested: 1. packet_ok - means that all HW checks depending on packet layer have passed. This may mean that in some HW such flow should be splited to number of flows or fail. 2. l2_ok - all check for layer 2 have passed. 3. l3_ok - all check for layer 3 have passed. If packet doesn't have l3 layer this check should fail. 4. l4_ok - all check for layer 4 have passed. If packet doesn't have l4 layer this check should fail. 5. l2_crc_ok - the layer 2 crc is O.K. 6. ipv4_csum_ok - IPv4 checksum is O.K. it is possible that the IPv4 checksum will be O.K. but the l3_ok will be 0. it is not possible that checksum will be 0 and the l3_ok will be 1. 7. l4_csum_ok - layer 4 checksum is O.K. 8. l3_len_OK - check that the reported layer 3 len is smaller than the frame len. Example of usage: 1. check packets from all possible layers for integrity. flow create integrity spec packet_ok = 1 mask packet_ok = 1 . 2. Check only packet with layer 4 (UDP / TCP) flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 l4_ok = 1 Signed-off-by: Ori Kam --- doc/guides/prog_guide/rte_flow.rst | 20 +++ doc/guides/rel_notes/release_21_05.rst | 5 +++ lib/librte_ethdev/rte_flow.h | 49 ++ 3 files changed, 74 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index e1b93ecedf..1dd2301a07 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1398,6 +1398,26 @@ Matches a eCPRI header. - ``hdr``: eCPRI header definition (``rte_ecpri.h``). - Default ``mask`` matches nothing, for all eCPRI messages. +Item: ``PACKET_INTEGRITY_CHECKS`` +^ + +Matches packet integrity. +For some devices application needs to enable integration checks in HW +before using this item. + +- ``level``: the encapsulation level that should be checked. level 0 means the + default PMD mode (Can be inner most / outermost). value of 1 means outermost + and higher value means inner header. See also RSS level. +- ``packet_ok``: All HW packet integrity checks have passed based on the max + layer of the packet. +- ``l2_ok``: all layer 2 HW integrity checks passed. +- ``l3_ok``: all layer 3 HW integrity checks passed. +- ``l4_ok``: all layer 4 HW integrity checks passed. +- ``l2_crc_ok``: layer 2 crc check passed. +- ``ipv4_csum_ok``: ipv4 checksum check passed. +- ``l4_csum_ok``: layer 4 checksum check passed. +- ``l3_len_ok``: the layer 3 len is smaller than the frame len. + Actions ~~~ diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 82ee71152f..b1c90f4d9f 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -55,6 +55,11 @@ New Features Also, make sure to start the actual text at the margin. === +* **Added packet integrity match to flow rules.** + + * Added ``RTE_FLOW_ITEM_TYPE_INTEGRITY`` flow item. + * Added ``rte_flow_item_integrity`` data structure. + * **Added support for Marvell CN10K SoC drivers.**
[dpdk-dev] [PATCH v6 0/2] add packet integrity checks
v6: update API comments Ori Kam (2): ethdev: add packet integrity checks app/testpmd: add support for integrity item app/test-pmd/cmdline_flow.c | 39 doc/guides/prog_guide/rte_flow.rst | 20 + doc/guides/rel_notes/release_21_05.rst | 5 +++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 lib/librte_ethdev/rte_flow.h| 49 + 5 files changed, 141 insertions(+) -- 2.25.1
[dpdk-dev] [PATCH v6 2/2] app/testpmd: add support for integrity item
From: Ori Kam
The integrity item allows the application to match
on the integrity of a packet.
use example:
match that packet integrity checks are ok. The checks depend on
packet layers. For example ICMP packet will not check L4 level.
flow create 0 ingress pattern integrity value mask 0x01 value spec 0x01
match that L4 packet is ok - check L2 & L3 & L4 layers:
flow create 0 ingress pattern integrity value mask 0xfe value spec 0xfe
Signed-off-by: Ori Kam
Signed-off-by: Gregory Etelson
---
app/test-pmd/cmdline_flow.c | 39 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++
2 files changed, 67 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0127d9e7d6..a1b0fa4a32 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -293,6 +293,9 @@ enum index {
ITEM_GENEVE_OPT_TYPE,
ITEM_GENEVE_OPT_LENGTH,
ITEM_GENEVE_OPT_DATA,
+ ITEM_INTEGRITY,
+ ITEM_INTEGRITY_LEVEL,
+ ITEM_INTEGRITY_VALUE,
/* Validate/create actions. */
ACTIONS,
@@ -968,6 +971,7 @@ static const enum index next_item[] = {
ITEM_PFCP,
ITEM_ECPRI,
ITEM_GENEVE_OPT,
+ ITEM_INTEGRITY,
END_SET,
ZERO,
};
@@ -1319,6 +1323,19 @@ static const enum index item_geneve_opt[] = {
ZERO,
};
+static const enum index item_integrity[] = {
+ ITEM_INTEGRITY_LEVEL,
+ ITEM_INTEGRITY_VALUE,
+ ZERO,
+};
+
+static const enum index item_integrity_lv[] = {
+ ITEM_INTEGRITY_LEVEL,
+ ITEM_INTEGRITY_VALUE,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3400,6 +3417,28 @@ static const struct token token_list[] = {
(sizeof(struct rte_flow_item_geneve_opt),
ITEM_GENEVE_OPT_DATA_SIZE)),
},
+ [ITEM_INTEGRITY] = {
+ .name = "integrity",
+ .help = "match packet integrity",
+ .priv = PRIV_ITEM(INTEGRITY,
+ sizeof(struct rte_flow_item_integrity)),
+ .next = NEXT(item_integrity),
+ .call = parse_vc,
+ },
+ [ITEM_INTEGRITY_LEVEL] = {
+ .name = "level",
+ .help = "integrity level",
+ .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
+item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity, level)),
+ },
+ [ITEM_INTEGRITY_VALUE] = {
+ .name = "value",
+ .help = "integrity value",
+ .next = NEXT(item_integrity_lv, NEXT_ENTRY(UNSIGNED),
+item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_integrity, value)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index e3bfed566d..feaae9350b 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3791,6 +3791,13 @@ This section lists supported pattern items and their
attributes, if any.
- ``s_field {unsigned}``: S field.
- ``seid {unsigned}``: session endpoint identifier.
+- ``integrity``: match packet integrity.
+
+ - ``level {unsigned}``: Packet encapsulation level the item should
+ apply to. See rte_flow_action_rss for details.
+ - ``value {unsigned}``: A bitmask that specify what packet elements
+ must be matched for integrity.
+
Actions list
@@ -4925,6 +4932,27 @@ NVGRE encapsulation header and sent to port id 0.
testpmd> flow create 0 ingress transfer pattern eth / end actions
sample ratio 1 index 0 / port_id id 2 / end
+Sample integrity rules
+~~
+
+Integrity rules can be created by the following commands:
+
+Integrity rule that forwards valid TCP packets to group 1.
+TCP packet integrity is matched with the ``l4_ok`` bit 3.
+
+::
+
+ testpmd> flow create 0 ingress
+pattern eth / ipv4 / tcp / integrity value mask 8 value spec 8 /
end
+actions jump group 1 / end
+
+Integrity rule that forwards invalid packets to application.
+General packet integrity is matched with the ``packet_ok`` bit 0.
+
+::
+
+ testpmd> flow create 0 ingress pattern integrity value mask 1 value spec 0 /
end actions queue index 0 / end
+
BPF Functions
--
--
2.25.1
[dpdk-dev] [PATCH] eal/windows: fix build warnings in MinGW
the strncasecmp marco defined in rte_os_shim.h is already
defined in MinGW-w64, as a result the compiler prints out
the warning below on function redefinition whenever compiling
a file including the header.
..\lib/librte_eal/windows/include/rte_os_shim.h:21:
warning: "strncasecmp" redefined
#define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
Fixed by defining the marco only to the clang compiler.
Fixes: 45d62067c237 ("eal: make OS shims internal")
Signed-off-by: Tal Shnaiderman
---
lib/librte_eal/windows/include/rte_os_shim.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_eal/windows/include/rte_os_shim.h
b/lib/librte_eal/windows/include/rte_os_shim.h
index f40fb62d1d..db0ea6f1b3 100644
--- a/lib/librte_eal/windows/include/rte_os_shim.h
+++ b/lib/librte_eal/windows/include/rte_os_shim.h
@@ -17,7 +17,9 @@
#define strdup(str) _strdup(str)
#define strtok_r(str, delim, saveptr) strtok_s(str, delim, saveptr)
+#ifndef RTE_TOOLCHAIN_GCC
#define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
+#endif
#define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
#define read(fd, buf, n) _read(fd, buf, n)
--
2.16.1.windows.4
Re: [dpdk-dev] [PATCH v5 5/9] app/testpmd: add clock_gettime_monotonic
> Subject: [dpdk-dev] [PATCH v5 5/9] app/testpmd: add
> clock_gettime_monotonic
>
> External email: Use caution opening links or attachments
>
>
> Add clock_gettime_monotonic for testpmd on Windows
>
> Signed-off-by: Jie Zhou
> Signed-off-by: Jie Zhou
> ---
> app/test-pmd/config.c | 33 -
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> ef0b9784d..a5f8fec5b 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -63,6 +63,12 @@
>
> #define NS_PER_SEC 1E9
>
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +#define _clock_gettime_monotonic(cur_time)
> +clock_gettime_monotonic(&cur_time)
> +#else
> +#define _clock_gettime_monotonic(cur_time)
> clock_gettime(CLOCK_TYPE_ID,
> +&cur_time) #endif
> +
I think this change should be in EAL:
rte_get_time_monotonic(&cur_time)
Windows implementation in windows\eal_timer.c
Unix implementation in unix\eal_unix_timer.c
> static char *flowtype_to_str(uint16_t flow_type);
>
> static const struct {
> @@ -170,6 +176,27 @@ print_ethaddr(const char *name, struct
> rte_ether_addr *eth_addr)
> printf("%s%s", name, buf);
> }
>
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +static int
> +clock_gettime_monotonic(struct timespec *tp) {
> + LARGE_INTEGER pf, pc;
> + LONGLONG nsec;
> +
> + if (QueryPerformanceFrequency(&pf) == 0)
> + return -1;
> +
> + if (QueryPerformanceCounter(&pc) == 0)
> + return -1;
> +
> + nsec = pc.QuadPart * NS_PER_SEC / pf.QuadPart;
> + tp->tv_sec = nsec / NS_PER_SEC;
> + tp->tv_nsec = nsec - tp->tv_sec * NS_PER_SEC;
> +
> + return 0;
> +}
> +#endif
> +
> void
> nic_stats_display(portid_t port_id)
> {
> @@ -186,6 +213,8 @@ nic_stats_display(portid_t port_id)
>
> static const char *nic_stats_border = "";
>
> + int ret;
> +
> if (port_id_is_invalid(port_id, ENABLED_WARN)) {
> print_valid_ports();
> return;
> @@ -202,7 +231,9 @@ nic_stats_display(portid_t port_id)
>"%-"PRIu64"\n", stats.opackets, stats.oerrors, stats.obytes);
>
> diff_ns = 0;
> - if (clock_gettime(CLOCK_TYPE_ID, &cur_time) == 0) {
> +
> + ret = _clock_gettime_monotonic(cur_time);
> + if (ret == 0) {
> uint64_t ns;
>
> ns = cur_time.tv_sec * NS_PER_SEC;
> --
> 2.30.0.vfs.0.2
Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building testpmd on Windows
> Subject: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building testpmd > on Windows > > External email: Use caution opening links or attachments > > > From: Jie Zhou > > - Disable unsupported Apps on Windows > - Enable building of testpmd on Windows > > Signed-off-by: Jie Zhou > Signed-off-by: Jie Zhou > --- > app/meson.build| 4 > app/pdump/meson.build | 6 ++ > app/proc-info/meson.build | 6 ++ > app/test-acl/meson.build | 6 ++ > app/test-bbdev/meson.build | 6 ++ > app/test-cmdline/meson.build | 6 ++ > app/test-compress-perf/meson.build | 6 ++ > app/test-crypto-perf/meson.build | 6 ++ > app/test-eventdev/meson.build | 6 ++ > app/test-fib/meson.build | 6 ++ > app/test-flow-perf/meson.build | 6 ++ > app/test-pipeline/meson.build | 6 ++ > app/test-regex/meson.build | 6 ++ > app/test-sad/meson.build | 6 ++ > app/test/meson.build | 6 ++ > 15 files changed, 84 insertions(+), 4 deletions(-) > Building testpmd results in 2 warnings in clang: ../app/test-pmd/config.c:4254:1: warning: unused function 'print_fdir_mask' [-Wunused-function] print_fdir_mask(struct rte_eth_fdir_masks *mask) ^ ../app/test-pmd/config.c:4289:1: warning: unused function 'print_fdir_flex_payload' [-Wunused-function] print_fdir_flex_payload(struct rte_eth_fdir_flex_conf *flex_conf, uint32_t num) ^ 2 warnings generated.
Re: [dpdk-dev] [PATCH v5 1/2] ethdev: add packet integrity checks
18/04/2021 10:15, Gregory Etelson: > > > > +__extension__ > > > > > > Why extension here? > > > If this is because of the anonymous union, it should be RTE_STD_C11 > > > before the union. > > > Same for the struct. > > > > > O.K > > The RTE_STD_C11 macro fails compilation on > RHEL-7.9 with gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) This macro is used eveywhere in DPDK. What is failing exactly?
Re: [dpdk-dev] [PATCH v6 1/2] ethdev: add packet integrity checks
18/04/2021 17:51, Gregory Etelson:
> +__extension__
That still doesn't make sense, as in v5.
The things which require a macro are anonymous union,
anonymous struct and some bit fields with special sizes.
> +struct rte_flow_item_integrity {
> + /**< Tunnel encapsulation level the item should apply to.
> + * @see rte_flow_action_rss
> + */
> + uint32_t level;
Should have RTE_STD_C11 here.
> + union {
Should have RTE_STD_C11 here.
> + struct {
> + /**< The packet is valid after passing all HW checks. */
> + uint64_t packet_ok:1;
> + /**< L2 layer is valid after passing all HW checks. */
> + uint64_t l2_ok:1;
> + /**< L3 layer is valid after passing all HW checks. */
> + uint64_t l3_ok:1;
> + /**< L4 layer is valid after passing all HW checks. */
> + uint64_t l4_ok:1;
> + /**< L2 layer CRC is valid. */
> + uint64_t l2_crc_ok:1;
> + /**< IPv4 layer checksum is valid. */
> + uint64_t ipv4_csum_ok:1;
> + /**< L4 layer checksum is valid. */
> + uint64_t l4_csum_ok:1;
> + /**< The l3 length is smaller than the frame length. */
> + uint64_t l3_len_ok:1;
> + uint64_t reserved:56;
The reserved space looks useless since it is in an union.
> + };
I'm not sure about the 64-bit bitfields.
Maybe that's why you need __extension__.
I feel 32 bits are enough.
> + uint64_t value;
> + };
> +};
Re: [dpdk-dev] [PATCH] eal/windows: fix build warnings in MinGW
18/04/2021 19:08, Tal Shnaiderman: > the strncasecmp marco defined in rte_os_shim.h is already > defined in MinGW-w64, as a result the compiler prints out > the warning below on function redefinition whenever compiling > a file including the header. > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21: > warning: "strncasecmp" redefined > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count) Why the tests are passing? Are we allowing warnings in build test? > Fixed by defining the marco only to the clang compiler. That's a very common typo: s/marco/macro/
Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building testpmd on Windows
18/04/2021 19:21, Tal Shnaiderman: > Building testpmd results in 2 warnings in clang: > > ../app/test-pmd/config.c:4254:1: warning: unused function 'print_fdir_mask' > [-Wunused-function] > print_fdir_mask(struct rte_eth_fdir_masks *mask) > ^ > ../app/test-pmd/config.c:4289:1: warning: unused function > 'print_fdir_flex_payload' [-Wunused-function] > print_fdir_flex_payload(struct rte_eth_fdir_flex_conf *flex_conf, uint32_t > num) > ^ > 2 warnings generated. Why all tests are passing in the CI? I feel there is something wrong. We must test with -werror.
Re: [dpdk-dev] [PATCH] eal/windows: fix build warnings in MinGW
> Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW > > External email: Use caution opening links or attachments > > > 18/04/2021 19:08, Tal Shnaiderman: > > the strncasecmp marco defined in rte_os_shim.h is already defined in > > MinGW-w64, as a result the compiler prints out the warning below on > > function redefinition whenever compiling a file including the header. > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21: > > warning: "strncasecmp" redefined > > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count) > > Why the tests are passing? Are we allowing warnings in build test? It's a good question, I see CI is passing without warnings, Dmitry can you reproduce it? On my side the collision is with the following file: C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/string.h:119: note: this is the location of the previous definition #define strncasecmp _strnicmp I'm using: -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0 -meson 0.53.2 > > > Fixed by defining the marco only to the clang compiler. > > That's a very common typo: s/marco/macro/ > Thanks, will fix in v2 if this patch is indeed needed. >
Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building testpmd on Windows
> Subject: Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building > testpmd on Windows > > External email: Use caution opening links or attachments > > > 18/04/2021 19:21, Tal Shnaiderman: > > Building testpmd results in 2 warnings in clang: > > > > ../app/test-pmd/config.c:4254:1: warning: unused function > > 'print_fdir_mask' [-Wunused-function] print_fdir_mask(struct > > rte_eth_fdir_masks *mask) ^ > > ../app/test-pmd/config.c:4289:1: warning: unused function > > 'print_fdir_flex_payload' [-Wunused-function] > > print_fdir_flex_payload(struct rte_eth_fdir_flex_conf *flex_conf, > > uint32_t num) ^ > > 2 warnings generated. > > Why all tests are passing in the CI? > I feel there is something wrong. We must test with -werror. I know that the UNH Windows CI runs with -werror however the test didn't run on clang yet [1]. This patch passed Intel compilation test on Windows, however I don't know if -werror is used there [2]. [1] - https://lab.dpdk.org/results/dashboard/patchsets/16593/ [2] - http://mails.dpdk.org/archives/test-report/2021-April/188796.html
Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building testpmd on Windows
> Subject: Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building > testpmd on Windows > > External email: Use caution opening links or attachments > > > > Subject: Re: [dpdk-dev] [PATCH v5 9/9] app/testpmd: enable building > > testpmd on Windows > > > > External email: Use caution opening links or attachments > > > > > > 18/04/2021 19:21, Tal Shnaiderman: > > > Building testpmd results in 2 warnings in clang: > > > > > > ../app/test-pmd/config.c:4254:1: warning: unused function > > > 'print_fdir_mask' [-Wunused-function] print_fdir_mask(struct > > > rte_eth_fdir_masks *mask) ^ > > > ../app/test-pmd/config.c:4289:1: warning: unused function > > > 'print_fdir_flex_payload' [-Wunused-function] > > > print_fdir_flex_payload(struct rte_eth_fdir_flex_conf *flex_conf, > > > uint32_t num) ^ > > > 2 warnings generated. > > > > Why all tests are passing in the CI? > > I feel there is something wrong. We must test with -werror. > > I know that the UNH Windows CI runs with -werror however the test didn't > run on clang yet [1]. > This patch passed Intel compilation test on Windows, however I don't know if > -werror is used there [2]. > > [1] - https://lab.dpdk.org/results/dashboard/patchsets/16593/ > [2] - http://mails.dpdk.org/archives/test-report/2021-April/188796.html Update: the UNH test run a few minutes ago and as expected, failed with the compilation warnings. For some reason however the test appears as 'passed' in patchwork.
Re: [dpdk-dev] [PATCH v6 1/2] ethdev: add packet integrity checks
Hello Thomas,
I modified the following drivers/net/mlx5/mlx5_flow_age.c compilation command
to produce pre-processed source code output:
1 # 1 "../drivers/net/mlx5/mlx5_flow_age.c"
2 # 1 "/.autodirect/mtrswgwork/getelson/src/dpdk/stable/build-dev//"
3 # 1 ""
4 #define __STDC__ 1
** 5 #define __STDC_VERSION__ 201112L
6 #define __STDC_UTF_16__ 1
According to the result, the built-in __STDC_VERSION__ macro was set to 201112L.
Therefore, in rte_common.h, RTE_STD_C11 macro was evaluated as empty value:
Source code:
30 #ifndef typeof
31 #define typeof __typeof__
32 #endif
33
34 #ifndef asm
35 #define asm __asm__
36 #endif
37
38 /** C extension macro for environments lacking C11 features. */
39 #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
40 #define RTE_STD_C11 __extension__
41 #else
42 #define RTE_STD_C11
43 #endif
Preprocessor output:
# 29 "../lib/librte_eal/include/rte_common.h" 2
#define typeof __typeof__
#define asm __asm__
#define RTE_STD_C11
According to these results, RTE_STD_C11 location in code has no significance,
because it will always be replaced with empty string.
After I changed RTE_STD_C11 condition like this:
- #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
+ #if !defined(__STDC_VERSION__) || __STDC_VERSION__ <= 201112L
-__extension__
+RTE_STD_C11
struct rte_flow_item_integrity {
the compilation completed successfully both for 32 and 64 bits value.
Regards,
Gregory.
The compilation command was copied from `ninja --verbose` output:
cc -Idrivers/libtmp_rte_net_mlx5.a.p -Idrivers -I../drivers -Idrivers/net/mlx5
-I../drivers/net/mlx5 \
-Idrivers/net/mlx5/linux -I../drivers/net/mlx5/linux -Ilib/librte_ethdev
-I../lib/librte_ethdev \
-I. -I.. -Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include \
-I../lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
-I../lib/librte_eal/x86/include \
-Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal
-I../lib/librte_eal \
-Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_metrics
-I../lib/librte_metrics \
-Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_net
-I../lib/librte_net \
-Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool
-I../lib/librte_mempool \
-Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter -I../lib/librte_meter
-Idrivers/bus/pci \
-I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/librte_pci
-I../lib/librte_pci \
-Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash -I../lib/librte_hash
\
-Ilib/librte_rcu -I../lib/librte_rcu -Idrivers/common/mlx5
-I../drivers/common/mlx5 \
-Idrivers/common/mlx5/linux -I../drivers/common/mlx5/linux -I/usr//usr/include \
-I/usr/include/libnl3 -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g \
-include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat \
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes \
-Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes \
-Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC \
-march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -std=c11 \
-Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 \
-pedantic -DPEDANTIC -MD -MQ
drivers/libtmp_rte_net_mlx5.a.p/net_mlx5_mlx5_flow_age.c.o \
-MF drivers/libtmp_rte_net_mlx5.a.p/net_mlx5_mlx5_flow_age.c.o.d \
-o drivers/libtmp_rte_net_mlx5.a.p/net_mlx5_mlx5_flow_age.c.o -c
../drivers/net/mlx5/mlx5_flow_age.c
> -Original Message-
> From: Thomas Monjalon
> Sent: Sunday, April 18, 2021 21:12
> To: Gregory Etelson
> Cc: Ori Kam ; ajit.khapa...@broadcom.com;
> andrew.rybche...@oktetlabs.ru; dev@dpdk.org; ferruh.yi...@intel.com;
> jer...@marvell.com; jerinjac...@gmail.com; olivier.m...@6wind.com;
> Slava Ovsiienko ; Gregory Etelson
> ; Matan Azrad ; Raslan
> Darawsheh
> Subject: Re: [PATCH v6 1/2] ethdev: add packet integrity checks
>
> External email: Use caution opening links or attachments
>
>
> 18/04/2021 17:51, Gregory Etelson:
> > +__extension__
>
> That still doesn't make sense, as in v5.
> The things which require a macro are anonymous union, anonymous struct
> and some bit fields with special sizes.
>
> > +struct rte_flow_item_integrity {
> > + /**< Tunnel encapsulation level the item should apply to.
> > + * @see rte_flow_action_rss
> > + */
> > + uint32_t level;
>
> Should have RTE_STD_C11 here.
>
> > + union {
>
> Should have RTE_STD_C11 here.
>
> > + struct {
> > + /**< The packet is valid after passing all HW checks.
> > */
> > + uint64_t packet_ok:1;
> > + /**< L2 layer is valid after passing all HW checks. */
> > + uint64_t l2_ok:1;
> > + /**< L3 layer is valid after passing all HW checks. */
> > + uint64_t l3_ok:1;
> > +
Re: [dpdk-dev] [PATCH v5 00/14] Add ASO meter support in MLX5 PMD
Hi,
> -Original Message-
> From: Li Zhang
> Sent: Thursday, April 15, 2021 6:11 PM
> To: dek...@nvidia.com; Ori Kam ; Slava Ovsiienko
> ; Matan Azrad ; Shahaf
> Shuler
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> ; Raslan Darawsheh ; Roni
> Bar Yanai
> Subject: [PATCH v5 00/14] Add ASO meter support in MLX5 PMD
>
> To support more meters and better performance,
> MLX HW provide ASO flow meter.
> It can expose millions of ASO flow meter context's in HW.
> This ASO object can allocate the large bulk meter objects.
> This patch set implement the ASO flow meter for mlx5 driver.
> MLX5 PMD driver will be responsible for ASO flow meter manage to HW.
>
> V2: Fix compile error issue (mlx5_glue->destroy_flow_action)
> V3: Fix comments.
> V4: Fix comments and add Acked.
> V5: Fix unused log_obj_size issue.
>
> Li Zhang (10):
> net/mlx5: optimize meter statistics
> common/mlx5: add definitions for ASO flow meter
> common/mlx5: add read ASO flow meter HCA capability
> common/mlx5: add DevX API to create ASO flow meter object
> net/mlx5: flow meter pool to manage meter object
> net/mlx5: initialize the flow meter ASO SQ
> net/mlx5: aso flow meter send WQE and CQE handle
> net/mlx5: add support of ASO meter action
> net/mlx5: make ASO meter queue thread-safe
> net/mlx5: allow multiple flow tables on the same level
>
> Shun Hao (3):
> common/mlx5: add color register idle bits definition
> net/mlx5: fix meter statistics
> net/mlx5: use mask for meter register setting
>
> Suanming Mou (1):
> net/mlx5: support three level table walk
>
> doc/guides/nics/mlx5.rst | 6 +
> drivers/common/mlx5/mlx5_devx_cmds.c | 68 ++
> drivers/common/mlx5/mlx5_devx_cmds.h | 26 +-
> drivers/common/mlx5/mlx5_prm.h| 81 +-
> drivers/common/mlx5/version.map | 1 +
> drivers/net/mlx5/linux/mlx5_os.c | 20 +-
> drivers/net/mlx5/meson.build | 2 +-
> drivers/net/mlx5/mlx5.c | 98 +-
> drivers/net/mlx5/mlx5.h | 258 +-
> drivers/net/mlx5/mlx5_flow.c | 334 +--
> drivers/net/mlx5/mlx5_flow.h | 212 ++---
> .../mlx5/{mlx5_flow_age.c => mlx5_flow_aso.c} | 289 +-
> drivers/net/mlx5/mlx5_flow_dv.c | 792 +++-
> drivers/net/mlx5/mlx5_flow_meter.c| 873 --
> drivers/net/mlx5/mlx5_utils.h | 90 ++
> 15 files changed, 2320 insertions(+), 830 deletions(-)
> rename drivers/net/mlx5/{mlx5_flow_age.c => mlx5_flow_aso.c} (65%)
>
> --
> 2.27.0
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH] eal/windows: fix build warnings in MinGW
Hi Tal, 2021-04-18 19:04 (UTC+), Tal Shnaiderman: > > Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW > > > > External email: Use caution opening links or attachments > > > > > > 18/04/2021 19:08, Tal Shnaiderman: > > > the strncasecmp marco defined in rte_os_shim.h is already defined in > > > MinGW-w64, as a result the compiler prints out the warning below on > > > function redefinition whenever compiling a file including the header. > > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21: > > > warning: "strncasecmp" redefined > > > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count) > > > > Why the tests are passing? Are we allowing warnings in build test? > > It's a good question, I see CI is passing without warnings, Dmitry can you > reproduce it? > > On my side the collision is with the following file: > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/string.h:119: note: > this is the location of the previous definition > #define strncasecmp _strnicmp > > I'm using: > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0 > -meson 0.53.2 I can't reproduce it using the same versions. Do you invoke meson with other options than "-Dexamples=..."?
Re: [dpdk-dev] [PATCH v6 1/2] ethdev: add packet integrity checks
Please read again the comment I did below,
and try 32-bit bitfield instead of 64-bit.
18/04/2021 21:24, Gregory Etelson:
> Hello Thomas,
>
> I modified the following drivers/net/mlx5/mlx5_flow_age.c compilation command
> to produce pre-processed source code output:
>
> 1 # 1 "../drivers/net/mlx5/mlx5_flow_age.c"
> 2 # 1 "/.autodirect/mtrswgwork/getelson/src/dpdk/stable/build-dev//"
> 3 # 1 ""
> 4 #define __STDC__ 1
> ** 5 #define __STDC_VERSION__ 201112L
> 6 #define __STDC_UTF_16__ 1
>
> According to the result, the built-in __STDC_VERSION__ macro was set to
> 201112L.
> Therefore, in rte_common.h, RTE_STD_C11 macro was evaluated as empty value:
>
> Source code:
> 30 #ifndef typeof
> 31 #define typeof __typeof__
> 32 #endif
> 33
> 34 #ifndef asm
> 35 #define asm __asm__
> 36 #endif
> 37
> 38 /** C extension macro for environments lacking C11 features. */
> 39 #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> 40 #define RTE_STD_C11 __extension__
> 41 #else
> 42 #define RTE_STD_C11
> 43 #endif
>
> Preprocessor output:
> # 29 "../lib/librte_eal/include/rte_common.h" 2
> #define typeof __typeof__
> #define asm __asm__
> #define RTE_STD_C11
>
> According to these results, RTE_STD_C11 location in code has no significance,
> because it will always be replaced with empty string.
> After I changed RTE_STD_C11 condition like this:
>
> - #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> + #if !defined(__STDC_VERSION__) || __STDC_VERSION__ <= 201112L
>
> -__extension__
> +RTE_STD_C11
> struct rte_flow_item_integrity {
>
> the compilation completed successfully both for 32 and 64 bits value.
>
> Regards,
> Gregory.
>
> The compilation command was copied from `ninja --verbose` output:
> cc -Idrivers/libtmp_rte_net_mlx5.a.p -Idrivers -I../drivers
> -Idrivers/net/mlx5 -I../drivers/net/mlx5 \
> -Idrivers/net/mlx5/linux -I../drivers/net/mlx5/linux -Ilib/librte_ethdev
> -I../lib/librte_ethdev \
> -I. -I.. -Iconfig -I../config -Ilib/librte_eal/include
> -I../lib/librte_eal/include -Ilib/librte_eal/linux/include \
> -I../lib/librte_eal/linux/include -Ilib/librte_eal/x86/include
> -I../lib/librte_eal/x86/include \
> -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal
> -I../lib/librte_eal \
> -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_metrics
> -I../lib/librte_metrics \
> -Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_net
> -I../lib/librte_net \
> -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool
> -I../lib/librte_mempool \
> -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter
> -I../lib/librte_meter -Idrivers/bus/pci \
> -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/librte_pci
> -I../lib/librte_pci \
> -Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash
> -I../lib/librte_hash \
> -Ilib/librte_rcu -I../lib/librte_rcu -Idrivers/common/mlx5
> -I../drivers/common/mlx5 \
> -Idrivers/common/mlx5/linux -I../drivers/common/mlx5/linux
> -I/usr//usr/include \
> -I/usr/include/libnl3 -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g \
> -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat \
> -Wformat-nonliteral -Wformat-security -Wmissing-declarations
> -Wmissing-prototypes \
> -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes \
> -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC \
> -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -std=c11 \
> -Wno-strict-prototypes -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 \
> -pedantic -DPEDANTIC -MD -MQ
> drivers/libtmp_rte_net_mlx5.a.p/net_mlx5_mlx5_flow_age.c.o \
> -MF drivers/libtmp_rte_net_mlx5.a.p/net_mlx5_mlx5_flow_age.c.o.d \
> -o drivers/libtmp_rte_net_mlx5.a.p/net_mlx5_mlx5_flow_age.c.o -c
> ../drivers/net/mlx5/mlx5_flow_age.c
>
> > -Original Message-
> > From: Thomas Monjalon
> > Sent: Sunday, April 18, 2021 21:12
> > To: Gregory Etelson
> > Cc: Ori Kam ; ajit.khapa...@broadcom.com;
> > andrew.rybche...@oktetlabs.ru; dev@dpdk.org; ferruh.yi...@intel.com;
> > jer...@marvell.com; jerinjac...@gmail.com; olivier.m...@6wind.com;
> > Slava Ovsiienko ; Gregory Etelson
> > ; Matan Azrad ; Raslan
> > Darawsheh
> > Subject: Re: [PATCH v6 1/2] ethdev: add packet integrity checks
> >
> > External email: Use caution opening links or attachments
> >
> >
> > 18/04/2021 17:51, Gregory Etelson:
> > > +__extension__
> >
> > That still doesn't make sense, as in v5.
> > The things which require a macro are anonymous union, anonymous struct
> > and some bit fields with special sizes.
> >
> > > +struct rte_flow_item_integrity {
> > > + /**< Tunnel encapsulation level the item should apply to.
> > > + * @see rte_flow_action_rss
> > > + */
> > > + uint32_t level;
> >
> > Should have RTE_STD_C11 here.
> >
> > > + union {
> >
> > Should have RTE_STD_C11 here.
> >
> > > + struct {
> > > +
Re: [dpdk-dev] [pull-request] next-eventdev 21.05-rc1
17/04/2021 19:28, Jerin Jacob Kollanukkaran: > http://dpdk.org/git/next/dpdk-next-eventdev Pulled, thanks
Re: [dpdk-dev] [PATCH 00/14] Build file updates
16/04/2021 19:04, Bruce Richardson: > RFC -> V1: > * rebased to current main branch > * performed cleanup on many meson.build files to ensure correct formatting of > lists: >* split lists with >3 or >4 entries to be one per line >* first entry on own line >* last entry on own line with "," >* closing braces dedented to original indent level >* alphabetical ordering > Files in "lib" folder should be mostly ok now - files in the drivers > directory have not been done to the same level, as there are so many of > them to work on. > * other general whitespace changes, including merging lines where possible, > since indent levels are reduced There were 2 more suggestions in the RFC: - ignore-rev file to avoid polluting git blame - devtools script to convert patches for backport For me they are must-have before merging.
Re: [dpdk-dev] [PATCH v6] ethdev: add sanity checks in control APIs
在 2021/4/18 5:37, Thomas Monjalon 写道:
17/04/2021 02:28, Min Hu (Connor):
在 2021/4/17 0:28, Stephen Hemminger 写道:
On Fri, 16 Apr 2021 11:22:02 +0100
Kevin Traynor wrote:
+ if (dev_conf == NULL) {
+ RTE_ETHDEV_LOG(ERR,
+ "Cannot configure ethdev port %u to NULL dev_conf\n",
The others use a natural sounding names instead of argument name. If you
wanted to match that it could be "..to NULL conf"
I would prefer that error messages don't try to be English sentences.
The wording ends up awkward. and overly wordy.
If function name is automatically included by RTE_ETHDEV_LOG() then
Just:
RTE_ETHDEV_LOG(ERR, "NULL ethdev")
should be enough for programmer to find/fix the problem
.
Hi, Stephen,
Your opinion is quit different from that of Andrew Rybchenko.
Andrew does not support show function name in the log:
"- log messages should be human readable (i.e. I'd avoid
usage of function name)"
@Andrew ,@Thoms, @Ferruh, @Kevin, so, what's your opinion ?
I prefer human readable messages which are unique enough to be "grepped".
Agree with Thomas, thanks.
.
[dpdk-dev] [PATCH v11] app/testpmd: support multi-process
This patch adds multi-process support for testpmd.
The test cmd example as follows:
the primary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=0
the secondary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=1
Signed-off-by: Min Hu (Connor)
Signed-off-by: Lijun Ou
Acked-by: Xiaoyun Li
Acked-by: Ajit Khaparde
Reviewed-by: Ferruh Yigit
---
v11:
* Fixed some minor syntax.
v10:
* Hid process type checks behind new functions.
* Added comments.
v9:
* Updated release notes and rst doc.
* Deleted deprecated codes.
* move macro and variable.
v8:
* Added warning info about queue numbers and process numbers.
v7:
* Fixed compiling error for unexpected unindent.
v6:
* Add rte flow description for multiple process.
v5:
* Fixed run_app.rst for multiple process description.
* Fix compiling error.
v4:
* Fixed minimum vlaue of Rxq or Txq in doc.
v3:
* Fixed compiling error using gcc10.0.
v2:
* Added document for this patch.
---
app/test-pmd/cmdline.c | 6 ++
app/test-pmd/config.c | 21 +-
app/test-pmd/parameters.c | 11 +++
app/test-pmd/testpmd.c | 129 ++---
app/test-pmd/testpmd.h | 9 +++
doc/guides/rel_notes/release_21_05.rst | 1 +
doc/guides/testpmd_app_ug/run_app.rst | 86 ++
7 files changed, 236 insertions(+), 27 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5bf1497..e465824 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -5354,6 +5354,12 @@ cmd_set_flush_rx_parsed(void *parsed_result,
__rte_unused void *data)
{
struct cmd_set_flush_rx *res = parsed_result;
+
+ if (num_procs > 1 && (strcmp(res->mode, "on") == 0)) {
+ printf("multi-process doesn't support to flush rx queues.\n");
+ return;
+ }
+
no_flush_rx = (uint8_t)((strcmp(res->mode, "on") == 0) ? 0 : 1);
}
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index d4b0e85..5d91335 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2859,6 +2859,8 @@ rss_fwd_config_setup(void)
queueid_t rxq;
queueid_t nb_q;
streamid_t sm_id;
+ int start;
+ int end;
nb_q = nb_rxq;
if (nb_q > nb_txq)
@@ -2876,7 +2878,22 @@ rss_fwd_config_setup(void)
init_fwd_streams();
setup_fwd_config_of_each_lcore(&cur_fwd_config);
- rxp = 0; rxq = 0;
+
+ if (proc_id > 0 && nb_q % num_procs)
+ printf("Warning! queue numbers should be multiple of "
+ "processes, or packet loss will happen.\n");
+
+ /**
+* In multi-process, All queues are allocated to different
+* processes based on num_procs and proc_id. For example:
+* if supports 4 queues(nb_q), 2 processes(num_procs),
+* the 0~1 queue for primary process.
+* the 2~3 queue for secondary process.
+*/
+ start = proc_id * nb_q / num_procs;
+ end = start + nb_q / num_procs;
+ rxp = 0;
+ rxq = start;
for (sm_id = 0; sm_id < cur_fwd_config.nb_fwd_streams; sm_id++) {
struct fwd_stream *fs;
@@ -2893,6 +2910,8 @@ rss_fwd_config_setup(void)
continue;
rxp = 0;
rxq++;
+ if (rxq >= end)
+ rxq = start;
}
}
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index f3954c1..ece05c1 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -508,6 +508,9 @@ parse_link_speed(int n)
void
launch_args_parse(int argc, char** argv)
{
+#define PARAM_PROC_ID "proc-id"
+#define PARAM_NUM_PROCS "num-procs"
+
int n, opt;
char **argvopt;
int opt_idx;
@@ -625,6 +628,8 @@ launch_args_parse(int argc, char** argv)
{ "rx-mq-mode", 1, 0, 0 },
{ "record-core-cycles", 0, 0, 0 },
{ "record-burst-stats", 0, 0, 0 },
+ { PARAM_NUM_PROCS, 1, 0, 0 },
+ { PARAM_PROC_ID,1, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1391,6 +1396,12 @@ launch_args_parse(int argc, char** argv)
record_core_cycles = 1;
if (!strcmp(lgopts[opt_idx].name, "record-burst-stats"))
record_burst_stats = 1;
+ if (strncmp(lgopts[opt_idx].name,
+ PARAM_NUM_PROCS, 9) == 0)
+ num_procs = atoi(optarg);
+ if (strncmp(lgopts[opt_idx].name,
+ PARAM_PROC_ID, 7) == 0)
+ proc_id = atoi(optarg);
break;
case
Re: [dpdk-dev] [PATCH v10] app/testpmd: support multi-process
Thanks Ferruh, fixed in v11, thanks.
在 2021/4/18 6:21, Ferruh Yigit 写道:
On 4/17/2021 7:12 AM, Min Hu (Connor) wrote:
This patch adds multi-process support for testpmd.
The test cmd example as follows:
the primary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=0
the secondary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=1
Signed-off-by: Min Hu (Connor)
Signed-off-by: Lijun Ou
Acked-by: Xiaoyun Li
Acked-by: Ajit Khaparde
Hi Connor,
I put some minor syntax comments, when they are fixed,
Reviewed-by: Ferruh Yigit
<...>
if (diag != 0) {
- if (rte_atomic16_cmpset(&(port->port_status),
- RTE_PORT_HANDLING, RTE_PORT_STOPPED) == 0)
- printf("Port %d can not be set back "
- "to stopped\n", pi);
- printf("Fail to configure port %d\n", pi);
+ if (rte_atomic16_cmpset(
+ &(port->port_status),
+ RTE_PORT_HANDLING,
+ RTE_PORT_STOPPED) == 0)
+ printf("Port %d can not be set "
+ "back to stopped\n", pi);
It is OK to have long line for the strings, so it can be like
printf("Port %d can not be set back to stopped\n",
pi);
+ printf("Fail to configure port %d\n",
+ pi);
No need to update this line.
<...>
/* Fail to setup rx queue, return */
if (rte_atomic16_cmpset(&(port->port_status),
- RTE_PORT_HANDLING, RTE_PORT_STOPPED) == 0)
+ RTE_PORT_HANDLING, RTE_PORT_STOPPED) == 0)
printf("Port %d can not be set back to "
- "stopped\n", pi);
+ "stopped\n",
+ pi);
These are syntax changes, I think can keep these lines as it is.
.
Re: [dpdk-dev] [PATCH V5] ethdev: add queue state when retrieve queue information
在 2021/4/18 6:00, Ferruh Yigit 写道: On 4/17/2021 4:09 AM, Lijun Ou wrote: Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API. Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible. Signed-off-by: Chengwen Feng Signed-off-by: Lijun Ou Acked-by: Konstantin Ananyev --- V4->V5: - Add acked-by - add a note to the "New features" section to annouce the new feature. V3->V4: - update libabigail.abignore for removing the CI warnings V2->V3: - rewrite the commit log and delete the part Note - rewrite tht comments for queue state - move the queue_state definition locations V1->V2: - move queue state defines to public file --- doc/guides/rel_notes/release_21_05.rst | 6 ++ lib/librte_ethdev/ethdev_driver.h | 7 --- lib/librte_ethdev/rte_ethdev.c | 3 +++ lib/librte_ethdev/rte_ethdev.h | 9 + 4 files changed, 18 insertions(+), 7 deletions(-) missing 'libabigail.abignore' that was in v4? . Yes. the CI is warning after I send the V3 with fix some comments. Then I update liabigail.bignore, taking into account your comments with thomas and send the V4.
[dpdk-dev] [PATCH V6] ethdev: add queue state when retrieve queue information
Currently, upper-layer application could get queue state only
through pointers such as dev->data->tx_queue_state[queue_id],
this is not the recommended way to access it. So this patch
add get queue state when call rte_eth_rx_queue_info_get and
rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size
remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so
it could be ABI compatible.
Signed-off-by: Chengwen Feng
Signed-off-by: Lijun Ou
Acked-by: Konstantin Ananyev
---
V5->V6:
- add updated update libabigail.abignore
V4->V5:
- add acked-by
- add a note to the "New features" section to annouce the new feature.
V3->V4:
- update libabigail.abignore for removing the CI warnings
V2->V3:
- rewrite the commit log and delete the part Note
- rewrite tht comments for queue state
- move the queue_state definition locations
V1->V2:
- move queue state defines to public file
---
devtools/libabigail.abignore | 12 +++-
doc/guides/rel_notes/release_21_05.rst | 6 ++
lib/librte_ethdev/ethdev_driver.h | 7 ---
lib/librte_ethdev/rte_ethdev.c | 3 +++
lib/librte_ethdev/rte_ethdev.h | 9 +
5 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 6c0b389..d8082cf 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -19,4 +19,14 @@
; Ignore fields inserted in cacheline boundary of rte_cryptodev
[suppress_type]
name = rte_cryptodev
-has_data_member_inserted_between = {offset_after(attached), end}
\ No newline at end of file
+has_data_member_inserted_between = {offset_after(attached), end}
+
+; Ignore fields inserted in alignment hole of rte_eth_rxq_info
+[suppress_type]
+ name = rte_eth_rxq_info
+ has_data_member_inserted_at = offset_after(scattered_rx)
+
+; Ignore fields inserted in cacheline boundary of rte_eth_txq_info
+[suppress_type]
+ name = rte_eth_txq_info
+ has_data_member_inserted_between = {offset_after(nb_desc), end}
diff --git a/doc/guides/rel_notes/release_21_05.rst
b/doc/guides/rel_notes/release_21_05.rst
index 58272e1..1ab3681 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -81,6 +81,12 @@ New Features
representor=[[c#]pf#]sf# sf[0,2-1023] /* 1023 SFs. */
representor=[c#]pf# c2pf[0,1]/* 2 PFs on controller 2.*/
+* **Enhanced function for getting rxq/txq info ABI.**
+ * Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure to
+provide indicated rxq queue state.
+ * Added new field ``queue_state`` to ``rte_eth_txq_info`` structure to
+provide indicated txq queue state.
+
* **Added support for meter PPS profile.**
Currently meter algorithms only supports bytes per second(BPS).
diff --git a/lib/librte_ethdev/ethdev_driver.h
b/lib/librte_ethdev/ethdev_driver.h
index 113129d..40e474a 100644
--- a/lib/librte_ethdev/ethdev_driver.h
+++ b/lib/librte_ethdev/ethdev_driver.h
@@ -952,13 +952,6 @@ struct eth_dev_ops {
};
/**
- * RX/TX queue states
- */
-#define RTE_ETH_QUEUE_STATE_STOPPED 0
-#define RTE_ETH_QUEUE_STATE_STARTED 1
-#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
-
-/**
* @internal
* Check if the selected Rx queue is hairpin queue.
*
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index c73d263..d5adf4f 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -5038,6 +5038,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t
queue_id,
memset(qinfo, 0, sizeof(*qinfo));
dev->dev_ops->rxq_info_get(dev, queue_id, qinfo);
+ qinfo->queue_state = dev->data->rx_queue_state[queue_id];
+
return 0;
}
@@ -5078,6 +5080,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t
queue_id,
memset(qinfo, 0, sizeof(*qinfo));
dev->dev_ops->txq_info_get(dev, queue_id, qinfo);
+ qinfo->queue_state = dev->data->tx_queue_state[queue_id];
return 0;
}
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 3b773b6..a0d01d2 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1588,6 +1588,13 @@ struct rte_eth_dev_info {
};
/**
+ * RX/TX queue states
+ */
+#define RTE_ETH_QUEUE_STATE_STOPPED 0
+#define RTE_ETH_QUEUE_STATE_STARTED 1
+#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
+
+/**
* Ethernet device RX queue information structure.
* Used to retrieve information about configured queue.
*/
@@ -1595,6 +1602,7 @@ struct rte_eth_rxq_info {
struct rte_mempool *mp; /**< mempool used by that queue. */
struct rte_eth_rxconf conf; /**< queue config parameters. */
uint8_t scattered_rx; /**< scattered packets RX supported. */
+ uint8_t queue_state;/**< one of RTE_ETH_QUEUE_STATE_*. */
uint16_t nb_desc;
Re: [dpdk-dev] [PATCH V5] ethdev: add queue state when retrieve queue information
在 2021/4/18 6:00, Ferruh Yigit 写道: On 4/17/2021 4:09 AM, Lijun Ou wrote: Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API. Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible. Signed-off-by: Chengwen Feng Signed-off-by: Lijun Ou Acked-by: Konstantin Ananyev --- V4->V5: - Add acked-by - add a note to the "New features" section to annouce the new feature. V3->V4: - update libabigail.abignore for removing the CI warnings V2->V3: - rewrite the commit log and delete the part Note - rewrite tht comments for queue state - move the queue_state definition locations V1->V2: - move queue state defines to public file --- doc/guides/rel_notes/release_21_05.rst | 6 ++ lib/librte_ethdev/ethdev_driver.h | 7 --- lib/librte_ethdev/rte_ethdev.c | 3 +++ lib/librte_ethdev/rte_ethdev.h | 9 + 4 files changed, 18 insertions(+), 7 deletions(-) missing 'libabigail.abignore' that was in v4? . Sorry. thanks. I have sent the new version for V6.
Re: [dpdk-dev] [PATCH v6] net/iavf: deprecate i40evf pmd
> -Original Message- > From: Zhang, RobinX > Sent: Friday, April 16, 2021 9:58 AM > To: dev@dpdk.org > Cc: Xing, Beilei ; Guo, Jia ; Wang, > Haiyue ; m...@ashroe.eu; nhor...@tuxdriver.com; > Wu, Jingjing ; Yang, Qiming > ; Yang, SteveX ; Zhang, > RobinX > Subject: [PATCH v6] net/iavf: deprecate i40evf pmd > > The i40evf PMD will be deprecated, iavf will be the only VF driver for Intel > 700 > serial (i40e) NIC family. To reach this, there will be 2 steps: > > Step 1: iavf will be the default VF driver, while i40evf still can be > selected by > devarg: "driver=i40evf". > This is covered by this patch, which include: > 1) add all 700 serial NIC VF device ID into iavf PMD > 2) skip probe if devargs contain "driver=i40evf" in iavf > 3) continue probe if devargs contain "driver=i40evf" in i40evf > > Step 2: i40evf and related devarg are removed, this will happen at DPDK > 21.11 > > Between step 1 and step 2, no new feature will be added into i40evf except > bug fix. > > Signed-off-by: Robin Zhang > --- > v6: > - remove unnecessary ifdef in iavf. > > v5: > - refine code of check device id. > > v4: > - rebase code. > > v3: > - skip probe if devargs contain "driver=i40evf" in iavf. > - update intel_vf.rst for the new devargs. > > v2: > - change default VF driver to iavf, add devarg "driver=i40evf" so that > i40evf can still be used. > --- > doc/guides/nics/intel_vf.rst | 6 +++ > doc/guides/rel_notes/deprecation.rst | 8 > drivers/common/iavf/iavf_devids.h| 2 + > drivers/net/i40e/i40e_ethdev_vf.c| 45 ++ > drivers/net/iavf/iavf_ethdev.c | 57 +++- > 5 files changed, 116 insertions(+), 2 deletions(-) > > diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst index > 529ff4a955..fcea8151bf 100644 > --- a/doc/guides/nics/intel_vf.rst > +++ b/doc/guides/nics/intel_vf.rst > @@ -88,6 +88,12 @@ For more detail on SR-IOV, please refer to the following > documents: > assignment in hypervisor. Take qemu for example, the device assignment > should carry the IAVF device id (0x1889) like > ``-device vfio-pci,x-pci-device-id=0x1889,host=03:0a.0``. > > +Starting from DPDK 21.05, the default VF driver for Intel® 700 Series > Ethernet Controller will be IAVF. No new feature > +will be added into i40evf except bug fix until it's removed in DPDK > 21.11. > Between DPDK 21.05 and 21.11, by using the > +``devargs`` option ``driver=i40evf``, i40evf PMD still can be used on > Intel® > 700 Series Ethernet Controller, for example:: > + > +-a 81:02.0,driver=i40evf > + > When IAVF is backed by an Intel® E810 device, the "Protocol Extraction" > feature which is supported by ice PMD is also > available for IAVF PMD. The same devargs with the same parameters can be > applied to IAVF PMD, for detail please reference > the section ``Protocol extraction for per queue`` of ice.rst. > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 2afc84c396..05ef276b21 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -139,3 +139,11 @@ Deprecation Notices > * cmdline: ``cmdline`` structure will be made opaque to hide > platform-specific >content. On Linux and FreeBSD, supported prior to DPDK 20.11, >original structure will be kept until DPDK 21.11. > + > +* i40e: As there are both i40evf and iavf pmd, the functions of them > +are > + duplicated. And now more and more advanced features are developed on > iavf. > + To keep consistent with kernel driver's name > + (https://patchwork.ozlabs.org/patch/970154/), i40evf is no need to > maintain. > + Starting from 21.05, the default VF driver of i40e will be iavf, but > +i40evf > + can still be used if users specify the devarg "driver=i40evf". I40evf > +will > + be deleted in DPDK 21.11. > diff --git a/drivers/common/iavf/iavf_devids.h > b/drivers/common/iavf/iavf_devids.h > index 722c2e4f49..b0d48b0582 100644 > --- a/drivers/common/iavf/iavf_devids.h > +++ b/drivers/common/iavf/iavf_devids.h > @@ -13,5 +13,7 @@ > #define IAVF_DEV_ID_VF_HV0x1571 > #define IAVF_DEV_ID_ADAPTIVE_VF 0x1889 > #define IAVF_DEV_ID_X722_VF 0x37CD > +#define I40E_DEV_ID_X722_A0_VF 0x374D Why not IAVF_DEV_ID_X722_A0_VF here?
Re: [dpdk-dev] [PATCH] app/testpmd: add link autoneg status display
Hi
> -Original Message-
> From: Min Hu (Connor)
> Sent: Thursday, April 15, 2021 14:45
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Li, Xiaoyun
> Subject: [PATCH] app/testpmd: add link autoneg status display
>
> From: Huisong Li
>
> This patch adds link autoneg status display in port_infos_display().
>
> Signed-off-by: Huisong Li
> Signed-off-by: Min Hu (Connor)
> ---
> app/test-pmd/config.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> 40b2b29..0dd6a6f 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -619,6 +619,8 @@ port_infos_display(portid_t port_id)
> printf("Link speed: %s\n", rte_eth_link_speed_to_str(link.link_speed));
> printf("Link duplex: %s\n", (link.link_duplex ==
> ETH_LINK_FULL_DUPLEX) ?
> ("full-duplex") : ("half-duplex"));
> + printf("Autoneg status: %s\n", (link.link_autoneg ==
> ETH_LINK_AUTONEG) ?
> +("On") : ("Off"));
>
> if (!rte_eth_dev_get_mtu(port_id, &mtu))
> printf("MTU: %u\n", mtu);
> --
> 2.7.4
Acked-by: Xiaoyun Li
Re: [dpdk-dev] [PATCH] app/testpmd: support the query of link flow ctrl info
Hi
> -Original Message-
> From: Min Hu (Connor)
> Sent: Thursday, April 15, 2021 14:47
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Li, Xiaoyun
> Subject: [PATCH] app/testpmd: support the query of link flow ctrl info
>
> From: Huisong Li
>
> This patch supports the query of the link flow control parameter on a port.
>
> The command format is as follows:
> show port flow_ctrl
>
> Signed-off-by: Huisong Li
> Signed-off-by: Min Hu (Connor)
> ---
> app/test-pmd/cmdline.c | 83
> +
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
> 2 files changed, 90 insertions(+)
>
> + printf("\n%s Flow control infos for port %-2d %s\n",
> + info_border, res->port_id, info_border);
> + printf("FC mode:\n");
> + printf(" Rx: %s\n", rx_fc_en ? "On" : "Off");
> + printf(" Tx: %s\n", tx_fc_en ? "On" : "Off");
> + printf("FC autoneg status: %s\n", fc_conf.autoneg != 0 ? "On" : "Off");
"fc_conf.autoneg ? "On" : "Off"" is enough like the others in this patch.
> + printf("pause_time: 0x%x\n", fc_conf.pause_time);
> + printf("high_water: 0x%x\n", fc_conf.high_water);
> + printf("low_water: 0x%x\n", fc_conf.low_water);
> + printf("Send Xon: %s\n", fc_conf.send_xon ? "On" : "Off");
> + printf("mac ctrl frame fwd: %s\n",
Follow others' format will be better like "Send Xon".
"Forward MAC control frames:"
> + fc_conf.mac_ctrl_frame_fwd ? "On" : "Off");
> + printf("\n%s** End ***%s\n",
> + info_border, info_border);
> +}
> +
>
> --
> 2.7.4
Re: [dpdk-dev] [PATCH V3] app/testpmd: support Tx mbuf free on demand cmd
Hi > -Original Message- > From: Lijun Ou > Sent: Monday, April 12, 2021 21:13 > To: Yigit, Ferruh > Cc: Li, Xiaoyun ; dev@dpdk.org; > linux...@openeuler.org > Subject: [PATCH V3] app/testpmd: support Tx mbuf free on demand cmd > > From: Chengwen Feng > > This patch support tx_done_cleanup command: > tx_done_cleanup port (port_id) (queue_id) (free_cnt) > > Users must make sure there are no concurrent access to the same Tx queue (like > rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on) this command > executed. > > Signed-off-by: Chengwen Feng > Signed-off-by: Lijun Ou As I remember, last comments (from Ferruh and Aaron) suggest you to do this in an unit test not testpmd. > --- > V2->V3: > - The command implementation is changed so that the queuestate does > not depend on the command execution. > > V1->V2: > - use Tx instead of TX > - add note in doc > --- > app/test-pmd/cmdline.c | 85 > + > doc/guides/rel_notes/release_21_05.rst | 2 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 > 3 files changed, 98 insertions(+) > + > show config > ~~~ > > -- > 2.7.4
[dpdk-dev] [PATCH v7] net/iavf: deprecate i40evf pmd
The i40evf PMD will be deprecated, iavf will be the only VF driver for
Intel 700 serial (i40e) NIC family. To reach this, there will be 2 steps:
Step 1: iavf will be the default VF driver, while i40evf still can be
selected by devarg: "driver=i40evf".
This is covered by this patch, which include:
1) add all 700 serial NIC VF device ID into iavf PMD
2) skip probe if devargs contain "driver=i40evf" in iavf
3) continue probe if devargs contain "driver=i40evf" in i40evf
Step 2: i40evf and related devarg are removed, this will happen at DPDK
21.11
Between step 1 and step 2, no new feature will be added into i40evf except
bug fix.
Signed-off-by: Robin Zhang
Acked-by: Qi Zhang
Acked-by: Ferruh Yigit
---
v7:
- correct the device id macro name of X722_A0_VF.
v6:
- remove unnecessary ifdef in iavf.
v5:
- refine code of check device id.
v4:
- rebase code.
v3:
- skip probe if devargs contain "driver=i40evf" in iavf.
- update intel_vf.rst for the new devargs.
v2:
- change default VF driver to iavf, add devarg "driver=i40evf" so that
i40evf can still be used.
---
doc/guides/nics/intel_vf.rst | 6 +++
doc/guides/rel_notes/deprecation.rst | 8
drivers/common/iavf/iavf_devids.h| 2 +
drivers/net/i40e/i40e_ethdev_vf.c| 45 ++
drivers/net/iavf/iavf_ethdev.c | 57 +++-
5 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
index 529ff4a955..fcea8151bf 100644
--- a/doc/guides/nics/intel_vf.rst
+++ b/doc/guides/nics/intel_vf.rst
@@ -88,6 +88,12 @@ For more detail on SR-IOV, please refer to the following
documents:
assignment in hypervisor. Take qemu for example, the device assignment
should carry the IAVF device id (0x1889) like
``-device vfio-pci,x-pci-device-id=0x1889,host=03:0a.0``.
+Starting from DPDK 21.05, the default VF driver for Intel® 700 Series
Ethernet Controller will be IAVF. No new feature
+will be added into i40evf except bug fix until it's removed in DPDK 21.11.
Between DPDK 21.05 and 21.11, by using the
+``devargs`` option ``driver=i40evf``, i40evf PMD still can be used on
Intel® 700 Series Ethernet Controller, for example::
+
+-a 81:02.0,driver=i40evf
+
When IAVF is backed by an Intel® E810 device, the "Protocol Extraction"
feature which is supported by ice PMD is also
available for IAVF PMD. The same devargs with the same parameters can be
applied to IAVF PMD, for detail please reference
the section ``Protocol extraction for per queue`` of ice.rst.
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 2afc84c396..05ef276b21 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -139,3 +139,11 @@ Deprecation Notices
* cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
content. On Linux and FreeBSD, supported prior to DPDK 20.11,
original structure will be kept until DPDK 21.11.
+
+* i40e: As there are both i40evf and iavf pmd, the functions of them are
+ duplicated. And now more and more advanced features are developed on iavf.
+ To keep consistent with kernel driver's name
+ (https://patchwork.ozlabs.org/patch/970154/), i40evf is no need to maintain.
+ Starting from 21.05, the default VF driver of i40e will be iavf, but i40evf
+ can still be used if users specify the devarg "driver=i40evf". I40evf will
+ be deleted in DPDK 21.11.
diff --git a/drivers/common/iavf/iavf_devids.h
b/drivers/common/iavf/iavf_devids.h
index 722c2e4f49..0f98375a09 100644
--- a/drivers/common/iavf/iavf_devids.h
+++ b/drivers/common/iavf/iavf_devids.h
@@ -13,5 +13,7 @@
#define IAVF_DEV_ID_VF_HV 0x1571
#define IAVF_DEV_ID_ADAPTIVE_VF0x1889
#define IAVF_DEV_ID_X722_VF0x37CD
+#define IAVF_DEV_ID_X722_A0_VF 0x374D
+
#endif /* _IAVF_DEVIDS_H_ */
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 0c9bd8d2c6..509c8f4e37 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1656,9 +1656,53 @@ i40evf_dev_uninit(struct rte_eth_dev *eth_dev)
return 0;
}
+static int
+i40evf_check_driver_handler(__rte_unused const char *key,
+ const char *value, __rte_unused void *opaque)
+{
+ if (strcmp(value, "i40evf"))
+ return -1;
+
+ return 0;
+}
+
+static int
+i40evf_driver_selected(struct rte_devargs *devargs)
+{
+ struct rte_kvargs *kvlist;
+ const char *key = "driver";
+ int ret = 0;
+
+ if (devargs == NULL)
+ return 0;
+
+ kvlist = rte_kvargs_parse(devargs->args, NULL);
+ if (kvlist == NULL)
+ return 0;
+
+ if (!rte_kvargs_count(kvlist, key))
+ goto exit;
+
+ /* i40evf driver selected when there's a key-value pair:
+* driver=i40evf
+*
Re: [dpdk-dev] 19.11.8 patches review and test
Hi Christian, The testing with dpdk 19.11.8-rc1 from Red Hat looks good. We tested below 16 scenarios and and all got PASS on RHEL8: (1)Guest with device assignment(PF) throughput testing(1G hugepage size): PASS (2)Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS (3)Guest with device assignment(VF) throughput testing: PASS (4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS (5)PVP vhost-user 2Q throughput testing: PASS (6)PVP vhost-user 1Q - cross numa node throughput testing: PASS (7)Guest with vhost-user 2 queues throughput testing: PASS (8)vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect: PASS (9)vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS (10)PVP 1Q live migration testing: PASS (11)PVP 1Q cross numa node live migration testing: PASS (12)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS (13)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS (14)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS (15)Host PF + DPDK testing: PASS (16)Host VF + DPDK testing: PASS Versions: kernel 4.18 qemu 5.2 dpdk: git://dpdk.org/dpdk-stable # git log -1 commit 6a1b35022ca0dbdfa04cb7b8bfa5694c2fdda3bc (HEAD, tag: v19.11.8-rc1, origin/19.11) Author: Christian Ehrhardt Date: Thu Apr 8 16:55:20 2021 +0200 version: 19.11.8-rc1 Signed-off-by: Christian Ehrhardt # git branch remotes/origin/19.11 NICs: X540-AT2 NIC(ixgbe, 10G) Best regards, Pei On Fri, Apr 9, 2021 at 3:43 PM Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > Hi all, > > Here is a list of patches targeted for stable release 19.11.8. > > The planned date for the final release is 16th April. > > Please help with testing and validation of your use cases and report > any issues/results with reply-all to this mail. For the final release > the fixes and reported validations will be added to the release notes. > > Note: > This is a special interim release not following the releases of recent > mainline (that was 19.11.7). Instead this addresses issues with >=19.11.6 > identified and discussed in: > http://mails.dpdk.org/archives/stable/2021-March/029418.html > > Testing-Note: > The only changes this release has over the former one are about linking. > We switch back to how it was <=19.11.6 since it regressed some use-cases. > The most known one at the moment is building OVS 2.13 vs a DPDK that was > built with meson. It seems that make-based DPDK builds are unaffected. > Due to that this verification phase should not so much be about the usual > performance, functionality, ... (I'm happy if you run those, but they are > not strictly required). Instead the focus should mostly about buildability > via the various possible combinations that exist. > > A release candidate tarball can be found at: > > https://dpdk.org/browse/dpdk-stable/tag/?id=v19.11.8-rc1 > > These patches are located at branch 19.11 of dpdk-stable repo: > https://dpdk.org/browse/dpdk-stable/ > > Thanks. > > Christian Ehrhardt > > --- > Christian Ehrhardt (7): > Revert "Revert "Revert "build/pkg-config: prevent overlinking""" > Revert "Revert "Revert "build/pkg-config: improve static linking > flags""" > Revert "Revert "Revert "build/pkg-config: output drivers first for > static build""" > Revert "Revert "Revert "build/pkg-config: move pkg-config file > creation""" > Revert "Revert "Revert "build: always link whole DPDK static > libraries""" > Revert "Revert "Revert "devtools: test static linkage with > pkg-config""" > Regenerate meson.build changes required due to reverts > >
Re: [dpdk-dev] [PATCH v2 3/4] vhost: avoid deadlock on async register
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Friday, April 16, 2021 4:34 PM
> To: Hu, Jiayu ; dev@dpdk.org
> Cc: Xia, Chenbo ; Wang, Yinan
> ; Pai G, Sunil ; Jiang, Cheng1
>
> Subject: Re: [PATCH v2 3/4] vhost: avoid deadlock on async register
>
>
>
> On 4/16/21 10:18 AM, Hu, Jiayu wrote:
> > Hi Maxime,
> >
> >> -Original Message-
> >> From: Maxime Coquelin
> >> Sent: Friday, April 16, 2021 2:35 PM
> >> To: Hu, Jiayu ; dev@dpdk.org
> >> Cc: Xia, Chenbo ; Wang, Yinan
> >> ; Pai G, Sunil ; Jiang,
> Cheng1
> >>
> >> Subject: Re: [PATCH v2 3/4] vhost: avoid deadlock on async register
> >>
> >> Hi Jiayu,
> >>
> >> On 4/16/21 4:19 AM, Hu, Jiayu wrote:
> >>> Hi Maxime,
> >> On 4/14/21 3:40 AM, Hu, Jiayu wrote:
> >>> Hi Maxime,
> >>>
> -Original Message-
> From: Maxime Coquelin
> Sent: Tuesday, April 13, 2021 7:33 PM
> To: Hu, Jiayu ; dev@dpdk.org
> Cc: Xia, Chenbo ; Wang, Yinan
> ; Pai G, Sunil ;
> Jiang,
> >> Cheng1
>
> Subject: Re: [PATCH v2 3/4] vhost: avoid deadlock on async register
>
>
>
> On 4/2/21 3:04 PM, Jiayu Hu wrote:
> > Users can register async copy device in vring_state_changed(),
> > when vhost queue is enabled. However, a deadlock occurs inside
> > rte_vhost_async_channel_register(), if
> VHOST_USER_F_PROTOCOL_FEATURES
> > is not supported, as vhost_user_msg_handler() takes vq-
> >>> access_lock
> > before calling vhost_user_set_vring_kick().
> >
> > This patch avoids async register deadlock by removing calling
> > vring_state_changed() in vhost_user_set_vring_kick(). It's safe
> > as vhost_user_msg_handler() will call vring_state_changed()
> >> anyway.
> >
> > Signed-off-by: Jiayu Hu
> > ---
> > lib/librte_vhost/vhost_user.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/lib/librte_vhost/vhost_user.c
> b/lib/librte_vhost/vhost_user.c
> > index 44c0452..8f0eba6 100644
> > --- a/lib/librte_vhost/vhost_user.c
> > +++ b/lib/librte_vhost/vhost_user.c
> > @@ -1918,9 +1918,6 @@ vhost_user_set_vring_kick(struct
> >> virtio_net
> **pdev, struct VhostUserMsg *msg,
> > */
> > if (!(dev->features & (1ULL <<
> VHOST_USER_F_PROTOCOL_FEATURES))) {
> > vq->enabled = true;
> > - if (dev->notify_ops->vring_state_changed)
> > - dev->notify_ops->vring_state_changed(
> > - dev->vid, file.index, 1);
> > }
> >
> > if (vq->ready) {
> >
>
> As replied earlier on v1, I agree the call to vring_state_changed
> here
> is not needed. But it might not be enough, there are other cases
> >> where
> you could have issues.
> >>>
> >>> vhost_user_notify_queue_state() can be called in three cases:
> >>> 1. when vq ready status changes, vhost_user_msg_handler() calls it
> to
> >> notify
> >>> backend. But vhost_user_msg_handler() doesn't take lock before
> >> calling
> it.
> >>> So in this case, no deadlock occurs in async register.
> >>>
> >>> 2. if vq->ready is true, vhost_user_set_vring_call() calls it to
> >>> notify
> backend
> >>> vq is not enabled. Although vhost_user_set_vring_call() is protected
> by
> lock,
> >>> async register is called only if vq is enabled, so async register
> >>> will not
> >> be
> >> called
> >>> in this case.
> >>>
> >>> 3. If vq->ready is true, vhost_user_set_vring_kick() calls it to
> >>> notify
> backend
> >>> vq is not enabled. Same as #2, async register is called only when vq
> is
> >> enabled.
> >>> Even if vhost_user_set_vring_kick() is protected by lock, there is no
> >> deadlock in
> >>> async register, as it will not be called in this case.
> >>>
> >>> In summary, I think there is no deadlock issue in async register if
> >>> we
> >>> can remove calling vring_state_change() in
> >> vhost_user_set_vring_kick().
> >>
> >>
> >> But unregister one could be called in theory no? Otherwise it would
> >> look
> >> unbalanced. At least on disabled notification, the app should make
> sure
> >> the DMA transfers to and from the vring are stopped before it
> returns
> >> from the callabck. Otherwise it could lead to undefined behavior.
> >
> > Right, users need to call unregister, but we cannot remove calling
> > vhost_user_notify_queue_state() in case #2 and #3, IMHO. So to
> > avoid deadlock, we recommended users to call async unregister in
> > destroy_device(), instead of on vring disabled notification. Does it
> > make sense to you?
>
> Ca
[dpdk-dev] [PATCH] net/iavf: fix hash configuration on Fortville VF
In i40evf PMD, the VF directly accesses the hash enable registers to
enable or disable hashing on ingress packets. When binding Fortville VF
to iavf, because the PF doesn't support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF
capability. Therefore, the VF hashing cannot be enabled.
This patch adds support of hash configuration for Fortville VF by
sending VIRTCHNL_OP_SET_RSS_HENA message to the PF after checking
that the PF does not support VIRTCHNL_VF_OFFLOAD_ADV_RSS_PF capability.
Fixes: c678299594a8 ("net/iavf: fix default RSS configuration")
Cc: sta...@dpdk.org
Signed-off-by: Alvin Zhang
---
drivers/net/iavf/iavf.h| 1 +
drivers/net/iavf/iavf_ethdev.c | 111 -
drivers/net/iavf/iavf_vchnl.c | 27 ++
3 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index c934d2e..d6d1b3e 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -336,6 +336,7 @@ int iavf_fdir_check(struct iavf_adapter *adapter,
struct iavf_fdir_conf *filter);
int iavf_add_del_rss_cfg(struct iavf_adapter *adapter,
struct virtchnl_rss_cfg *rss_cfg, bool add);
+int iavf_get_hena_caps(struct iavf_adapter *adapter, uint64_t *caps);
int iavf_set_hena(struct iavf_adapter *adapter, uint64_t hena);
int iavf_rss_hash_set(struct iavf_adapter *ad, uint64_t rss_hf, bool add);
int iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 51cad48..e5fdf4d 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -242,6 +242,107 @@ struct rte_iavf_xstats_name_off {
}
static int
+iavf_config_rss_hf(struct iavf_adapter *adapter, uint64_t rss_hf)
+{
+ static const uint64_t map_hena_rss[] = {
+ /* IPv4 */
+ [IAVF_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
+ ETH_RSS_NONFRAG_IPV4_UDP,
+ [IAVF_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP] =
+ ETH_RSS_NONFRAG_IPV4_UDP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV4_UDP] =
+ ETH_RSS_NONFRAG_IPV4_UDP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
+ ETH_RSS_NONFRAG_IPV4_TCP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV4_TCP] =
+ ETH_RSS_NONFRAG_IPV4_TCP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV4_SCTP] =
+ ETH_RSS_NONFRAG_IPV4_SCTP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV4_OTHER] =
+ ETH_RSS_NONFRAG_IPV4_OTHER,
+ [IAVF_FILTER_PCTYPE_FRAG_IPV4] = ETH_RSS_FRAG_IPV4,
+
+ /* IPv6 */
+ [IAVF_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
+ ETH_RSS_NONFRAG_IPV6_UDP,
+ [IAVF_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP] =
+ ETH_RSS_NONFRAG_IPV6_UDP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV6_UDP] =
+ ETH_RSS_NONFRAG_IPV6_UDP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
+ ETH_RSS_NONFRAG_IPV6_TCP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV6_TCP] =
+ ETH_RSS_NONFRAG_IPV6_TCP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV6_SCTP] =
+ ETH_RSS_NONFRAG_IPV6_SCTP,
+ [IAVF_FILTER_PCTYPE_NONF_IPV6_OTHER] =
+ ETH_RSS_NONFRAG_IPV6_OTHER,
+ [IAVF_FILTER_PCTYPE_FRAG_IPV6] = ETH_RSS_FRAG_IPV6,
+
+ /* L2 Payload */
+ [IAVF_FILTER_PCTYPE_L2_PAYLOAD] = ETH_RSS_L2_PAYLOAD
+ };
+
+ const uint64_t ipv4_rss = ETH_RSS_NONFRAG_IPV4_UDP |
+ ETH_RSS_NONFRAG_IPV4_TCP |
+ ETH_RSS_NONFRAG_IPV4_SCTP |
+ ETH_RSS_NONFRAG_IPV4_OTHER |
+ ETH_RSS_FRAG_IPV4;
+
+ const uint64_t ipv6_rss = ETH_RSS_NONFRAG_IPV6_UDP |
+ ETH_RSS_NONFRAG_IPV6_TCP |
+ ETH_RSS_NONFRAG_IPV6_SCTP |
+ ETH_RSS_NONFRAG_IPV6_OTHER |
+ ETH_RSS_FRAG_IPV6;
+
+ struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
+ uint64_t caps = 0, hena = 0, valid_rss_hf = 0;
+ uint32_t i;
+ int ret;
+
+ ret = iavf_get_hena_caps(adapter, &caps);
+ if (ret)
+ return ret;
+ /**
+* ETH_RSS_IPV4 and ETH_RSS_IPV6 can be considered as 2
+* generalizations of all other IPv4 and IPv6 RSS types.
+*/
+ if (rss_hf & ETH_RSS_IPV4)
+ rss_hf |= ipv4_rss;
+
+ if (rss_hf & ETH_RSS_IPV6)
+ rss_hf |= ipv6_rss;
+
+ RTE_BUILD_BUG_ON(RTE_DIM(map_hena_rss) > size
[dpdk-dev] [PATCH] examples/vhost: fix potential overflow in args process
Add args length check to fix potential overflow issue.
Coverity issue: 363741
Fixes: 965b06f0358 ("examples/vhost: enhance getopt_long usage")
Cc: sta...@dpdk.org
Signed-off-by: Cheng Jiang
---
examples/vhost/main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 119ba7e01..5df36ad3c 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -669,6 +669,11 @@ us_vhost_parse_args(int argc, char **argv)
break;
case OPT_DMA_TYPE_NUM:
+ if (strlen(optarg) >= MAX_LONG_OPT_SZ) {
+ RTE_LOG(INFO, VHOST_CONFIG, "Wrong DMA type\n");
+ us_vhost_usage(prgname);
+ return -1;
+ }
strcpy(dma_type, optarg);
break;
--
2.29.2
[dpdk-dev] [PATCH 1/2] app/testpmd: add link speed check before port start
From: Huisong Li
Currently, to check whether the configured link_speeds is valid, we
have to run "port start". In addition, if the configuration fails,
"port->dev_conf.link_speeds" maintained in testpmd cannot be
restored.
This patch adds the link_speeds check before port start by calling
dev_configure, and resolves these problems.
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
---
app/test-pmd/cmdline.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5bf1497..09e30cf 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1537,8 +1537,12 @@ cmd_config_speed_all_parsed(void *parsed_result,
__rte_unused void *data)
{
struct cmd_config_speed_all *res = parsed_result;
+ uint32_t old_link_speeds[RTE_MAX_ETHPORTS];
+ struct rte_port *port;
uint32_t link_speed;
portid_t pid;
+ portid_t i;
+ int ret;
if (!all_ports_stopped()) {
printf("Please stop all ports first\n");
@@ -1550,7 +1554,26 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;
RTE_ETH_FOREACH_DEV(pid) {
- ports[pid].dev_conf.link_speeds = link_speed;
+ port = &ports[pid];
+ old_link_speeds[pid] = port->dev_conf.link_speeds;
+ port->dev_conf.link_speeds = link_speed;
+ ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
+ &port->dev_conf);
+ if (ret < 0) {
+ printf("Failed to check link speeds for port %d, ret =
%d.\n",
+ pid, ret);
+ goto roolback;
+ }
+ }
+
+ cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
+
+ return;
+
+roolback:
+ for (i = 0; i <= pid; i++) {
+ port = &ports[i];
+ port->dev_conf.link_speeds = old_link_speeds[i];
}
cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
@@ -1609,7 +1632,10 @@ cmd_config_speed_specific_parsed(void *parsed_result,
__rte_unused void *data)
{
struct cmd_config_speed_specific *res = parsed_result;
+ uint32_t old_link_speeds;
+ struct rte_port *port;
uint32_t link_speed;
+ int ret;
if (!all_ports_stopped()) {
printf("Please stop all ports first\n");
@@ -1623,7 +1649,17 @@ cmd_config_speed_specific_parsed(void *parsed_result,
&link_speed) < 0)
return;
- ports[res->id].dev_conf.link_speeds = link_speed;
+ port = &ports[res->id];
+ old_link_speeds = port->dev_conf.link_speeds;
+ port->dev_conf.link_speeds = link_speed;
+ ret = rte_eth_dev_configure(res->id, nb_rxq, nb_txq,
+ &port->dev_conf);
+ if (ret < 0) {
+ printf("Failed to check link speeds for port %d, ret = %d.\n",
+ res->id, ret);
+ port->dev_conf.link_speeds = old_link_speeds;
+ return;
+ }
cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
}
--
2.7.4
[dpdk-dev] [PATCH 0/2] fixes for link speed
This patchset contains fixes for link speed in testpmd. Huisong Li (2): app/testpmd: add link speed check before port start app/testpmd: fix link speed for a specified port app/test-pmd/cmdline.c | 48 +++-- 1 file changed, 42 insertions(+), 6 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH 2/2] app/testpmd: fix link speed for a specified port
From: Huisong Li
When we use the following cmd to modify the link speed of specified
port: "port config speed xxx duplex xxx", we have to stop
all ports. It's not necessary.
Fixes: 82113036e4e5 ("ethdev: redesign link speed config")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
---
app/test-pmd/cmdline.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 09e30cf..31884c5 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1637,13 +1637,13 @@ cmd_config_speed_specific_parsed(void *parsed_result,
uint32_t link_speed;
int ret;
- if (!all_ports_stopped()) {
- printf("Please stop all ports first\n");
+ if (port_id_is_invalid(res->id, ENABLED_WARN))
return;
- }
- if (port_id_is_invalid(res->id, ENABLED_WARN))
+ if (!port_is_stopped(res->id)) {
+ printf("Please stop port %d first\n", res->id);
return;
+ }
if (parse_and_check_speed_duplex(res->value1, res->value2,
&link_speed) < 0)
--
2.7.4
Re: [dpdk-dev] [RFC 3/3] net/virtio: add MAC device config getter and setter
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Friday, March 19, 2021 6:35 AM
> To: dev@dpdk.org; Xia, Chenbo ; amore...@redhat.com;
> david.march...@redhat.com
> Cc: Maxime Coquelin
> Subject: [RFC 3/3] net/virtio: add MAC device config getter and setter
>
> This patch uses the new device config ops to get and set
> the MAC address if supported.
>
> If a valid MAC address is passed as devarg of the
> Virtio-user PMD, the driver will try to store it in the
> device config space. Otherwise the one provided in
> the device config space will be used, if available.
I agree with the MAC selection strategy you proposed.
>
> Signed-off-by: Maxime Coquelin
> ---
> .../net/virtio/virtio_user/virtio_user_dev.c | 78 ---
> .../net/virtio/virtio_user/virtio_user_dev.h | 2 +
> drivers/net/virtio/virtio_user_ethdev.c | 7 +-
> 3 files changed, 74 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
> b/drivers/net/virtio/virtio_user/virtio_user_dev.c
> index 8757a23f6e..61517692b3 100644
> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
> @@ -259,20 +259,76 @@ int virtio_user_stop_device(struct virtio_user_dev *dev)
> return -1;
> }
>
> -static inline void
> -parse_mac(struct virtio_user_dev *dev, const char *mac)
> +int
> +virtio_user_dev_set_mac(struct virtio_user_dev *dev)
> {
> - struct rte_ether_addr tmp;
> + int ret = 0;
>
> - if (!mac)
> - return;
> + if (!(dev->device_features & (1ULL << VIRTIO_NET_F_MAC)))
> + return -ENOTSUP;
> +
> + if (!dev->ops->set_config)
> + return -ENOTSUP;
> +
> + ret = dev->ops->set_config(dev, dev->mac_addr,
> + offsetof(struct virtio_net_config, mac),
> + RTE_ETHER_ADDR_LEN);
> + if (ret)
> + PMD_DRV_LOG(ERR, "(%s) Failed to set MAC address in device\n",
> dev->path);
> +
> + return ret;
> +}
> +
> +int
> +virtio_user_dev_get_mac(struct virtio_user_dev *dev)
> +{
> + int ret = 0;
> +
> + if (!(dev->device_features & (1ULL << VIRTIO_NET_F_MAC)))
> + return -ENOTSUP;
> +
> + if (!dev->ops->get_config)
> + return -ENOTSUP;
> +
> + ret = dev->ops->get_config(dev, dev->mac_addr,
> + offsetof(struct virtio_net_config, mac),
> + RTE_ETHER_ADDR_LEN);
> + if (ret)
> + PMD_DRV_LOG(ERR, "(%s) Failed to get MAC address from device\n",
> dev->path);
>
> - if (rte_ether_unformat_addr(mac, &tmp) == 0) {
> - memcpy(dev->mac_addr, &tmp, RTE_ETHER_ADDR_LEN);
> + return ret;
> +}
> +
> +static void
> +virtio_user_dev_init_mac(struct virtio_user_dev *dev, const char *mac)
> +{
> + struct rte_ether_addr cmdline_mac;
> + int ret;
> +
> + if (mac && rte_ether_unformat_addr(mac, &cmdline_mac) == 0) {
> + /*
> + * MAC address was passed from command-line, try to store
> + * it in the device if it supports it. Otherwise try to use
> + * the device one.
> + */
> + memcpy(dev->mac_addr, &cmdline_mac, RTE_ETHER_ADDR_LEN);
> dev->mac_specified = 1;
How do we define mac_specified? If I understand correctly, it means the mac
we see is from device (we set it or we just use device's). Then
'dev->mac_specified = 1'
should be after get_mac succeeds. Note that during virtio_user_dev_init, we
also use
this val to set VIRTIO_NET_F_MAC. But here the val is set without making sure
the
feature exists.
> +
> + /* Setting MAC may fail, continue to get the device one in this
> case */
> + virtio_user_dev_set_mac(dev);
> + ret = virtio_user_dev_get_mac(dev);
> + if (ret == -ENOTSUP)
> + return;
> +
> + if (memcmp(&cmdline_mac, dev->mac_addr, RTE_ETHER_ADDR_LEN))
> + PMD_DRV_LOG(INFO, "(%s) Device MAC update failed\n",
> dev-
> >path);
Besides Adrian's comments, if we decide to return no error on this, it may also
be good to add something like 'using random MAC' to tell users that the driver
will
use random mac. Adding here or in the function that generates mac is both ok.
The patchset overall looks good to me. I'm looking forward to v1 😊
Thanks,
Chenbo
> } else {
> - /* ignore the wrong mac, use random mac */
> - PMD_DRV_LOG(ERR, "wrong format of mac: %s", mac);
> + ret = virtio_user_dev_get_mac(dev);
> + if (ret)
> + PMD_DRV_LOG(ERR, "(%s) No valid MAC in devargs or
> device,
> use random\n",
> + dev->path);
> + else
> + dev->mac_specified = 1;
> }
> }
>
> @@ -508,8 +564,6 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char
> *path, int queues,
> d
Re: [dpdk-dev] [PATCH] app/testpmd: support the query of link flow ctrl info
Hi,
在 2021/4/19 10:53, Li, Xiaoyun 写道:
Hi
-Original Message-
From: Min Hu (Connor)
Sent: Thursday, April 15, 2021 14:47
To: dev@dpdk.org
Cc: Yigit, Ferruh ; Li, Xiaoyun
Subject: [PATCH] app/testpmd: support the query of link flow ctrl info
From: Huisong Li
This patch supports the query of the link flow control parameter on a port.
The command format is as follows:
show port flow_ctrl
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
---
app/test-pmd/cmdline.c | 83 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 90 insertions(+)
+ printf("\n%s Flow control infos for port %-2d %s\n",
+ info_border, res->port_id, info_border);
+ printf("FC mode:\n");
+ printf(" Rx: %s\n", rx_fc_en ? "On" : "Off");
+ printf(" Tx: %s\n", tx_fc_en ? "On" : "Off");
+ printf("FC autoneg status: %s\n", fc_conf.autoneg != 0 ? "On" : "Off");
"fc_conf.autoneg ? "On" : "Off"" is enough like the others in this patch.Got it.
+ printf("pause_time: 0x%x\n", fc_conf.pause_time);
+ printf("high_water: 0x%x\n", fc_conf.high_water);
+ printf("low_water: 0x%x\n", fc_conf.low_water);
+ printf("Send Xon: %s\n", fc_conf.send_xon ? "On" : "Off");
+ printf("mac ctrl frame fwd: %s\n",
Follow others' format will be better like "Send Xon".
"Forward MAC control frames:"
I don not catch your meaning. Is that right?:
change the statement
"
+ printf("Send Xon: %s\n", fc_conf.send_xon ? "On" : "Off");
+ printf("mac ctrl frame fwd: %s\n",fc_conf.mac_ctrl_frame_fwd ? "On" :
"Off")
"
to
"
+ printf("Send Xon: %s\n", fc_conf.send_xon ? "On" : "Off");
+ printf("Forward MAC control frames: %s\n",fc_conf.mac_ctrl_frame_fwd ?
"On" : "Off")
"
+ fc_conf.mac_ctrl_frame_fwd ? "On" : "Off");
+ printf("\n%s** End ***%s\n",
+ info_border, info_border);
+}
+
--
2.7.4
.
Re: [dpdk-dev] [PATCH v9] app/testpmd: support multi-process
Tested-by: Aman Deep Singh
Re: [dpdk-dev] [PATCH] eal/windows: fix build warnings in MinGW
> Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW > > External email: Use caution opening links or attachments > > > Hi Tal, > > 2021-04-18 19:04 (UTC+), Tal Shnaiderman: > > > Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW > > > > > > External email: Use caution opening links or attachments > > > > > > > > > 18/04/2021 19:08, Tal Shnaiderman: > > > > the strncasecmp marco defined in rte_os_shim.h is already defined > > > > in MinGW-w64, as a result the compiler prints out the warning > > > > below on function redefinition whenever compiling a file including the > header. > > > > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21: > > > > warning: "strncasecmp" redefined > > > > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count) > > > > > > Why the tests are passing? Are we allowing warnings in build test? > > > > It's a good question, I see CI is passing without warnings, Dmitry can you > reproduce it? > > > > On my side the collision is with the following file: > > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64- > mingw32/include/string.h:119: > > note: this is the location of the previous definition #define > > strncasecmp _strnicmp > > > > I'm using: > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0 -meson > > 0.53.2 > > I can't reproduce it using the same versions. > Do you invoke meson with other options than "-Dexamples=..."? This is the meson line I'm using: meson "-Dexamples=helloworld" build --wipe --default-library=static --buildtype debug The problem however is that MinGW's string.h defines the macro in line 119, for some reason my build includes it and the rest doesn't.
