[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
Hi Neil, On 12/01/2014 06:16 PM, Neil Horman wrote: >>> [...] >>> >>> Whats the advantage to keeping this warning? >>> >> The advantage is that it does exactly what it's meant to do. If someone goes >> to >> assign l2_len = 128; somewhere, it will throw a warning. If someone goes to >> change >> the lpm library and set [lpm_table_entry].depth = 64 somewhere, it will throw >> a warning. The reason the warning is a problem here is because we are in the >> usual position of wanting to initialize all values to 1's. It's causing >> problems >> nowhere else. >> >> However, let me query the scope of the disabling the warning you are talking >> about. >> If we just disable the warning for the one problematic function, it's >> probably >> reasonable enough because of the all-1's initialization, but disabling it >> globally >> is not something I would agree with. >> > No, this actually makes some sense as far as the warning goes, though it seems > like we can't rely on it, since clang is the only thing that throws the > warning. > > That said, I was just looking at this code, and I think the use of these > bitfields is problematic anyway (or at least potentially so). The bitfields > exist as a set in a union that also contains a data field, and the bitfields > and > data are type puned (both in the ixgbe implementation and I think in the > rte_mbuf implementation). GCC (nor any C compiler that I'm aware of) provides > any guarantee regarding the bit endianess of any given field, nor any padding > in > between bitfields, nor any ordering among bitfields. The take away from that > is, while I can't currently find any use of the data member of the referenced > unions, if theres any expectation as to the value of said data member of that > union, theres no guarantee it will be correct between platforms. It seems > like > we should be using a single typed integer value here and some bit shifting > values to set fields within it, rather than bitfields. The padding and endianess of bitfields is maybe not defined, but I think many people at least suppose the way it works, since we have the following code in standard headers (netinet/ip.h): #if __BYTE_ORDER == __LITTLE_ENDIAN unsigned int flags:4; unsigned int overflow:4; #elif __BYTE_ORDER == __BIG_ENDIAN unsigned int overflow:4; unsigned int flags:4; That said, the .data field of the union is only used to do faster assignment and comparison in ixgbe or mbuf, so I don't think there is no issue with that. About removing the warning, I agree with Bruce: it is maybe useful in other cases and I think we should keep it. However, if there is no consensus on the "|=" solution, I can provide another patch that solves the issue in a different way, maybe using a static const variable. Regards, Olivier
[dpdk-dev] RTE mempool "used count" steadily goes down to zero despite steady packet throughput
Thanks Oliver for the helpful tip, that settles the confusion as to why Free count grows and used shrinks. I've modified the rte_mempool library to maintain atomic pktmbuf malloc and free stats, hopefully that would help pinpoint the leak. Thanks again for your help! --Kam On Mon, Dec 1, 2014 at 4:58 AM, Olivier MATZ wrote: > Hi Kam, > > On 11/28/2014 06:34 PM, Kamraan Nasim wrote: > > I have ~15Gbps of traffic flowing through two 10GE ports and been > profiling > > the rte mempool(or rather the pktmbuf mempool) memory consumption: > > > > I have per lcore caching disabled(cache_size is 0) > > > > I have noticed that: > > - Mempool FREE cnt(as given byt rte_mempool_free_count()) increases > > - Mempool USED cnt(as given by rte_mempool_used_count() decreases and > > eventually drops to 0. When this happens, mempool reports itself as EMPTY > > - rx_nombuf stats for the eth ports start climbing > > - Valgrind Memcheck does not indicate any obvious leaks in RTE mempool or > > my application. > > > > > > I was wondering if others have come across this issue? Or if people here > > have used ways, besides Valgrind to profile the mempool or the pkt mbuf > > pool? > > First, be careful with rte_mempool_free_count(): it returns the number > of free entries in the internal ring of the mempool, which actually > corresponds to the number of allocated objects from the mempool point > of view. See: > http://dpdk.org/browse/dpdk/tree/lib/librte_mempool/rte_mempool.h > > If you have the number of allocated objects increasing, and the > statistics rx_nombuf increasing when the mbuf pool is empty, it means > that you have a mbuf leak in your application. Valgrind won't see it > since it does not know about mempool alloc/free functions. > > Regards, > Olivier >
[dpdk-dev] [PATCH] ixgbe: fix build with bypass and debug enabled
On Mon, Dec 1, 2014 at 6:40 PM, Thomas Monjalon
wrote:
> Since commit aae1047905621 ("use the right debug macro"),
> DEBUGOUT was replaced by PMD_DRV_LOG which requires at least
> 2 arguments. But the level argument was missing.
>
> Commit 7a10de5e27 fixed the logs but not the macros FUNC_PTR_OR_*
> which are not preprocessed if RTE_LIBRTE_IXGBE_DEBUG_DRIVER is disabled.
>
> Signed-off-by: Thomas Monjalon
> ---
> lib/librte_pmd_ixgbe/ixgbe_bypass.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_bypass.c
> b/lib/librte_pmd_ixgbe/ixgbe_bypass.c
> index 15203a4..832f415 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_bypass.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_bypass.c
> @@ -42,7 +42,7 @@
> /* Macros to check for invlaid function pointers. */
> #defineFUNC_PTR_OR_ERR_RET(func, retval) do { \
> if ((func) == NULL) { \
> - PMD_DRV_LOG("%s:%d function not supported", \
> + PMD_DRV_LOG(ERR, "%s:%d function not supported", \
> __func__, __LINE__);\
> return retval;\
> } \
> @@ -50,7 +50,7 @@
>
> #defineFUNC_PTR_OR_RET(func) do { \
> if ((func) == NULL) { \
> - PMD_DRV_LOG("%s:%d function not supported", \
> + PMD_DRV_LOG(ERR, "%s:%d function not supported", \
> __func__, __LINE__);\
> return; \
> } \
>
>
>
Argh ... good catch.
Looks like these were the only places with this error (I did some grep and
only found those).
And ok with the ERR level, it looks fine to me.
Ack.
Thanks Thomas.
--
David Marchand
[dpdk-dev] Avoid stripping vlan tag with I350 VF on a VM
Did you try to remove the VLAN strip on the PF side?
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shiantung Wong
Sent: Monday, December 01, 2014 11:29 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Avoid stripping vlan tag with I350 VF on a VM
My application running on a VM needs to deal with multiple VLANS on packets
received over I350 using Virtual Function. But I always see the received
packets without vlan tag.
This is my setup:
- host: 3.13.6-031306-generic
- QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
- guest: 2.6.32-358.el6.x86_64
- dpdk: 1.6
And this is how I set up in the VM:
---
memset(&port_conf, 0, sizeof(port_conf));
if (vlanCnt > 0)
port_conf.rxmode.hw_vlan_filter = 1;
port_conf.rxmode.jumbo_frame = 1;
port_conf.rxmode.max_rx_pkt_len = 9018;
ret = rte_eth_dev_configure(port, 1, 1, &port_conf);
if (ret < 0) {
rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
ret=%d\n",
(unsigned)port, ret);
return -1;
}
for(i = 0; i < vlanCnt; i++) {
ret = rte_eth_dev_vlan_filter(port, vlan[i], 1);
if (ret < 0) {
rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
vlan%d ret=%d\n",
(unsigned)port, vlan[i], ret);
return -1;
}
}
-
If I also try to explicitly disable the stripping with next, but get an error
return -ENOSUP.
ret = rte_eth_dev_set_vlan_strip_on_queue(port, 0, 0);
I appreciate anyone can help. on how to set it up.
Thanks,
Shian Wong
[dpdk-dev] attachment policy
2014-12-01 09:40, O'driscoll, Tim: > I'm not sure of the policy for sending attachments to the list. > Perhaps that's something that Thomas can clarify. There is some basic filtering of attachments. The goal is to not be polluted with useless or harmful attachments. These MIME types are allowed: text/plain application/zip application/x-tar application/x-gzip application/x-bzip-compressed-tar application/pdf application/vnd.oasis.opendocument.spreadsheet image/png More can be added. -- Thomas
[dpdk-dev] [PATCH 4/4] Doc: Moved known issue 6.29 to resolved issues in Rel Notes
Signed-off-by: Siobhan Butler --- doc/guides/rel_notes/resolved_issues.rst | 28 1 file changed, 28 insertions(+) diff --git a/doc/guides/rel_notes/resolved_issues.rst b/doc/guides/rel_notes/resolved_issues.rst index f9ddb7f..59355f9 100644 --- a/doc/guides/rel_notes/resolved_issues.rst +++ b/doc/guides/rel_notes/resolved_issues.rst @@ -1192,3 +1192,31 @@ Packet reception issues when virtualization is enabled | Driver/Module | Poll mode drivers | | | | +-+---+ + +Double VLAN does not work on Intel? 40GbE ethernet contoller + + ++-+---+ +| Title | Double VLAN does not work on Intel? 40GbE ethernet controller | +| | | ++=+===+ +| Reference # | | +| | | ++-+---+ +| Description | On Intel? 40 GbE ethernet controller double VLAN does not work. | +| | This was confirmed as a Firmware issue which will be fixed in later versions of | +| | firmware. | ++-+---+ +| Implication | After setting double vlan to be enabled on a port, no packets can be transmitted out | +| | on that port. | ++-+---+ +| Resolution/Workaround | Resolved in latest release with firmware upgrade. | +| | | +| | | ++-+---+ +| Affected Environment/Platform | All | +| | | ++-+---+ +| Driver/Module | Poll mode drivers | +| | | ++-+---+ -- 1.8.5.3
[dpdk-dev] [PATCH 3/4] Doc: Added to known issue 6.10 and removed fixed issue 6.29 from Rel_Notes
Signed-off-by: Siobhan Butler --- doc/guides/rel_notes/known_issues.rst | 40 +++ 1 file changed, 8 insertions(+), 32 deletions(-) diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst index 8ef654a..7dd05cb 100644 --- a/doc/guides/rel_notes/known_issues.rst +++ b/doc/guides/rel_notes/known_issues.rst @@ -338,6 +338,12 @@ Not all variants of supported NIC types have been used in testing || | || The NIC device identifiers used during testing: | || | +|| * Intel? Ethernet Controller XL710 for 40GbE QSFP+ [8086:1584] | +|| | +|| * Intel? Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583] | +|| | +|| * Intel? Ethernet Controller X710 for 10GbE SFP+ [8086:1572] | +|| | || * Intel? 82576 Gigabit Ethernet Controller [8086:10c9] | || | || * Intel? 82576 Quad Copper Gigabit Ethernet Controller [8086:10e8] | @@ -940,38 +946,8 @@ Ethertype filter could receive other packets (non-assigned) in Niantic || | ++--+ -Double VLAN does not work on Intel? 40G ethernet controller - -++--+ -| Title | Double VLAN does not work on Intel? 40G ethernet controller | -|| | -++==+ -| Reference #| IXA00386480 | -|| | -++--+ -| Description| On Intel? 40G Ethernet Controller: | -|| | -|| Double VLAN does not work. This was confirmed a firmware issue which will be fixed | -|| in later versions of firmware. | -|| | -++--+ -| Implication| After setting double vlan to be enabled on a port, no packets can be transmitted out | -|| on that port. | -|| | -++--+ -| Resolution/ Workaround | None | -|| | -++--+ -| Affected Environment/ Platform | All
[dpdk-dev] [PATCH 2/4] Doc: Added "New Features" to release notes
Signed-off-by: Siobhan Butler --- doc/guides/rel_notes/new_features.rst | 24 1 file changed, 24 insertions(+) diff --git a/doc/guides/rel_notes/new_features.rst b/doc/guides/rel_notes/new_features.rst index a93aa3c..00895ce 100644 --- a/doc/guides/rel_notes/new_features.rst +++ b/doc/guides/rel_notes/new_features.rst @@ -30,6 +30,30 @@ New Features +* Link Bonding +* Support for 802.3ad link aggregation (mode 4) and transmit load balancing (mode 5) to the link bonding library. + +* Support for registration of link status change callbacks with link bonding devices. + +* Support for slaves devices which do not support link status change interrupts in the link bonding library via a link status polling mechanism. + +* Poll Mode Driver - 40 GbE Controllers (librte_pmd_i40e) + +* Support for Flow Director + +* Support for ethertype filter + +* Support RSS in VF + +* Support configuring redirection table with different size from 1GbE and 10 GbE + + - 128/512 entries of 40GbE PF + + - 64 entries of 40GbE VF + +* Support configuring hash functions + +* Packet Distributor Sample Application For further features supported in this release, see Chapter 3 Supported Features. -- 1.8.5.3
[dpdk-dev] [PATCH 1/4] Doc: Moved 1.7 "New Features" to "Supported Features" for 1.8 in Rel_Notes
Signed-off-by: Siobhan Butler --- doc/guides/rel_notes/new_features.rst | 17 - doc/guides/rel_notes/supported_features.rst | 22 ++ 2 files changed, 22 insertions(+), 17 deletions(-) diff --git a/doc/guides/rel_notes/new_features.rst b/doc/guides/rel_notes/new_features.rst index 568d0c9..a93aa3c 100644 --- a/doc/guides/rel_notes/new_features.rst +++ b/doc/guides/rel_notes/new_features.rst @@ -31,22 +31,5 @@ New Features -* Packet Distributor library for dynamic, single-packet at a time, load balancing - -* IP fragmentation and reassembly library - -* Support for IPv6 in IP fragmentation and reassembly sample applications - -* Support for VFIO for mapping BARs and setting up interrupts - -* Link Bonding PMD Library supporting round-robin, active backup, balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding modes - -* Support zero copy mode RX/TX in user space vhost sample - -* Support multiple queues in virtio-net PMD - -* Support for Intel? 40GbE Controllers - -* Support NIC filters in addition to flow director for Intel? 1GbE and 10GbE Controllers For further features supported in this release, see Chapter 3 Supported Features. diff --git a/doc/guides/rel_notes/supported_features.rst b/doc/guides/rel_notes/supported_features.rst index c51eb26..797b57e 100644 --- a/doc/guides/rel_notes/supported_features.rst +++ b/doc/guides/rel_notes/supported_features.rst @@ -31,6 +31,28 @@ Supported Features == +* Packet Distributor library for dynamic, single-packet at a time, load balancing + +* IP fragmentation and reassembly library + +* Support for IPv6 in IP fragmentation and reassembly sample applications + +* Support for VFIO for mapping BARs and setting up interrupts + +* Link Bonding PMD Library supporting round-robin, active backup, balance(layer 2, layer 2+3, and layer 3+4) and broadcast bonding mode + +* Support zero copy mode RX/TX in user space vhost sample + +* Support multiple queues in virtio-net PMD + +* Support for Intel? 40GbE Controllers: + +* Intel? XL710 40 Gigabit Ethernet Controller + +* Intel? X710 40 Gigabit Ethernet Controller + +* Support NIC filters in addition to flow director for Intel? 1GbE and 10GbE Controllers + * Virtualization (KVM) * Userspace vhost switch: -- 1.8.5.3
[dpdk-dev] [PATCH 0/4]Doc: Patch set to update release notes
New Features section: - Removed 1.7 New Features - Added 1.8.0 New Features Supported Features section: - Added 1.7 features to Supported Features Known Issues: - Added devices to Known issue "Not all varients of supported NIC types have been used in testing" - Removed known issue 6.29 "Double VLAN not working on 40GbE Ethnet Controller" as resolved Resolved issues: - Added known issue 6.29 to resolved issues Siobhan Butler (4): Doc: Moved 1.7 "New Features" to "Supported Features" for 1.8 in Rel_Notes Doc: Added "New Features" to release notes Doc: Added to known issue 6.10 and removed fixed issue 6.29 from Rel_Notes Doc: Moved known issue 6.29 to resolved issues in Rel Notes doc/guides/rel_notes/known_issues.rst | 38 ++--- doc/guides/rel_notes/new_features.rst | 27 doc/guides/rel_notes/resolved_issues.rst| 30 +++ doc/guides/rel_notes/supported_features.rst | 22 + 4 files changed, 76 insertions(+), 41 deletions(-) -- 1.9.4.msysgit.2
[dpdk-dev] [PATCH] ixgbe: fix build with bypass and debug enabled
Since commit aae1047905621 ("use the right debug macro"),
DEBUGOUT was replaced by PMD_DRV_LOG which requires at least
2 arguments. But the level argument was missing.
Commit 7a10de5e27 fixed the logs but not the macros FUNC_PTR_OR_*
which are not preprocessed if RTE_LIBRTE_IXGBE_DEBUG_DRIVER is disabled.
Signed-off-by: Thomas Monjalon
---
lib/librte_pmd_ixgbe/ixgbe_bypass.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_bypass.c
b/lib/librte_pmd_ixgbe/ixgbe_bypass.c
index 15203a4..832f415 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_bypass.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_bypass.c
@@ -42,7 +42,7 @@
/* Macros to check for invlaid function pointers. */
#defineFUNC_PTR_OR_ERR_RET(func, retval) do { \
if ((func) == NULL) { \
- PMD_DRV_LOG("%s:%d function not supported", \
+ PMD_DRV_LOG(ERR, "%s:%d function not supported", \
__func__, __LINE__);\
return retval;\
} \
@@ -50,7 +50,7 @@
#defineFUNC_PTR_OR_RET(func) do { \
if ((func) == NULL) { \
- PMD_DRV_LOG("%s:%d function not supported", \
+ PMD_DRV_LOG(ERR, "%s:%d function not supported", \
__func__, __LINE__);\
return; \
} \
--
2.1.3
[dpdk-dev] [BUG] ixgbe vector cannot compile without bulk alloc
These 2 configuration options are incompatible: CONFIG_RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC=n CONFIG_RTE_IXGBE_INC_VECTOR=y Building this config gives this error: lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:69:24: error: ?struct igb_rx_queue? has no member named ?fake_mbuf? I'd like a confirmation that it will be always incompatible. Thanks -- Thomas
[dpdk-dev] Problem in running DPDK quick assist technology environment application
Hi, Checked with the Quick Assist Technology, QAT team. Please find the following recommendation. Can you please submit your question in QAT forum here: https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches While submitting in QAT forum, please furnish the following information: * Which Linux distribution and kernel are you using? * What is the output of "cat /proc/cmdline"? * Have you changed the QuickAssist configuration files? If so, please provide them. * If you compile and run the performance sample code, do things work for you? That would be the first step, to verify that things can work in your environment. * Are you compiling with any virtualization build flags? And what are your virtualization details (if applicable)? (e.g. running on host, running on guest, guest OS details, build flags of each, etc) Note: there is one FAQ in the release notes (available here: https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches ) that may apply: see Section 5.11. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pankaj Joshi Sent: Monday, December 01, 2014 3:28 AM To: dev at dpdk.org Subject: [dpdk-dev] Problem in running DPDK quick assist technology environment application hi, I have run DPDK qat example . working fine for me . I have written a sample application for coletocreek hardware using QAT apis . 1. The crypto initialization is successfule. 2. API cpaCySymDpInitSession is returning successful. 3. Crypto enque is successful. 4. While doing the flush queue , cpaCySymDpPerformOpNow API giving the error like : tail -f /var/log/messages Dec 1 14:53:13 linux-frmb kernel: [ 2404.420731] icp_qa_al err: adf_dh895xcc_adf_isr_handleUncoInterrupt: Uncorrectable Error Occurred on CPM 5 Dec 1 14:53:13 linux-frmb kernel: [ 2404.420736] icp_qa_al err: adf_dh895xcc_adf_isr_LogSSM_Int: Push/Pull Error on CPM 5 Dec 1 14:53:13 linux-frmb kernel: [ 2404.420737] One error occured - Error type: Data asserted on Dram Push Data Bus Dec 1 14:53:13 linux-frmb kernel: [ 2404.420738] id 0x580D547C Dec 1 14:53:13 linux-frmb kernel: [ 2404.420744] icp_qa_al err: adf_dh895xcc_adf_isr_handleUncoInterrupt: Uncorrectable Push/Pull Misc Error Dec 1 14:53:13 linux-frmb kernel: [ 2404.420745] memory status: No errors occurred - Transaction Id 0x0 - Error type reserved Dec 1 14:53:13 linux-frmb kernel: [ 2404.420746] Bus Operation Type Push - Id 0x580D547C Dec 1 14:53:13 linux-frmb kernel: [ 2404.420747] Reset needed for device: icp_dev0 pls let me know how to proceed . how can I debug this Thanks in advance .. Pankaj.
[dpdk-dev] [BUG] ixgbe vector cannot compile without bulk alloc
On Mon, Dec 01, 2014 at 06:10:18PM +0100, Thomas Monjalon wrote: > These 2 configuration options are incompatible: > CONFIG_RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC=n > CONFIG_RTE_IXGBE_INC_VECTOR=y > Building this config gives this error: > lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:69:24: > error: ?struct igb_rx_queue? has no member named ?fake_mbuf? > > I'd like a confirmation that it will be always incompatible. > Thanks > -- > Thomas Hi Thomas, I don't think these options should always be incompatible, though as you point out you do need to turn on bulk alloc support in order to use the vector PMD. Why do you ask? There are no immediate plans to remove the dependency on our end. /Bruce
[dpdk-dev] [PATCH] doc: link bonding related updates to programmers guide
Adding details for link status interrupts and link status polling.
Adding details for mode 4 / mode 5
Tidying up rst document to conform to 80 character line limit
Adding diagrams to explain bonding modes
Signed-off-by: Declan Doherty
---
doc/guides/prog_guide/img/bond-mode-0.svg | 638 +
doc/guides/prog_guide/img/bond-mode-1.svg | 724 +++
doc/guides/prog_guide/img/bond-mode-2.svg | 702 ++
doc/guides/prog_guide/img/bond-mode-3.svg | 702 ++
doc/guides/prog_guide/img/bond-mode-4.svg | 784 +
doc/guides/prog_guide/img/bond-mode-5.svg | 642 +
doc/guides/prog_guide/img/bond-overview.svg| 121
.../prog_guide/link_bonding_poll_mode_drv_lib.rst | 366 +++---
8 files changed, 4579 insertions(+), 100 deletions(-)
create mode 100644 doc/guides/prog_guide/img/bond-mode-0.svg
create mode 100644 doc/guides/prog_guide/img/bond-mode-1.svg
create mode 100644 doc/guides/prog_guide/img/bond-mode-2.svg
create mode 100644 doc/guides/prog_guide/img/bond-mode-3.svg
create mode 100644 doc/guides/prog_guide/img/bond-mode-4.svg
create mode 100644 doc/guides/prog_guide/img/bond-mode-5.svg
create mode 100644 doc/guides/prog_guide/img/bond-overview.svg
diff --git a/doc/guides/prog_guide/img/bond-mode-0.svg
b/doc/guides/prog_guide/img/bond-mode-0.svg
new file mode 100644
index 000..eff0edb
--- /dev/null
+++ b/doc/guides/prog_guide/img/bond-mode-0.svg
@@ -0,0 +1,638 @@
+
+
+
+http://purl.org/dc/elements/1.1/";
+ xmlns:cc="http://creativecommons.org/ns#";
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
+ xmlns:svg="http://www.w3.org/2000/svg";
+ xmlns="http://www.w3.org/2000/svg";
+ xmlns:xlink="http://www.w3.org/1999/xlink";
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+ width="332.15576"
+ height="334.46951"
+ viewBox="0 0 265.725 267.57566"
+ xml:space="preserve"
+ color-interpolation-filters="sRGB"
+ class="st16"
+ id="svg3406"
+ version="1.1"
+ inkscape:version="0.48.5 r10040"
+ sodipodi:docname="bond-mode-0.svg"
+
style="font-size:12px;fill:none;stroke-linecap:square;stroke-miterlimit:3;overflow:visible">image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage";
/>
+ .st1 {visibility:visible}
+ .st2
{fill:#5b9bd5;fill-opacity:0.25;filter:url(#filter_2);stroke:#5b9bd5;stroke-opacity:0.25}
+ .st3 {fill:#4f87bb;stroke:#40709c;stroke-width:0.75}
+ .st4 {fill:#fe;font-family:Calibri;font-size:0.86em}
+ .st5 {fill:url(#grad0-11);stroke:#4f87bb;stroke-width:0.75}
+ .st6 {fill:#4f87bb;font-family:Calibri;font-size:0.86em}
+ .st7
{fill:#759fcc;fill-opacity:0.25;filter:url(#filter_2);stroke:#759fcc;stroke-opacity:0.25}
+ .st8 {fill:#668bb3;stroke:#547395;stroke-width:0.75}
+ .st9
{fill:#5b9bd5;fill-opacity:0.22;filter:url(#filter_2);stroke:#5b9bd5;stroke-opacity:0.22}
+ .st10 {fill:#5b9bd5;stroke:#c7c8c8;stroke-width:0.25}
+ .st11
{fill:#759fcc;fill-opacity:0.22;filter:url(#filter_2);stroke:#759fcc;stroke-opacity:0.22}
+ .st12 {fill:#759fcc;stroke:#c7c8c8;stroke-width:0.25}
+ .st13 {fill:url(#grad0-40);stroke:#a6b6cd;stroke-width:0.75}
+ .st14
{fill:#70ad47;fill-opacity:0.25;filter:url(#filter_2);stroke:#70ad47;stroke-opacity:0.25}
+ .st15 {fill:#61973d;stroke:#507e31;stroke-width:0.75}
+ .st16
{fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
+ Page-4Rectangle.7User ApplicationUser Application
+Sheet.2Rectangle.38DPDKDPDK
+Rectangle.16bonded ethdevbonded ethdev
+Rectangle.11ethdev portethdev port
+Rectangle.14ethdev portethdev port
+Rectangle.15ethdev portethdev port
+Simple Double Arrow.14Simple ArrowSimple Arrow.37Simple Arrow.38Simple Arrow.39Square.11411
+Square.11522
+Square.11633
+Square.11744
+Square.11855
+Square.12011
+Square.12122
+Square.12233
+Square.12344
+Square.12455
+
\ No newline at end of file
diff --git a/doc/guides/prog_guide/img/bond-mode-1.svg
b/doc/guides/prog_guide/img/bond-mode-1.svg
new file mode 100644
index 000..c177e85
--- /dev/null
+++ b/doc/guides/prog_guide/img/bond-mode-1.svg
@@ -0,0 +1,724 @@
+
+
+
+http://schemas.microsoft.com/visio/2003/SVGExtensions/";
+ xmlns:dc="http://purl.org/dc/elements/1.1/";
+ xmlns:cc="http://creativecommons.org/ns#";
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
+ xmlns:svg="http://www.w3.org/2000/svg";
+ xmlns="http://www.w3.org/2000/svg";
+ xmlns:xlink="http://www.w3.org/1999/xlink";
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+ width="
[dpdk-dev] Problem in running DPDK quick assist technology environment application
hi, I have run DPDK qat example . working fine for me . I have written a sample application for coletocreek hardware using QAT apis . 1. The crypto initialization is successfule. 2. API cpaCySymDpInitSession is returning successful. 3. Crypto enque is successful. 4. While doing the flush queue , cpaCySymDpPerformOpNow API giving the error like : tail -f /var/log/messages Dec 1 14:53:13 linux-frmb kernel: [ 2404.420731] icp_qa_al err: adf_dh895xcc_adf_isr_handleUncoInterrupt: Uncorrectable Error Occurred on CPM 5 Dec 1 14:53:13 linux-frmb kernel: [ 2404.420736] icp_qa_al err: adf_dh895xcc_adf_isr_LogSSM_Int: Push/Pull Error on CPM 5 Dec 1 14:53:13 linux-frmb kernel: [ 2404.420737] One error occured - Error type: Data asserted on Dram Push Data Bus Dec 1 14:53:13 linux-frmb kernel: [ 2404.420738] id 0x580D547C Dec 1 14:53:13 linux-frmb kernel: [ 2404.420744] icp_qa_al err: adf_dh895xcc_adf_isr_handleUncoInterrupt: Uncorrectable Push/Pull Misc Error Dec 1 14:53:13 linux-frmb kernel: [ 2404.420745] memory status: No errors occurred - Transaction Id 0x0 - Error type reserved Dec 1 14:53:13 linux-frmb kernel: [ 2404.420746] Bus Operation Type Push - Id 0x580D547C Dec 1 14:53:13 linux-frmb kernel: [ 2404.420747] Reset needed for device: icp_dev0 pls let me know how to proceed . how can I debug this Thanks in advance .. Pankaj.
[dpdk-dev] [PATCH 0/2] Fix clang compilation on FreeBSD
> This patch contains fixes for two compilation errors that occur with clang > on FreeBSD. These errors are not seen when compiling with clang on Fedora > Linux. > > Bruce Richardson (2): > testpmd: fix out-of-range compiler error > testpmd: fix macro check for little endian Acked-by: Thomas Monjalon Applied Thanks -- Thomas
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 11:35:28AM -0500, Neil Horman wrote:
> On Mon, Dec 01, 2014 at 03:24:32PM +, Bruce Richardson wrote:
> > On Mon, Dec 01, 2014 at 10:18:06AM -0500, Neil Horman wrote:
> > > On Mon, Dec 01, 2014 at 02:36:46PM +, Bruce Richardson wrote:
> > > > On Mon, Dec 01, 2014 at 09:25:44AM -0500, Neil Horman wrote:
> > > > > On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> > > > > > On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > > > > > > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > > > > > > Hi Bruce, Hi Neil,
> > > > > > > >
> > > > > > > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > > > > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson
> > > > > > > > > wrote:
> > > > > > > > >> When compiling with clang, errors were being emitted due to
> > > > > > > > >> truncation
> > > > > > > > >> of values when assigning to the tx_offload_mask bit fields.
> > > > > > > > >>
> > > > > > > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal
> > > > > > > > >> error: implicit truncation from 'int' to bitfield changes
> > > > > > > > >> value from -1 to 127 [-Wbitfield-constant-conversion]
> > > > > > > > >> tx_offload_mask.l2_len = ~0;
> > > > > > > > >>
> > > > > > > > >> The fix proposed here is to define a static const value of
> > > > > > > > >> the same type
> > > > > > > > >> with all fields set to 1s, and use that instead of constants
> > > > > > > > >> for assigning to.
> > > > > > > > >>
> > > > > > > > >> Other options would be to explicitily define the suitable
> > > > > > > > >> constants that
> > > > > > > > >> would not truncate for each individual field e.g. 0x7f for
> > > > > > > > >> l2_len, 0x1FF
> > > > > > > > >> for l3_len, etc., but this solution here has the advantage
> > > > > > > > >> that it works
> > > > > > > > >> without any changes to values if the field sizes are ever
> > > > > > > > >> modified.
> > > > > > > > >>
> > > > > > > > >> Signed-off-by: Bruce Richardson > > > > > > > >> intel.com>
> > > > > > > > >> ---
> > > > > > > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29
> > > > > > > > >> +++--
> > > > > > > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > > > > > > >>
> > > > > > > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > >> index 8559ef6..4f71194 100644
> > > > > > > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue*
> > > > > > > > >> txq,
> > > > > > > > >> volatile struct ixgbe_adv_tx_context_desc
> > > > > > > > >> *ctx_txd,
> > > > > > > > >> uint64_t ol_flags, union ixgbe_tx_offload
> > > > > > > > >> tx_offload)
> > > > > > > > >> {
> > > > > > > > >> +static const union ixgbe_tx_offload offload_allones = {
> > > > > > > > >> .data = ~0 };
> > > > > > > > > Do you want to make this a static data structure? If you
> > > > > > > > > make it a macro like
> > > > > > > > > this:
> > > > > > > > > #define ALLONES {.data = ~0}
> > > > > > > > > Then you save the extra data space in the .data area (not
> > > > > > > > > that its that much),
> > > > > > > > > and you can define it in a header file and use it in multiple
> > > > > > > > > c files (if you
> > > > > > > > > need to)
> > > > > > > >
> > > > > > > > I found that the following code works:
> > > > > > > >
> > > > > > > > tx_offload_mask.l2_len |= ~0;
> > > > > > > >
> > > > > > > > (note the '|=' instead of '=')
> > > > > > > >
> > > > > > > How exactly does this work? does the or operator imply some level
> > > > > > > of type
> > > > > > > promotion that the assignment doesn't to avoid the truncation?
> > > > > > > Neil
> > > > > > >
> > > > > >
> > > > > > For any aithmetic, and presumably logical, operation on two values,
> > > > > > any values
> > > > > > smaller than "int" are promoted to type int before the operation
> > > > > > takes place. I
> > > > > > believe the exact rules for this are in the C specs e.g. C99.
> > > > > >
> > > > > Yes, but I would have thought that assignment was included in the
> > > > > list of
> > > > > logical operations for that promotion to occur. The above change
> > > > > seems to
> > > > > suggest it isn't, which is why I'm asking. C99 specifies |=
> > > > > explicitly as a
> > > > > type of assignment operator (see 6.5.16 here:
> > > > > http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> > > > > )
> > > > >
> > > > > So I would presume that using = should work exactly the same as |= in
> > > > > terms of
> > > > > type promotion. We also don't get this warning on gcc, which
> > > > > concerns me that
> > > > > we might just be papering over a compiler problem here.
> > > > >
> > > > > Looking at the error, its complaining t
[dpdk-dev] [PATCH] lpm: fix maybe-uninitialized warning when using LTO during compilation
This patch fixes a maybe-uninitialized warning when compiling DPDK with
GCC 4.9 + Link Time Optimization.
Signed-off-by: Dennis Marinus
---
lib/librte_table/rte_table_lpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_table/rte_table_lpm.c b/lib/librte_table/rte_table_lpm.c
index 59f87bb..cf92619 100644
--- a/lib/librte_table/rte_table_lpm.c
+++ b/lib/librte_table/rte_table_lpm.c
@@ -185,7 +185,7 @@ rte_table_lpm_entry_add(
struct rte_table_lpm_key *ip_prefix = (struct rte_table_lpm_key *) key;
uint32_t nht_pos, nht_pos0_valid;
int status;
- uint8_t nht_pos0;
+ uint8_t nht_pos0 = 0;
/* Check input parameters */
if (lpm == NULL) {
--
2.1.2.AMZN
[dpdk-dev] i40 on dpdk 1.7
Hi, We are currently using dpdk 1.7, and I've seen lots of patches for the i40 pmd adding features and bug fixes. How much functionality for the xl-710 vf exists in dpdk 1.7 Thanks Alex
[dpdk-dev] [PATCH] i40e: bug fix of compile error
The compile error will occur as below when set
'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'.
The changes is just to fix it.
lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir:
lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union has
no member named fd
lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl
[-Werror=unused-variable]
lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh
[-Werror=unused-variable]
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_rxtx.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 2d2ef04..95666fd 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -424,13 +424,9 @@ static inline uint64_t
i40e_rxd_build_fdir(volatile union i40e_rx_desc *rxdp, struct rte_mbuf *mb)
{
uint64_t flags = 0;
+#ifndef RTE_LIBRTE_I40E_16BYTE_RX_DESC
uint16_t flexbh, flexbl;
-#ifdef RTE_LIBRTE_I40E_16BYTE_RX_DESC
- mb->hash.fdir.hi =
- rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.fd);
- flags |= PKT_RX_FDIR_ID;
-#else
flexbh = (rte_le_to_cpu_32(rxdp->wb.qword2.ext_status) >>
I40E_RX_DESC_EXT_STATUS_FLEXBH_SHIFT) &
I40E_RX_DESC_EXT_STATUS_FLEXBH_MASK;
@@ -438,22 +434,28 @@ i40e_rxd_build_fdir(volatile union i40e_rx_desc *rxdp,
struct rte_mbuf *mb)
I40E_RX_DESC_EXT_STATUS_FLEXBL_SHIFT) &
I40E_RX_DESC_EXT_STATUS_FLEXBL_MASK;
-
if (flexbh == I40E_RX_DESC_EXT_STATUS_FLEXBH_FD_ID) {
mb->hash.fdir.hi =
rte_le_to_cpu_32(rxdp->wb.qword3.hi_dword.fd_id);
flags |= PKT_RX_FDIR_ID;
} else if (flexbh == I40E_RX_DESC_EXT_STATUS_FLEXBH_FLEX) {
mb->hash.fdir.hi =
-
rte_le_to_cpu_32(rxdp->wb.qword3.hi_dword.flex_bytes_hi);
+ rte_le_to_cpu_32(
+ rxdp->wb.qword3.hi_dword.flex_bytes_hi);
flags |= PKT_RX_FDIR_FLX;
}
+
if (flexbl == I40E_RX_DESC_EXT_STATUS_FLEXBL_FLEX) {
mb->hash.fdir.lo =
-
rte_le_to_cpu_32(rxdp->wb.qword3.lo_dword.flex_bytes_lo);
+ rte_le_to_cpu_32(
+ rxdp->wb.qword3.lo_dword.flex_bytes_lo);
flags |= PKT_RX_FDIR_FLX;
}
+#else
+ mb->hash.fdir.hi = rte_le_to_cpu_32(rxdp->wb.qword0.hi_dword.fd_id);
+ flags |= PKT_RX_FDIR_ID;
#endif
+
return flags;
}
static inline void
--
1.9.3
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 10:18:06AM -0500, Neil Horman wrote:
> On Mon, Dec 01, 2014 at 02:36:46PM +, Bruce Richardson wrote:
> > On Mon, Dec 01, 2014 at 09:25:44AM -0500, Neil Horman wrote:
> > > On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> > > > On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > > > > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > > > > Hi Bruce, Hi Neil,
> > > > > >
> > > > > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> > > > > > >> When compiling with clang, errors were being emitted due to
> > > > > > >> truncation
> > > > > > >> of values when assigning to the tx_offload_mask bit fields.
> > > > > > >>
> > > > > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error:
> > > > > > >> implicit truncation from 'int' to bitfield changes value from -1
> > > > > > >> to 127 [-Wbitfield-constant-conversion]
> > > > > > >> tx_offload_mask.l2_len = ~0;
> > > > > > >>
> > > > > > >> The fix proposed here is to define a static const value of the
> > > > > > >> same type
> > > > > > >> with all fields set to 1s, and use that instead of constants for
> > > > > > >> assigning to.
> > > > > > >>
> > > > > > >> Other options would be to explicitily define the suitable
> > > > > > >> constants that
> > > > > > >> would not truncate for each individual field e.g. 0x7f for
> > > > > > >> l2_len, 0x1FF
> > > > > > >> for l3_len, etc., but this solution here has the advantage that
> > > > > > >> it works
> > > > > > >> without any changes to values if the field sizes are ever
> > > > > > >> modified.
> > > > > > >>
> > > > > > >> Signed-off-by: Bruce Richardson
> > > > > > >> ---
> > > > > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29
> > > > > > >> +++--
> > > > > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > > > > >>
> > > > > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > >> index 8559ef6..4f71194 100644
> > > > > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> > > > > > >> volatile struct ixgbe_adv_tx_context_desc
> > > > > > >> *ctx_txd,
> > > > > > >> uint64_t ol_flags, union ixgbe_tx_offload
> > > > > > >> tx_offload)
> > > > > > >> {
> > > > > > >> +static const union ixgbe_tx_offload offload_allones = {
> > > > > > >> .data = ~0 };
> > > > > > > Do you want to make this a static data structure? If you make it
> > > > > > > a macro like
> > > > > > > this:
> > > > > > > #define ALLONES {.data = ~0}
> > > > > > > Then you save the extra data space in the .data area (not that
> > > > > > > its that much),
> > > > > > > and you can define it in a header file and use it in multiple c
> > > > > > > files (if you
> > > > > > > need to)
> > > > > >
> > > > > > I found that the following code works:
> > > > > >
> > > > > > tx_offload_mask.l2_len |= ~0;
> > > > > >
> > > > > > (note the '|=' instead of '=')
> > > > > >
> > > > > How exactly does this work? does the or operator imply some level of
> > > > > type
> > > > > promotion that the assignment doesn't to avoid the truncation?
> > > > > Neil
> > > > >
> > > >
> > > > For any aithmetic, and presumably logical, operation on two values, any
> > > > values
> > > > smaller than "int" are promoted to type int before the operation takes
> > > > place. I
> > > > believe the exact rules for this are in the C specs e.g. C99.
> > > >
> > > Yes, but I would have thought that assignment was included in the list of
> > > logical operations for that promotion to occur. The above change seems to
> > > suggest it isn't, which is why I'm asking. C99 specifies |= explicitly
> > > as a
> > > type of assignment operator (see 6.5.16 here:
> > > http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> > > )
> > >
> > > So I would presume that using = should work exactly the same as |= in
> > > terms of
> > > type promotion. We also don't get this warning on gcc, which concerns me
> > > that
> > > we might just be papering over a compiler problem here.
> > >
> > > Looking at the error, its complaining that we're truncating an int value
> > > to a
> > > bitfield (which we are), and that the resultant value is 127 rather that
> > > -1
> > > (which it would be if we actually intended to treat it as an integer
> > >
> > > Which I think is where the problem lies. That is to say we've typed the
> > > bitfields in ixgbe_tx_offload as uint64_t. I'm guessing gcc just
> > > promotes ~0 to
> > > an unsigned int during the assignment, and supresses the warning (unless
> > > you
> > > turn on -pedantic or some such), but clang does not. The correct
> > > solution I
> > > think here is to e
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 09:25:44AM -0500, Neil Horman wrote:
> On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> > On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > > Hi Bruce, Hi Neil,
> > > >
> > > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> > > > >> When compiling with clang, errors were being emitted due to
> > > > >> truncation
> > > > >> of values when assigning to the tx_offload_mask bit fields.
> > > > >>
> > > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error:
> > > > >> implicit truncation from 'int' to bitfield changes value from -1 to
> > > > >> 127 [-Wbitfield-constant-conversion]
> > > > >> tx_offload_mask.l2_len = ~0;
> > > > >>
> > > > >> The fix proposed here is to define a static const value of the same
> > > > >> type
> > > > >> with all fields set to 1s, and use that instead of constants for
> > > > >> assigning to.
> > > > >>
> > > > >> Other options would be to explicitily define the suitable constants
> > > > >> that
> > > > >> would not truncate for each individual field e.g. 0x7f for l2_len,
> > > > >> 0x1FF
> > > > >> for l3_len, etc., but this solution here has the advantage that it
> > > > >> works
> > > > >> without any changes to values if the field sizes are ever modified.
> > > > >>
> > > > >> Signed-off-by: Bruce Richardson
> > > > >> ---
> > > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
> > > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > > >>
> > > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > >> index 8559ef6..4f71194 100644
> > > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> > > > >> volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
> > > > >> uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
> > > > >> {
> > > > >> +static const union ixgbe_tx_offload offload_allones = { .data =
> > > > >> ~0 };
> > > > > Do you want to make this a static data structure? If you make it a
> > > > > macro like
> > > > > this:
> > > > > #define ALLONES {.data = ~0}
> > > > > Then you save the extra data space in the .data area (not that its
> > > > > that much),
> > > > > and you can define it in a header file and use it in multiple c files
> > > > > (if you
> > > > > need to)
> > > >
> > > > I found that the following code works:
> > > >
> > > > tx_offload_mask.l2_len |= ~0;
> > > >
> > > > (note the '|=' instead of '=')
> > > >
> > > How exactly does this work? does the or operator imply some level of type
> > > promotion that the assignment doesn't to avoid the truncation?
> > > Neil
> > >
> >
> > For any aithmetic, and presumably logical, operation on two values, any
> > values
> > smaller than "int" are promoted to type int before the operation takes
> > place. I
> > believe the exact rules for this are in the C specs e.g. C99.
> >
> Yes, but I would have thought that assignment was included in the list of
> logical operations for that promotion to occur. The above change seems to
> suggest it isn't, which is why I'm asking. C99 specifies |= explicitly as a
> type of assignment operator (see 6.5.16 here:
> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> )
>
> So I would presume that using = should work exactly the same as |= in terms of
> type promotion. We also don't get this warning on gcc, which concerns me that
> we might just be papering over a compiler problem here.
>
> Looking at the error, its complaining that we're truncating an int value to a
> bitfield (which we are), and that the resultant value is 127 rather that -1
> (which it would be if we actually intended to treat it as an integer
>
> Which I think is where the problem lies. That is to say we've typed the
> bitfields in ixgbe_tx_offload as uint64_t. I'm guessing gcc just promotes ~0
> to
> an unsigned int during the assignment, and supresses the warning (unless you
> turn on -pedantic or some such), but clang does not. The correct solution I
> think here is to either:
>
> 1) modify the bitfield types so that they are signed integers, thereby
> maintaining the resultant value of -1 after the assignment
>
> or
>
> 2) Modify the ~0 to be ~0UL, so that the clang compiler sees that the
> resultant
> value will be MAXLONG after the assignment
>
> I'd think operation 2 would be the better choice
> Neil
>
I'm not a compiler expert, but looking at it a bit more what I think is
happening is that we are simply changing the assignment from a constant one to
a computed one instead. With the constant assignment, the compiler can check
that
the assignment doesn't overflow, while with the co
[dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields
Hi lads, > -Original Message- > From: Liu, Jijiang > Sent: Monday, December 01, 2014 1:08 PM > To: Olivier MATZ; Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change > three fields > > > > > -Original Message- > > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > > Sent: Monday, December 1, 2014 8:28 PM > > To: Ananyev, Konstantin; Liu, Jijiang > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change > > three fields > > > > Hi Konstantin, > > > > On 12/01/2014 12:58 PM, Ananyev, Konstantin wrote: > > >> Ether/IP/UDP/vxlan/Ether/IP/UDP/xxx > > >> m->outer_l2_len = sizeof(ether) > > >> m->outer_l3_len = sizeof(ip) > > >> m->l2_len = sizeof(udp) + sizeof(vxlan) + sizeof(ether) > > > > > > I think it should be: > > > m->l2_len = sizeof(vxlan) + sizeof(ether) > > > > > > We don't need to add sizeof(udp) as we already say to the HW that I t > > > will be > > UDP TUNNELING vi the ol_flag: PKT_TX_UDP_TUNNEL_PKT. > > > > > >> m->l3_len = sizeof(ip) > > >> m->l4_len = sizeof(udp) > > > > I would agree if we had a m->outer_l4_len. Maybe we should add it to be > > coherent with lX_len fields? > > > > I think that to process the inner IP checksum, we should be able to use > > these 2 > > notations: > > > > Ether/IP/GRE/IP/UDP/xxx > > m->flags = OUTER_IP_CKSUM > > m->outer_l2_len = sizeof(ether) > > m->outer_l3_len = sizeof(ip) > > m->l2_len = sizeof(gre) > > m->l3_len = sizeof(ip) > > m->l4_len = sizeof(udp) > > > > Ether/IP/GRE/IP/UDP/xxx > > m->flags = IP_CKSUM > > /* sum of all outer_lX_len and l2_len from above: */ > > m->l2_len = sizeof(ether) + sizeof(ip) + sizeof(gre) > > m->l3_len = sizeof(ip) > > m->l4_len = sizeof(udp) > > > > So, in case of vxlan, I suggest that either we include the size of UDP in > > l2_len, or > > we add a outer_l4_len. What do you think? > I agree to include the size of UDP in l2_len, for VXLAN, the UDP header is a > part of VXLAN tunnelling header as the UDP destination > port indicate if a packet is VXLAN packet. Actually it is my bad. While looking at current implementation, I didn't realise that: ETHER_VXLAN_HLEN == (sizeof(struct udp_hdr) + sizeof(struct vxlan_hdr)). So yes you are right for VXLAN packet it should be: m->l2_len = sizeof(udp) + sizeof(vxlan) + sizeof(ether); Sorry for confusing everyone. Konstantin > > Maybe adding outer_l4_len makes more sense. > > > > > Regards, > > Olivier
[dpdk-dev] Avoid stripping vlan tag with I350 VF on a VM
How do I do this on PF? On my VM, isn't only VF interface is visible,
correct?
Thanks for your reply,
Shian-Tung
On Mon, Dec 1, 2014 at 12:17 PM, Zhu, Heqing wrote:
> Did you try to remove the VLAN strip on the PF side?
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shiantung Wong
> Sent: Monday, December 01, 2014 11:29 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Avoid stripping vlan tag with I350 VF on a VM
>
> My application running on a VM needs to deal with multiple VLANS on
> packets received over I350 using Virtual Function. But I always see the
> received packets without vlan tag.
> This is my setup:
> - host: 3.13.6-031306-generic
> - QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
> - guest: 2.6.32-358.el6.x86_64
> - dpdk: 1.6
>
> And this is how I set up in the VM:
> ---
> memset(&port_conf, 0, sizeof(port_conf));
> if (vlanCnt > 0)
> port_conf.rxmode.hw_vlan_filter = 1;
>
> port_conf.rxmode.jumbo_frame = 1;
> port_conf.rxmode.max_rx_pkt_len = 9018;
>
> ret = rte_eth_dev_configure(port, 1, 1, &port_conf);
> if (ret < 0) {
> rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
> ret=%d\n",
> (unsigned)port, ret);
> return -1;
> }
>
> for(i = 0; i < vlanCnt; i++) {
> ret = rte_eth_dev_vlan_filter(port, vlan[i], 1);
> if (ret < 0) {
> rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config
> port%u, vlan%d ret=%d\n",
> (unsigned)port, vlan[i], ret);
> return -1;
> }
> }
> -
>
> If I also try to explicitly disable the stripping with next, but get an
> error return -ENOSUP.
>
> ret = rte_eth_dev_set_vlan_strip_on_queue(port, 0, 0);
>
> I appreciate anyone can help. on how to set it up.
>
> Thanks,
> Shian Wong
>
[dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields
Hi Konstantin, On 12/01/2014 12:58 PM, Ananyev, Konstantin wrote: >> Ether/IP/UDP/vxlan/Ether/IP/UDP/xxx >> m->outer_l2_len = sizeof(ether) >> m->outer_l3_len = sizeof(ip) >> m->l2_len = sizeof(udp) + sizeof(vxlan) + sizeof(ether) > > I think it should be: > m->l2_len = sizeof(vxlan) + sizeof(ether) > > We don't need to add sizeof(udp) as we already say to the HW that I t will be > UDP TUNNELING vi the ol_flag: PKT_TX_UDP_TUNNEL_PKT. > >> m->l3_len = sizeof(ip) >> m->l4_len = sizeof(udp) I would agree if we had a m->outer_l4_len. Maybe we should add it to be coherent with lX_len fields? I think that to process the inner IP checksum, we should be able to use these 2 notations: Ether/IP/GRE/IP/UDP/xxx m->flags = OUTER_IP_CKSUM m->outer_l2_len = sizeof(ether) m->outer_l3_len = sizeof(ip) m->l2_len = sizeof(gre) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) Ether/IP/GRE/IP/UDP/xxx m->flags = IP_CKSUM /* sum of all outer_lX_len and l2_len from above: */ m->l2_len = sizeof(ether) + sizeof(ip) + sizeof(gre) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) So, in case of vxlan, I suggest that either we include the size of UDP in l2_len, or we add a outer_l4_len. What do you think? Maybe adding outer_l4_len makes more sense. Regards, Olivier
[dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields
> -Original Message- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > Sent: Monday, December 1, 2014 8:28 PM > To: Ananyev, Konstantin; Liu, Jijiang > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change > three fields > > Hi Konstantin, > > On 12/01/2014 12:58 PM, Ananyev, Konstantin wrote: > >> Ether/IP/UDP/vxlan/Ether/IP/UDP/xxx > >> m->outer_l2_len = sizeof(ether) > >> m->outer_l3_len = sizeof(ip) > >> m->l2_len = sizeof(udp) + sizeof(vxlan) + sizeof(ether) > > > > I think it should be: > > m->l2_len = sizeof(vxlan) + sizeof(ether) > > > > We don't need to add sizeof(udp) as we already say to the HW that I t will > > be > UDP TUNNELING vi the ol_flag: PKT_TX_UDP_TUNNEL_PKT. > > > >> m->l3_len = sizeof(ip) > >> m->l4_len = sizeof(udp) > > I would agree if we had a m->outer_l4_len. Maybe we should add it to be > coherent with lX_len fields? > > I think that to process the inner IP checksum, we should be able to use these > 2 > notations: > > Ether/IP/GRE/IP/UDP/xxx > m->flags = OUTER_IP_CKSUM > m->outer_l2_len = sizeof(ether) > m->outer_l3_len = sizeof(ip) > m->l2_len = sizeof(gre) > m->l3_len = sizeof(ip) > m->l4_len = sizeof(udp) > > Ether/IP/GRE/IP/UDP/xxx > m->flags = IP_CKSUM > /* sum of all outer_lX_len and l2_len from above: */ > m->l2_len = sizeof(ether) + sizeof(ip) + sizeof(gre) > m->l3_len = sizeof(ip) > m->l4_len = sizeof(udp) > > So, in case of vxlan, I suggest that either we include the size of UDP in > l2_len, or > we add a outer_l4_len. What do you think? I agree to include the size of UDP in l2_len, for VXLAN, the UDP header is a part of VXLAN tunneling header as the UDP destination port indicate if a packet is VXLAN packet. > Maybe adding outer_l4_len makes more sense. > > Regards, > Olivier
[dpdk-dev] [PATCH v5 4/4] doc: Various document fixes in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 4/4] doc: Various document fixes in testpmd UG > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v5 3/4] doc: Moved commands in testpmd UG to match testpmd command help order
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 3/4] doc: Moved commands in testpmd UG to match > testpmd > command help order > > Moved commands in testpmd UG to set queue rates to match order in testpmd > command help. > > Created new section "Filters" to match that same section in testpmd UG, and > moved all commands > related to it there. > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v5 2/4] doc: Corrected info for tx_checksum set mask function, in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 2/4] doc: Corrected info for tx_checksum set > mask function, in > testpmd UG > > tx_checksum set function does not use bitmask anymore, but strings > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v5 1/4] doc: Added new commands in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 1/4] doc: Added new commands in testpmd UG > > Added info in testpmd functions section for the following commands: > > - tunnel_filter add > - tunnel_filter rm > - rx_vxlan_port add > - rx_vxlan_port rm > - port stop/start queue > - set port mac address filter (for VF) > - tx_checksum set > - tso set > - tso show > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] enicpd: Warnings and one error when built using clang compiler
> > This patch fixes the warnings and error reported by clang compiler on Linux. > > > > Reported-by: Bruce Richardson > > Signed-off-by: Sujith Sankar > > This PMD now compiles up with clang on FreeBSD. The patch seems rather large > though, > are all these changes necessary for clang compilation? > > On the basis that this fixes the issue though: > > Acked-by: Bruce Richardson Applied Thanks -- Thomas
[dpdk-dev] [PATCH] ixgbe: change assignation of bitfields to fix clang compilation
> > Commit 1224decaa44b3dba58e0a524fd0383969929c575 changed the way > > the bitfields are assigned in ixgbe, example: > > > > tx_offload_mask.l2_len = ~0; > > > > This result in a compilation error with clang: > > > >error: implicit truncation from 'int' to bitfield > > changes value from -1 to 127 [-Werror,-Wbitfield-constant-conversion] > > > > Replacing the '=' with a '|=' fixes the issue. > > > > Signed-off-by: Olivier Matz > > Acked-by: Bruce Richardson Applied Thanks -- Thomas
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 04:44:39PM +, Bruce Richardson wrote:
> On Mon, Dec 01, 2014 at 11:35:28AM -0500, Neil Horman wrote:
> > On Mon, Dec 01, 2014 at 03:24:32PM +, Bruce Richardson wrote:
> > > On Mon, Dec 01, 2014 at 10:18:06AM -0500, Neil Horman wrote:
> > > > On Mon, Dec 01, 2014 at 02:36:46PM +, Bruce Richardson wrote:
> > > > > On Mon, Dec 01, 2014 at 09:25:44AM -0500, Neil Horman wrote:
> > > > > > On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> > > > > > > On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > > > > > > > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > > > > > > > Hi Bruce, Hi Neil,
> > > > > > > > >
> > > > > > > > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > > > > > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson
> > > > > > > > > > wrote:
> > > > > > > > > >> When compiling with clang, errors were being emitted due
> > > > > > > > > >> to truncation
> > > > > > > > > >> of values when assigning to the tx_offload_mask bit fields.
> > > > > > > > > >>
> > > > > > > > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal
> > > > > > > > > >> error: implicit truncation from 'int' to bitfield changes
> > > > > > > > > >> value from -1 to 127 [-Wbitfield-constant-conversion]
> > > > > > > > > >>tx_offload_mask.l2_len = ~0;
> > > > > > > > > >>
> > > > > > > > > >> The fix proposed here is to define a static const value of
> > > > > > > > > >> the same type
> > > > > > > > > >> with all fields set to 1s, and use that instead of
> > > > > > > > > >> constants for assigning to.
> > > > > > > > > >>
> > > > > > > > > >> Other options would be to explicitily define the suitable
> > > > > > > > > >> constants that
> > > > > > > > > >> would not truncate for each individual field e.g. 0x7f for
> > > > > > > > > >> l2_len, 0x1FF
> > > > > > > > > >> for l3_len, etc., but this solution here has the advantage
> > > > > > > > > >> that it works
> > > > > > > > > >> without any changes to values if the field sizes are ever
> > > > > > > > > >> modified.
> > > > > > > > > >>
> > > > > > > > > >> Signed-off-by: Bruce Richardson > > > > > > > > >> intel.com>
> > > > > > > > > >> ---
> > > > > > > > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29
> > > > > > > > > >> +++--
> > > > > > > > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > > > > > > > >>
> > > > > > > > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > > >> index 8559ef6..4f71194 100644
> > > > > > > > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct
> > > > > > > > > >> igb_tx_queue* txq,
> > > > > > > > > >>volatile struct ixgbe_adv_tx_context_desc
> > > > > > > > > >> *ctx_txd,
> > > > > > > > > >>uint64_t ol_flags, union ixgbe_tx_offload
> > > > > > > > > >> tx_offload)
> > > > > > > > > >> {
> > > > > > > > > >> + static const union ixgbe_tx_offload offload_allones = {
> > > > > > > > > >> .data = ~0 };
> > > > > > > > > > Do you want to make this a static data structure? If you
> > > > > > > > > > make it a macro like
> > > > > > > > > > this:
> > > > > > > > > > #define ALLONES {.data = ~0}
> > > > > > > > > > Then you save the extra data space in the .data area (not
> > > > > > > > > > that its that much),
> > > > > > > > > > and you can define it in a header file and use it in
> > > > > > > > > > multiple c files (if you
> > > > > > > > > > need to)
> > > > > > > > >
> > > > > > > > > I found that the following code works:
> > > > > > > > >
> > > > > > > > > tx_offload_mask.l2_len |= ~0;
> > > > > > > > >
> > > > > > > > > (note the '|=' instead of '=')
> > > > > > > > >
> > > > > > > > How exactly does this work? does the or operator imply some
> > > > > > > > level of type
> > > > > > > > promotion that the assignment doesn't to avoid the truncation?
> > > > > > > > Neil
> > > > > > > >
> > > > > > >
> > > > > > > For any aithmetic, and presumably logical, operation on two
> > > > > > > values, any values
> > > > > > > smaller than "int" are promoted to type int before the operation
> > > > > > > takes place. I
> > > > > > > believe the exact rules for this are in the C specs e.g. C99.
> > > > > > >
> > > > > > Yes, but I would have thought that assignment was included in the
> > > > > > list of
> > > > > > logical operations for that promotion to occur. The above change
> > > > > > seems to
> > > > > > suggest it isn't, which is why I'm asking. C99 specifies |=
> > > > > > explicitly as a
> > > > > > type of assignment operator (see 6.5.16 here:
> > > > > > http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> > > > > > )
> > > > > >
> > > > > > So I would presume that using = should work exactly the same as |=
[dpdk-dev] [PATCH] i40e: bug fix of compile error
2014-12-01 15:33, Helin Zhang: > The compile error will occur as below when set > 'RTE_LIBRTE_I40E_16BYTE_RX_DESC=y'. > The changes is just to fix it. > > lib/librte_pmd_i40e/i40e_rxtx.c: In function i40e_rxd_build_fdir: > lib/librte_pmd_i40e/i40e_rxtx.c:431:28: error: volatile union has > no member named fd > lib/librte_pmd_i40e/i40e_rxtx.c:427:19: error: unused variable flexbl > [-Werror=unused-variable] > lib/librte_pmd_i40e/i40e_rxtx.c:427:11: error: unused variable flexbh > [-Werror=unused-variable] It would be nice to reference the commit which introduced the error and explain it a bit. > - > rte_le_to_cpu_32(rxdp->wb.qword3.hi_dword.flex_bytes_hi); > + rte_le_to_cpu_32( > + rxdp->wb.qword3.hi_dword.flex_bytes_hi); [...] > - > rte_le_to_cpu_32(rxdp->wb.qword3.lo_dword.flex_bytes_lo); > + rte_le_to_cpu_32( > + rxdp->wb.qword3.lo_dword.flex_bytes_lo); Why are you wrapping these lines (with wrong indentation)? It makes the fix confuse. -- Thomas
[dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields
> -Original Message- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > Sent: Monday, December 01, 2014 9:52 AM > To: Liu, Jijiang; Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change > three fields > > Hi Jijiang, > > On 12/01/2014 03:30 AM, Liu, Jijiang wrote: > >> After another thought, I think that the way you proposed is a better one. > >> I gives us more flexibility: > >> let's say for now we'll keep both l2_len and outer_l2_len as 7 bit fields, > >> and upper > >> layer would have to: > >> mb->l2_len = eth_hdr_in + vxlan_hdr; > > > > A question, how to fill the mb->l2_len for IP in IP, IP in GRE tunneling > > packet that is no inner L2 header? > > What is the rule? > > Or you think it should be mb->l2_len = 0 + l4_tun_len; ?? I think it should be: l2_len = 0 + l4_tun_len; >From your patch: l4_tunnel_len = l4_tun_len + l2_len; > > We could have the following rule: > - the l2_len starts after the end of outer_l2_len + outer_l3_len (if > they are not 0) I think it should start after the outer_l4_hdr. I.e. right now we don't include udp header length into it. > - l2_len is the length of all headers up to the first ip or ipv6 > header Yes, same thought here. > > Examples: > > Ether/IP/UDP/xxx > m->outer_l2_len = 0 > m->outer_l3_len = 0 > m->l2_len = sizeof(ether) > m->l3_len = sizeof(ip) > m->l4_len = sizeof(udp) > > Ether/IP/IP/UDP/xxx > m->outer_l2_len = sizeof(ether) > m->outer_l3_len = sizeof(ip) > m->l2_len = 0 > m->l3_len = sizeof(ip) > m->l4_len = sizeof(udp) > > Ether/IP/GRE/IP/UDP/xxx > m->outer_l2_len = sizeof(ether) > m->outer_l3_len = sizeof(ip) > m->l2_len = sizeof(gre) > m->l3_len = sizeof(ip) > m->l4_len = sizeof(udp) > > Ether/IP/UDP/vxlan/Ether/IP/UDP/xxx > m->outer_l2_len = sizeof(ether) > m->outer_l3_len = sizeof(ip) > m->l2_len = sizeof(udp) + sizeof(vxlan) + sizeof(ether) I think it should be: m->l2_len = sizeof(vxlan) + sizeof(ether) We don't need to add sizeof(udp) as we already say to the HW that I t will be UDP TUNNELING vi the ol_flag: PKT_TX_UDP_TUNNEL_PKT. > m->l3_len = sizeof(ip) > m->l4_len = sizeof(udp) > > Regards, > Olivier
[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT
Hi Tim, Could I explain port hotplug function at next conference call? For this explanation, I've prepared slides. could I send a PDF to this ML? That slides describe what is the function, how it works and what is current progress. And it's under 100KB. Regards, Tetsuya (2014/11/22 1:08), O'driscoll, Tim wrote: > We're going to hold our next community call on Tuesday 2nd December. This > time, we're going to try a time that's more suitable for participants in > Asia, so we're going to hold it at 8:00 AM GMT. The meeting time in a variety > of timezones is included below. > > Generally, GoToMeeting worked well last time, although there was a limitation > that Neil was unable to present slides as he joined from a Linux system. > We'll stick with GoToMeeting again this time as we don't yet have a better > solution. Details for joining the GoToMeeting session are included below. > > I'll record the session again and post the video to YouTube afterwards for > anybody who can't make it. This seemed to work well last time, and as Kevin > pointed out, the audio quality on the recording is good. > > For the agenda, we'd like to discuss the following: > ? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a > lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can > join us to describe his work on this. > ? DPDK Test Suite. We hope to announce the release of this next week. > Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe the > functionality and benefits of this. > > > Meeting Time: > Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC > Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour > Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours > Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3 hours > New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST > UTC+5:30 hours > Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at 4:00:00 > PM CST UTC+8 hours > Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours > San Francisco (U.S.A. - California) Midnight between Monday, December 1, 2014 > and Tuesday, December 2, 2014 PST UTC-8 hours > Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST UTC-7 > hours > New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM EST > UTC-5 hours > Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST UTC-5 > hours > Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00 > > > GoToMeeting Details: > To join, follow the meeting link: > https://global.gotomeeting.com/join/772753069. This will start the > GoToMeeting web viewer. You then have two options for audio: > > 1. To use your computer's audio via a headset, you need to switch to the > desktop version of GoToMeeting. You can do this by clicking the GoToMeeting > icon on the top right hand side of the web viewer, and then selecting "Switch > to the desktop version". The desktop version will need to download and > install, so if you plan to use this you may want to get it set up in advance. > Once it starts, under the Audio section, you can select "Mic & Speakers". The > desktop version is only available for Windows and Mac, so if you're using > Linux then you need to use option 2 below. > > 2. You can join using a phone via one of the numbers listed below. The Access > Code is 772-753-069. You'll also be asked for an Audio PIN, which is > accessible by clicking the phone icon in the GoToMeeting web viewer after > you've joined the meeting. > ? Australia (Long distance): +61 2 9091 7601 > ? Austria (Long distance): +43 (0) 7 2088 1036 > ? Belgium (Long distance): +32 (0) 28 08 4345 > ? Canada (Long distance): +1 (647) 497-9372 > ? Denmark (Long distance): +45 (0) 69 91 89 24 > ? Finland (Long distance): +358 (0) 942 45 0382 > ? France (Long distance): +33 (0) 170 950 586 > ? Germany (Long distance): +49 (0) 692 5736 7206 > ? Ireland (Long distance): +353 (0) 15 255 598 > ? Italy (Long distance): +39 0 694 80 31 28 > ? Netherlands (Long distance): +31 (0) 208 084 055 > ? New Zealand (Long distance): +64 (0) 4 974 7243 > ? Norway (Long distance): +47 23 96 01 18 > ? Spain (Long distance): +34 932 20 0506 > ? Sweden (Long distance): +46 (0) 852 500 182 > ? Switzerland (Long distance): +41 (0) 435 0824 78 > ? United Kingdom (Long distance): +44 (0) 330 221 0098 > ? United States (Long distance): +1 (626) 521-0013 > Access Code 772-753-069. > > Info on downloading the desktop app is available at: > http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title=Download%7D > Info on the web viewer is available at: > http://support.citrixonline.com/en_US/GoToMeeting/help_files/GTM130019?title=Web+Viewer+FAQs > > > Thanks, > Tim
[dpdk-dev] [PATCH] kni: create KNI interface in current network namespace
Le 01/12/2014 06:45, Hemant at freescale.com a ?crit : >> 2014-11-21 12:10, Takayuki Usui: >>> With this patch, KNI interface (e.g. vEth0) is created in the network >>> namespace where the DPDK application is running. >>> Otherwise, all interfaces are created in the default namespace in the >>> host. >>> >>> Signed-off-by: Takayuki Usui >>> --- >>> lib/librte_eal/linuxapp/kni/kni_misc.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c >>> b/lib/librte_eal/linuxapp/kni/kni_misc.c >>> index ba6..f4a9965 100644 >>> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c >>> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c >>> @@ -354,6 +354,8 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned >> long ioctl_param) >>> return -EBUSY; >>> } >>> >>> + dev_net_set(net_dev, get_net_ns_by_pid(current->pid)); >>> + > > Another way to get it done is by the following. It will be init_net for the > root container. > > #ifdef CONFIG_NET_NS > net_dev->nd_net = current->nsproxy->net_ns; > #endif No. It's always better to use existing helpers, it hides this kind of ifdef and more importantly, it do the right things (call release_net()/hold_net())! Reimplemented helpers is error prone.
[dpdk-dev] [PATCH v5 4/4] doc: Various document fixes in testpmd UG
Signed-off-by: Pablo de Lara --- doc/guides/testpmd_app_ug/testpmd_funcs.rst |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 65d3168..be935c2 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -162,10 +162,12 @@ size is used to indicate the hardware supported reta size show port rss-hash ~~ -Display the RSS hash functions and RSS hash key of port (port_id). +Display the RSS hash functions and RSS hash key of a port: -show port (port_id) rss-hash [key] clear port -~ +show port (port_id) rss-hash [key] + +clear port +~~ Clear the port statistics for a given port or for all ports: -- 1.7.4.1
[dpdk-dev] [PATCH v5 3/4] doc: Moved commands in testpmd UG to match testpmd command help order
Moved commands in testpmd UG to set queue rates to match order in testpmd command help. Created new section "Filters" to match that same section in testpmd UG, and moved all commands related to it there. Signed-off-by: Pablo de Lara --- doc/guides/testpmd_app_ug/testpmd_funcs.rst | 1041 ++- 1 files changed, 523 insertions(+), 518 deletions(-) diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 975929e..65d3168 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -444,20 +444,6 @@ Remove a VLAN ID, from the set of VLAN identifiers filtered for VF(s) for port I rx_vlan rm (vlan_id) port (port_id) vf (vf_mask) -tx_rate (for Queue) -~~~ - -Set TX rate limitation for queue of a port ID: - -set port (port_id) queue (queue_id) rate (rate_value) - -tx_rate (for VF) - - -Set TX rate limitation for queues in VF of a port ID: - -set port (port_id) vf (vf_id) rate (rate_value) queue_mask (queue_mask) - rx_vlan set tpid @@ -717,6 +703,20 @@ The available receive modes are: * MPE: accepts all multicast packets +set port - tx_rate (for Queue) +~~ + +Set TX rate limitation for queue of a port ID: + +set port (port_id) queue (queue_id) rate (rate_value) + +set port - tx_rate (for VF) +~~~ + +Set TX rate limitation for queues in VF of a port ID: + +set port (port_id) vf (vf_id) rate (rate_value) queue_mask (queue_mask) + set port - mirror rule ~~ @@ -783,903 +783,908 @@ Show the bypass configuration for a bypass enabled NIC using the lowest port on show bypass config (port_id) -add_ethertype_filter - +set link up +~~~ -Add a L2 Ethertype filter, which identify packets by their L2 Ethertype mainly assign them to a receive queue. +Set link up for a port. -add_ethertype_filter (port_id) ethertype (eth_value) priority (enable|disable) (pri_value) queue (queue_id) index (idx) +set link-up port (port id) -The available information parameters are: +set link down +~ -* port_id: the port which the Ethertype filter assigned on. +Set link down for a port. -* eth_value: the EtherType value want to match, -for example 0x0806 for ARP packet. 0x0800 (IPv4) and 0x86DD (IPv6) are invalid. +set link-down port (port id) -* enable: user priority participates in the match. +Port Functions +-- -* disable: user priority doesn't participate in the match. +The following sections show functions for configuring ports. -* pri_value: user priority value that want to match. +.. note:: -* queue_id : The receive queue associated with this EtherType filter +Port configuration changes only become active when forwarding is started/restarted. -* index: the index of this EtherType filter +port start +~~ -Example: +Start all ports or a specific port: -.. code-block:: console +port start (port_id|all) -testpmd> add_ethertype_filter 0 ethertype 0x0806 priority disable 0 queue 3 index 0 -Assign ARP packet to receive queue 3 +port stop +~ -remove_ethertype_filter -~~~ +Stop all ports or a specific port: -Remove a L2 Ethertype filter +port stop (port_id|all) -remove_ethertype_filter (port_id) index (idx) +port close +~~ -get_ethertype_filter - +Close all ports or a specific port: -Get and display a L2 Ethertype filter +port close (port_id|all) -get_ethertype_filter (port_id) index (idx) +port start/stop queue +~ -Example: +Start/stop a rx/tx queue on a specific port: -.. code-block:: console +port (port_id) (rxq|txq) (queue_id) (start|stop) -testpmd> get_ethertype_filter 0 index 0 +Only take effect when port is started. -filter[0]: -ethertype: 0x0806 -priority: disable, 0 -queue: 3 +port config - speed +~~~ -add_2tuple_filter -~ +Set the speed and duplex mode for all ports or a specific port: -Add a 2-tuple filter, -which identify packets by specific protocol and destination TCP/UDP port -and forwards packets into one of the receive queues. +port config (port_id|all) speed (10|100|1000|1|auto) duplex (half|full|auto) -add_2tuple_filter (port_id) protocol (pro_value) (pro_mask) dst_port (port_value) (port_mask) -flags (flg_value) priority (prio_value) queue (queue_id) index (idx) +port config - queues/descriptors + -The available information parameters are: +Set number of queues/descriptors for rxq, txq, rxd and txd: -* port_id: the port which the 2-tuple filter assigned on. +port config all (rxq|txq|rxd|txd) (value) -* pro_value: IP L4 protocol +This is equivalent to the --rxq, --txq, --rxd and --txd command-line options. -* pro_mask: protocol participates in the match or not, 1 mean
[dpdk-dev] [PATCH v5 2/4] doc: Corrected info for tx_checksum set mask function, in testpmd UG
tx_checksum set function does not use bitmask anymore, but strings Signed-off-by: Pablo de Lara --- doc/guides/testpmd_app_ug/testpmd_funcs.rst | 21 - 1 files changed, 8 insertions(+), 13 deletions(-) diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index c010577..975929e 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -516,22 +516,17 @@ Disable hardware insertion of a VLAN header in packets sent on a port: tx_vlan reset (port_id) -tx_checksum set mask - - -Enable hardware insertion of checksum offload with a 4-bit mask, 0x0 - 0xF, in packets sent on a port: - -tx_checksum set (mask) (port_id) - -The bits in the mask are: - -bit 0 - if set insert ip checksum offload +tx_checksum set +~~~ -bit 1 - if set insert udp checksum offload +Select hardware or software calculation of the checksum when +transmitting a packet using the csum forward engine: -bit 2 - if set insert tcp checksum offload +tx_cksum set (ip|udp|tcp|sctp|vxlan) -bit 3 - if set insert sctp checksum offload +ip|udp|tcp|sctp always concern the inner layer. +vxlan concerns the outer IP and UDP layer (in case the packet +is recognized as a vxlan packet by the forward engine) .. note:: -- 1.7.4.1
[dpdk-dev] [PATCH v5 1/4] doc: Added new commands in testpmd UG
Added info in testpmd functions section for the following commands: - tunnel_filter add - tunnel_filter rm - rx_vxlan_port add - rx_vxlan_port rm - port stop/start queue - set port mac address filter (for VF) - tx_checksum set - tso set - tso show Signed-off-by: Pablo de Lara --- doc/guides/testpmd_app_ug/testpmd_funcs.rst | 79 +++ 1 files changed, 79 insertions(+), 0 deletions(-) diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 5e62ff9..c010577 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -150,6 +150,15 @@ For example: filter on qinq(extend) off +show port rss reta +~~ + +Display the rss redirection table entry indicated by masks on port X: + +show port (port_id) rss reta (size) (mask0, mask1...) + +size is used to indicate the hardware supported reta size + show port rss-hash ~~ @@ -456,6 +465,36 @@ Set the outer VLAN TPID for packet filtering on a port: rx_vlan set tpid (value) (port_id) +tunnel_filter add +~ + +Add a tunnel filter on a port: + +tunnel_filter add (port_id) (outer_mac) (inner_mac) (ip_addr) (inner_vlan) + (tunnel_type) (filter_type) (tenant_id) (queue_id) + +tunnel_filter remove + + +Remove a tunnel filter on a port: + +tunnel_filter rm (port_id) (outer_mac) (inner_mac) (ip_addr) (inner_vlan) + (tunnel_type) (filter_type) (tenant_id) (queue_id) + +rx_vxlan_port add +~ + +Add an UDP port for VXLAN packet filter on a port: + +rx_vxlan_port add (udp_port) (port_id) + +rx_vxlan_port remove + + +Remove an UDP port for VXLAN packet filter on a port: + +rx_vxlan_port rm (udp_port) (port_id) + tx_vlan set ~~~ @@ -498,6 +537,29 @@ bit 3 - if set insert sctp checksum offload Check the NIC Datasheet for hardware limits. +tx_checksum show + + +Display tx checksum offload configuration: + +tx_checksum show (port_id) + +tso set +~~~ + +Enable TCP Segmentation Offload in csum forward engine: + +tso set (segsize) (port_id) + +.. note:: + Please check the NIC datasheet for HW limits + +tso show + + +Display the status of TCP Segmentation Offload: + +tso show (port_id) set fwd ~~~ @@ -635,6 +697,14 @@ Set VF receive/transmit from a port: set port (port_id) vf (vf_id) (rx|tx) (on|off) +set port - mac address filter (for VF) +~~ + +Add/Remove unicast or multicast MAC addr filter for a VF: + +set port (port_id) vf (vf_id) (mac_addr) + (exact-mac|exact-mac-vlan|hashmac|hashmac-vlan) (on|off) + set port - rx mode(for VF) ~~ @@ -1061,6 +1131,15 @@ Close all ports or a specific port: port close (port_id|all) +port start/stop queue +~ + +Start/stop a rx/tx queue on a specific port: + +port (port_id) (rxq|txq) (queue_id) (start|stop) + +Only take effect when port is started. + port config - speed ~~~ -- 1.7.4.1
[dpdk-dev] [PATCH v5 0/4] Updated testpmd UG due to latest changes in the app
TestPMD app has been added new commands, which should be reflected in the user guide. Also, this patchset fixes several typos and changes the location of the description of some commands. Changes in v5: Removed trailing whitespaces Changes in v4: Fixed wrong patchset title Changes in v3: Added new missing existing command "show port rss reta" Added new commands from TSO support patchset Modified info for command "tx_cksum set" command Changes in v2: Title underline in added commands was too short. Pablo de Lara (4): doc: Added new commands in testpmd UG doc: Corrected info for tx_checksum set mask function, in testpmd UG doc: Moved commands in testpmd UG to match testpmd command help order doc: Various document fixes in testpmd UG doc/guides/testpmd_app_ug/testpmd_funcs.rst | 1127 ++- 1 files changed, 604 insertions(+), 523 deletions(-) -- 1.7.4.1
[dpdk-dev] [PATCH 2/2] testpmd: fix macro check for little endian
Compiling with clang on FreeBSD gave a compilation error: app/test-pmd/csumonly.c:84:5: fatal error: '__BYTE_ORDER' is not defined, evaluates to 0 [-Wundef] Querying the preprocessor defines show both the define and value used are incorrect. $ clang -dM -E - < /dev/null | grep BYTE \#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ Changing the check to __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ then resolves the issue. Signed-off-by: Bruce Richardson --- app/test-pmd/csumonly.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c index d8c080a..6f43761 100644 --- a/app/test-pmd/csumonly.c +++ b/app/test-pmd/csumonly.c @@ -81,7 +81,7 @@ /* we cannot use htons() from arpa/inet.h due to name conflicts, and we * cannot use rte_cpu_to_be_16() on a constant in a switch/case */ -#if __BYTE_ORDER == __LITTLE_ENDIAN +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ #define _htons(x) ((uint16_t)x) & 0x00ffU) << 8) | (((x) & 0xff00U) >> 8))) #else #define _htons(x) (x) -- 2.1.0
[dpdk-dev] [PATCH 1/2] testpmd: fix out-of-range compiler error
The definition value for IPPROTO_DIVERT protocol uses a value
which is out of range of the uint8_t type, giving clang compiler
errors on FreeBSD.
app/test-pmd/icmpecho.c:231:7: fatal error: overflow converting case value to
switch condition type (258 to 2) [-Wswitch]
case IPPROTO_DIVERT: /**< divert pseudo-protocol */
This is fixed by having the code to return the protocol name
use the uint16_t type for the protocol value input.
Signed-off-by: Bruce Richardson
---
app/test-pmd/icmpecho.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-pmd/icmpecho.c b/app/test-pmd/icmpecho.c
index c25a54b..08ea01d 100644
--- a/app/test-pmd/icmpecho.c
+++ b/app/test-pmd/icmpecho.c
@@ -88,7 +88,7 @@ arp_op_name(uint16_t arp_op)
}
static const char *
-ip_proto_name(uint8_t ip_proto)
+ip_proto_name(uint16_t ip_proto)
{
static const char * ip_proto_names[] = {
"IP6HOPOPTS", /**< IP6 hop-by-hop options */
--
2.1.0
[dpdk-dev] [PATCH 0/2] Fix clang compilation on FreeBSD
This patch contains fixes for two compilation errors that occur with clang on FreeBSD. These errors are not seen when compiling with clang on Fedora Linux. Bruce Richardson (2): testpmd: fix out-of-range compiler error testpmd: fix macro check for little endian app/test-pmd/csumonly.c | 2 +- app/test-pmd/icmpecho.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.1.0
[dpdk-dev] [RFC] Clang errors with bit fields and setting value of ~0.
Hi Keith, On 11/29/2014 05:33 PM, Keith Wiles wrote: > error: implicit truncation from 'int' to bitfield > changes value from -1 to 127 [-Werror,-Wbitfield-constant-conversion] > tx_offload_mask.l2_len = ~0; > Converted to use correct bit values > tx_offload_mask.l2_len = 0x7f; > > Signer-off-by: Keith Wiles > --- > lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 28 ++-- > 1 file changed, 14 insertions(+), 14 deletions(-) > I just submitted a patch that fixes the same issue without having to know the size of the bitfield. http://dpdk.org/ml/archives/dev/2014-December/009112.html Regards, Olivier
[dpdk-dev] [PATCH] ixgbe: change assignation of bitfields to fix clang compilation
Commit 1224decaa44b3dba58e0a524fd0383969929c575 changed the way
the bitfields are assigned in ixgbe, example:
tx_offload_mask.l2_len = ~0;
This result in a compilation error with clang:
error: implicit truncation from 'int' to bitfield
changes value from -1 to 127 [-Werror,-Wbitfield-constant-conversion]
Replacing the '=' with a '|=' fixes the issue.
Signed-off-by: Olivier Matz
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 8559ef6..5c36bff 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -381,7 +381,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
mss_l4len_idx |= (ctx_idx << IXGBE_ADVTXD_IDX_SHIFT);
if (ol_flags & PKT_TX_VLAN_PKT) {
- tx_offload_mask.vlan_tci = ~0;
+ tx_offload_mask.vlan_tci |= ~0;
}
/* check if TCP segmentation required for this packet */
@@ -391,17 +391,17 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
IXGBE_ADVTXD_TUCMD_L4T_TCP |
IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
- tx_offload_mask.l2_len = ~0;
- tx_offload_mask.l3_len = ~0;
- tx_offload_mask.l4_len = ~0;
- tx_offload_mask.tso_segsz = ~0;
+ tx_offload_mask.l2_len |= ~0;
+ tx_offload_mask.l3_len |= ~0;
+ tx_offload_mask.l4_len |= ~0;
+ tx_offload_mask.tso_segsz |= ~0;
mss_l4len_idx |= tx_offload.tso_segsz << IXGBE_ADVTXD_MSS_SHIFT;
mss_l4len_idx |= tx_offload.l4_len << IXGBE_ADVTXD_L4LEN_SHIFT;
} else { /* no TSO, check if hardware checksum is needed */
if (ol_flags & PKT_TX_IP_CKSUM) {
type_tucmd_mlhl = IXGBE_ADVTXD_TUCMD_IPV4;
- tx_offload_mask.l2_len = ~0;
- tx_offload_mask.l3_len = ~0;
+ tx_offload_mask.l2_len |= ~0;
+ tx_offload_mask.l3_len |= ~0;
}
switch (ol_flags & PKT_TX_L4_MASK) {
@@ -409,23 +409,23 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_UDP |
IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
mss_l4len_idx |= sizeof(struct udp_hdr) <<
IXGBE_ADVTXD_L4LEN_SHIFT;
- tx_offload_mask.l2_len = ~0;
- tx_offload_mask.l3_len = ~0;
+ tx_offload_mask.l2_len |= ~0;
+ tx_offload_mask.l3_len |= ~0;
break;
case PKT_TX_TCP_CKSUM:
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_TCP |
IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
mss_l4len_idx |= sizeof(struct tcp_hdr) <<
IXGBE_ADVTXD_L4LEN_SHIFT;
- tx_offload_mask.l2_len = ~0;
- tx_offload_mask.l3_len = ~0;
- tx_offload_mask.l4_len = ~0;
+ tx_offload_mask.l2_len |= ~0;
+ tx_offload_mask.l3_len |= ~0;
+ tx_offload_mask.l4_len |= ~0;
break;
case PKT_TX_SCTP_CKSUM:
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_SCTP |
IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
mss_l4len_idx |= sizeof(struct sctp_hdr) <<
IXGBE_ADVTXD_L4LEN_SHIFT;
- tx_offload_mask.l2_len = ~0;
- tx_offload_mask.l3_len = ~0;
+ tx_offload_mask.l2_len |= ~0;
+ tx_offload_mask.l3_len |= ~0;
break;
default:
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_RSV |
--
2.1.0
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 03:24:32PM +, Bruce Richardson wrote:
> On Mon, Dec 01, 2014 at 10:18:06AM -0500, Neil Horman wrote:
> > On Mon, Dec 01, 2014 at 02:36:46PM +, Bruce Richardson wrote:
> > > On Mon, Dec 01, 2014 at 09:25:44AM -0500, Neil Horman wrote:
> > > > On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> > > > > On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > > > > > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > > > > > Hi Bruce, Hi Neil,
> > > > > > >
> > > > > > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > > > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson
> > > > > > > > wrote:
> > > > > > > >> When compiling with clang, errors were being emitted due to
> > > > > > > >> truncation
> > > > > > > >> of values when assigning to the tx_offload_mask bit fields.
> > > > > > > >>
> > > > > > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal
> > > > > > > >> error: implicit truncation from 'int' to bitfield changes
> > > > > > > >> value from -1 to 127 [-Wbitfield-constant-conversion]
> > > > > > > >>tx_offload_mask.l2_len = ~0;
> > > > > > > >>
> > > > > > > >> The fix proposed here is to define a static const value of the
> > > > > > > >> same type
> > > > > > > >> with all fields set to 1s, and use that instead of constants
> > > > > > > >> for assigning to.
> > > > > > > >>
> > > > > > > >> Other options would be to explicitily define the suitable
> > > > > > > >> constants that
> > > > > > > >> would not truncate for each individual field e.g. 0x7f for
> > > > > > > >> l2_len, 0x1FF
> > > > > > > >> for l3_len, etc., but this solution here has the advantage
> > > > > > > >> that it works
> > > > > > > >> without any changes to values if the field sizes are ever
> > > > > > > >> modified.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Bruce Richardson
> > > > > > > >> ---
> > > > > > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29
> > > > > > > >> +++--
> > > > > > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > > > > > >>
> > > > > > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > >> index 8559ef6..4f71194 100644
> > > > > > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue*
> > > > > > > >> txq,
> > > > > > > >>volatile struct ixgbe_adv_tx_context_desc
> > > > > > > >> *ctx_txd,
> > > > > > > >>uint64_t ol_flags, union ixgbe_tx_offload
> > > > > > > >> tx_offload)
> > > > > > > >> {
> > > > > > > >> + static const union ixgbe_tx_offload offload_allones = {
> > > > > > > >> .data = ~0 };
> > > > > > > > Do you want to make this a static data structure? If you make
> > > > > > > > it a macro like
> > > > > > > > this:
> > > > > > > > #define ALLONES {.data = ~0}
> > > > > > > > Then you save the extra data space in the .data area (not that
> > > > > > > > its that much),
> > > > > > > > and you can define it in a header file and use it in multiple c
> > > > > > > > files (if you
> > > > > > > > need to)
> > > > > > >
> > > > > > > I found that the following code works:
> > > > > > >
> > > > > > > tx_offload_mask.l2_len |= ~0;
> > > > > > >
> > > > > > > (note the '|=' instead of '=')
> > > > > > >
> > > > > > How exactly does this work? does the or operator imply some level
> > > > > > of type
> > > > > > promotion that the assignment doesn't to avoid the truncation?
> > > > > > Neil
> > > > > >
> > > > >
> > > > > For any aithmetic, and presumably logical, operation on two values,
> > > > > any values
> > > > > smaller than "int" are promoted to type int before the operation
> > > > > takes place. I
> > > > > believe the exact rules for this are in the C specs e.g. C99.
> > > > >
> > > > Yes, but I would have thought that assignment was included in the list
> > > > of
> > > > logical operations for that promotion to occur. The above change seems
> > > > to
> > > > suggest it isn't, which is why I'm asking. C99 specifies |= explicitly
> > > > as a
> > > > type of assignment operator (see 6.5.16 here:
> > > > http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> > > > )
> > > >
> > > > So I would presume that using = should work exactly the same as |= in
> > > > terms of
> > > > type promotion. We also don't get this warning on gcc, which concerns
> > > > me that
> > > > we might just be papering over a compiler problem here.
> > > >
> > > > Looking at the error, its complaining that we're truncating an int
> > > > value to a
> > > > bitfield (which we are), and that the resultant value is 127 rather
> > > > that -1
> > > > (which it would be if we actually intended to treat it as an integer
> > > >
> > > > Which I think is where the problem lies. That is to
[dpdk-dev] [PATCH] mk: fix app linking for combined libs
2014-12-01 09:57, Gonzalez Monroy, Sergio: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-10-23 16:36, Sergio Gonzalez Monroy: > > > Building combined shared libraries results in applications being > > > linked against separeted/individual and combined libs altogether. > > > > > > Link only against combined lib when the config option is enabled. > > > > > > Signed-off-by: Sergio Gonzalez Monroy > > intel.com> > > [...] > > > --- a/mk/rte.app.mk > > > +++ b/mk/rte.app.mk > > > @@ -217,6 +217,12 @@ endif > > > > > > endif # plugins > > > > > > +ifeq ($(RTE_BUILD_COMBINE_LIBS),y) > > > +LDLIBS = --whole-archive > > > > You are resetting LDLIBS here. > > It's not easy to read and probably not desired. > > I think it would be better to explicitly disable separated libs in this > > case. > > > Yes, I am resetting LDLIBS so we just link against the combined lib instead > of all the previous separated libs. > I am not sure I understand what you mean with 'disable separated libs in this > case'. By "disable separated libs", I mean enclose the LDLIBS lines for separated libs with ifneq ($(RTE_BUILD_COMBINE_LIBS),y) Using ifeq is more explicit than inserting LDLIBS= in the middle of LDLIBS+= lines. Do you agree? -- Thomas
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > Hi Bruce, Hi Neil,
> >
> > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> > >> When compiling with clang, errors were being emitted due to truncation
> > >> of values when assigning to the tx_offload_mask bit fields.
> > >>
> > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit
> > >> truncation from 'int' to bitfield changes value from -1 to 127
> > >> [-Wbitfield-constant-conversion]
> > >> tx_offload_mask.l2_len = ~0;
> > >>
> > >> The fix proposed here is to define a static const value of the same type
> > >> with all fields set to 1s, and use that instead of constants for
> > >> assigning to.
> > >>
> > >> Other options would be to explicitily define the suitable constants that
> > >> would not truncate for each individual field e.g. 0x7f for l2_len, 0x1FF
> > >> for l3_len, etc., but this solution here has the advantage that it works
> > >> without any changes to values if the field sizes are ever modified.
> > >>
> > >> Signed-off-by: Bruce Richardson
> > >> ---
> > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
> > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > >>
> > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > >> index 8559ef6..4f71194 100644
> > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> > >> volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
> > >> uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
> > >> {
> > >> +static const union ixgbe_tx_offload offload_allones = { .data =
> > >> ~0 };
> > > Do you want to make this a static data structure? If you make it a macro
> > > like
> > > this:
> > > #define ALLONES {.data = ~0}
> > > Then you save the extra data space in the .data area (not that its that
> > > much),
> > > and you can define it in a header file and use it in multiple c files (if
> > > you
> > > need to)
> >
> > I found that the following code works:
> >
> > tx_offload_mask.l2_len |= ~0;
> >
> > (note the '|=' instead of '=')
> >
> How exactly does this work? does the or operator imply some level of type
> promotion that the assignment doesn't to avoid the truncation?
> Neil
>
For any aithmetic, and presumably logical, operation on two values, any values
smaller than "int" are promoted to type int before the operation takes place. I
believe the exact rules for this are in the C specs e.g. C99.
/Bruce
> > I would avoid to create a macro. What do you think?
> >
> > Regards,
> > Olivier
> >
[dpdk-dev] Testpmd with SR-IOV.
Hi I am trying to run latest DPDK on SR-IOV interface in VM environment. Interfaces are detected well in VM environment. When I started traffic through testpmd, it indicates both tx and rx are zero. I tried debugging. Wondering if you could point me some steps which I might be missing? Thanks in advance. Here are the steps that I followed. SR-IOV interfaces are detected in VM environment. Lspci indicate below interfaces in VM environment and ethtool indicates links are up and link speeds are fine. 00:08.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 00:09.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) root at regress-KVM:/dev/abc/dpdk/tools# ethtool eth2 Settings for eth2: Supported ports: [ ] Supported link modes: 1baseT/Full Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: Other PHYAD: 0 Transceiver: Unknown! Auto-negotiation: off Current message level: 0x0007 (7) drv probe link Link detected: yes root at regress-KVM:/dev/abc/dpdk/tools# ethtool eth3 Settings for eth3: Supported ports: [ ] Supported link modes: 1baseT/Full Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: Other PHYAD: 0 Transceiver: Unknown! Auto-negotiation: off Current message level: 0x0007 (7) drv probe link Link detected: yes Loaded uio module. root at regress-KVM:/dev/abc/dpdk/tools# modprobe uio root at regress-KVM:/dev/abc/dpdk/tools# insmod ../x86_64-native-linuxapp-gcc/kmod/igb_uio.ko Bound interfaces to igb_uio. root at regress-KVM:/dev/abc/dpdk/tools# python dpdk_nic_bind.py --bind=igb_uio 00:09.0 root at regress-KVM:/dev/abc/dpdk/tools# python dpdk_nic_bind.py --bind=igb_uio 00:08.0 Verified that interfaces are bound to igb_uio. root at regress-KVM:/dev/abc/dpdk/tools# python dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :00:08.0 '82599 Ethernet Controller Virtual Function' drv=igb_uio unused=vfio-pci :00:09.0 '82599 Ethernet Controller Virtual Function' drv=igb_uio unused=vfio-pci Network devices using kernel driver === :00:03.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio,vfio-pci :00:07.0 '82599 Ethernet Controller Virtual Function' if=eth1 drv=ixgbevf unused=igb_uio,vfio-pci Other network devices = root at regress-KVM:/dev/abc/dpdk/tools# Built test-pmd and executed and links detected. root at regress-KVM:/dev/abc/dpdk/app/test-pmd# ./testpmd -c 0xf -n 4 -- -i --nb-cores=2 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 0 on socket 0 EAL: Detected lcore 2 as core 0 on socket 0 EAL: Detected lcore 3 as core 0 on socket 0 EAL: Support maximum 64 logical core(s) by configuration. EAL: Detected 4 lcore(s) EAL: unsupported IOMMU type! EAL: VFIO support could not be initialized EAL: Setting up memory... EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fd8e120 (size = 0x20) EAL: Ask a virtual area of 0x7f00 bytes EAL: Virtual area found at 0x7fd86200 (size = 0x7f00) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fd861c0 (size = 0x20) EAL: Ask a virtual area of 0x40 bytes EAL: Virtual area found at 0x7fd86160 (size = 0x40) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fd86120 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fd860e0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fd860a0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fd86060 (size = 0x20) EAL: Requesting 1024 pages of size 2MB from socket 0 EAL: TSC frequency is ~199 KHz EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! EAL: Master core 0 is ready (tid=e281a840) EAL: Core 3 is ready (tid=5e9f0700) EAL: Core 2 is ready (tid=5f1f1700) EAL: Core 1 is ready (tid=5f9f2700) EAL: PCI device :00:03.0 on NUMA socket -1 EAL: probe driver: 1af4:1000 rte_virtio_pmd EAL: :00:03.0 not managed by UIO driver, skipping EAL: PCI device :00:07.0 on NUMA socket -1 EAL: probe driver: 8086:10ed rte_ixgbevf_pmd EAL: :00:07.0 not managed by UIO driver, skipping EAL: PCI device :00:08.0 on NUMA socket -1 EAL: probe driver: 8086:10ed rte_ixgbevf_pmd EAL: PCI memory mapped at 0x7fd8e2828000 EAL: PCI memory mapped at 0x7fd8e2824000 EAL: PCI device :00:09.0 on NUMA socket -1 EAL: probe driver: 8086:10ed rte_ixgbevf_pmd EAL: PCI memory mapped a
[dpdk-dev] [PATCH] enicpd: Warnings and one error when built using clang compiler
On Mon, Dec 01, 2014 at 11:06:43AM +, Sujith Sankar (ssujith) wrote: > > On 01/12/14 4:27 pm, "Bruce Richardson" wrote: > > >On Sat, Nov 29, 2014 at 12:47:37PM +0530, Sujith Sankar wrote: > >> This patch fixes the warnings and error reported by clang compiler on > >>Linux. > >> > >> Reported-by: Bruce Richardson > >> Signed-off-by: Sujith Sankar > > > >This PMD now compiles up with clang on FreeBSD. The patch seems rather > >large though, > >are all these changes necessary for clang compilation? > > Yes. This patch has only the changes to fix compilation on clang, and it > modifies enic code only. > > > > >On the basis that this fixes the issue though: > > > >Acked-by: Bruce Richardson > > Thanks Bruce. > And thank you for providing a patch so quickly! :-) /Bruce
[dpdk-dev] [PATCH] mk: fix app linking for combined libs
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, December 1, 2014 10:35 AM > > By "disable separated libs", I mean enclose the LDLIBS lines for separated > libs > with ifneq ($(RTE_BUILD_COMBINE_LIBS),y) Using ifeq is more explicit than > inserting LDLIBS= in the middle of LDLIBS+= lines. > Do you agree? > That makes sense, I agree it would be easier to read that way. I'll work on a v2. Thanks, Sergio > -- > Thomas
[dpdk-dev] [PATCH] enicpd: Warnings and one error when built using clang compiler
On 01/12/14 4:27 pm, "Bruce Richardson" wrote:
>On Sat, Nov 29, 2014 at 12:47:37PM +0530, Sujith Sankar wrote:
>> This patch fixes the warnings and error reported by clang compiler on
>>Linux.
>>
>> Reported-by: Bruce Richardson
>> Signed-off-by: Sujith Sankar
>
>This PMD now compiles up with clang on FreeBSD. The patch seems rather
>large though,
>are all these changes necessary for clang compilation?
Yes. This patch has only the changes to fix compilation on clang, and it
modifies enic code only.
>
>On the basis that this fixes the issue though:
>
>Acked-by: Bruce Richardson
Thanks Bruce.
>
>> ---
>> lib/librte_pmd_enic/enic.h | 40
>>+
>> lib/librte_pmd_enic/enic_compat.h | 1 +
>> lib/librte_pmd_enic/enic_main.c | 31 +++-
>> lib/librte_pmd_enic/vnic/vnic_dev.c | 19 ++
>> lib/librte_pmd_enic/vnic/vnic_dev.h | 9 +
>> 5 files changed, 78 insertions(+), 22 deletions(-)
>>
>> diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
>> index 6400d24..f128e64 100644
>> --- a/lib/librte_pmd_enic/enic.h
>> +++ b/lib/librte_pmd_enic/enic.h
>> @@ -154,4 +154,44 @@ static inline struct enic *pmd_priv(struct
>>rte_eth_dev *eth_dev)
>> return (struct enic *)eth_dev->data->dev_private;
>> }
>>
>> +extern int enic_fdir_add_fltr(struct enic *enic,
>> +struct rte_fdir_filter *params, u16 queue, u8 drop);
>> +extern int enic_fdir_del_fltr(struct enic *enic,
>> +struct rte_fdir_filter *params);
>> +extern void enic_free_wq(void *txq);
>> +extern int enic_alloc_intr_resources(struct enic *enic);
>> +extern int enic_setup_finish(struct enic *enic);
>> +extern int enic_alloc_wq(struct enic *enic, uint16_t queue_idx,
>> +unsigned int socket_id, uint16_t nb_desc);
>> +extern void enic_start_wq(struct enic *enic, uint16_t queue_idx);
>> +extern int enic_stop_wq(struct enic *enic, uint16_t queue_idx);
>> +extern void enic_start_rq(struct enic *enic, uint16_t queue_idx);
>> +extern int enic_stop_rq(struct enic *enic, uint16_t queue_idx);
>> +extern void enic_free_rq(void *rxq);
>> +extern int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
>> +unsigned int socket_id, struct rte_mempool *mp,
>> +uint16_t nb_desc);
>> +extern int enic_set_rss_nic_cfg(struct enic *enic);
>> +extern int enic_set_vnic_res(struct enic *enic);
>> +extern void enic_set_hdr_split_size(struct enic *enic, u16
>>split_hdr_size);
>> +extern int enic_enable(struct enic *enic);
>> +extern int enic_disable(struct enic *enic);
>> +extern void enic_remove(struct enic *enic);
>> +extern int enic_get_link_status(struct enic *enic);
>> +extern void enic_dev_stats_get(struct enic *enic,
>> +struct rte_eth_stats *r_stats);
>> +extern void enic_dev_stats_clear(struct enic *enic);
>> +extern void enic_add_packet_filter(struct enic *enic);
>> +extern void enic_set_mac_address(struct enic *enic, uint8_t *mac_addr);
>> +extern void enic_del_mac_address(struct enic *enic);
>> +extern unsigned int enic_cleanup_wq(struct enic *enic, struct vnic_wq
>>*wq);
>> +extern int enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
>> +struct rte_mbuf *tx_pkt, unsigned short len,
>> +uint8_t sop, uint8_t eop,
>> +uint16_t ol_flags, uint16_t vlan_tag);
>> +extern int enic_poll(struct vnic_rq *rq, struct rte_mbuf **rx_pkts,
>> +unsigned int budget, unsigned int *work_done);
>> +extern int enic_probe(struct enic *enic);
>> +extern int enic_clsf_init(struct enic *enic);
>> +extern void enic_clsf_destroy(struct enic *enic);
>> #endif /* _ENIC_H_ */
>> diff --git a/lib/librte_pmd_enic/enic_compat.h
>>b/lib/librte_pmd_enic/enic_compat.h
>> index b3738ee..b1af838 100644
>> --- a/lib/librte_pmd_enic/enic_compat.h
>> +++ b/lib/librte_pmd_enic/enic_compat.h
>> @@ -37,6 +37,7 @@
>> #define _ENIC_COMPAT_H_
>>
>> #include
>> +#include
>>
>> #include
>> #include
>> diff --git a/lib/librte_pmd_enic/enic_main.c
>>b/lib/librte_pmd_enic/enic_main.c
>> index 853dd04..4bbf1e4 100644
>> --- a/lib/librte_pmd_enic/enic_main.c
>> +++ b/lib/librte_pmd_enic/enic_main.c
>> @@ -65,17 +65,17 @@ static inline int enic_is_sriov_vf(struct enic
>>*enic)
>> return enic->pdev->id.device_id == PCI_DEVICE_ID_CISCO_VIC_ENET_VF;
>> }
>>
>> -static int is_zero_addr(char *addr)
>> +static int is_zero_addr(uint8_t *addr)
>> {
>> return !(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]);
>> }
>>
>> -static int is_mcast_addr(char *addr)
>> +static int is_mcast_addr(uint8_t *addr)
>> {
>> return addr[0] & 1;
>> }
>>
>> -static int is_eth_addr_valid(char *addr)
>> +static int is_eth_addr_valid(uint8_t *addr)
>> {
>> return !is_mcast_addr(addr) && !is_zero_addr(addr);
>> }
>> @@ -105,7 +105,8 @@ static const struct rte_memzone
>>*ring_dma_zone_reserve(
>> if (mz)
>> return mz;
>>
>> -return rte_memzone_reserve_aligned(z_name, (uint64_t) ring_size,
>> +return rte_memzone_
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
Hi Bruce, On 12/01/2014 10:48 AM, Bruce Richardson wrote: >> I found that the following code works: >> >> tx_offload_mask.l2_len |= ~0; >> >> (note the '|=' instead of '=') >> >> I would avoid to create a macro. What do you think? >> >> Regards, >> Olivier > > Nice one - cleanest solution thus far, so I suggest we go with that option. > Have > you got a patch for it ready? I'll submit the patch, after all it's my mistake! Regards, Olivier
[dpdk-dev] [PATCH] i40e: Use one bit flag for all hardware detected RX packet errors
Hi Helin, On 12/01/2014 02:57 AM, Zhang, Helin wrote: >>> #define PKT_RX_EIP_CKSUM_BAD (0ULL << 0) /**< External IP header >>> checksum error. */ [Helin] Nobody complains it, so we will keep it there, >>> and >> just assign a new value to it. >> >> ok. >> >> But it would be nice to have a better definition of this flag: does external >> mean >> outer header? For instance, when you receive a >> Ether/IP1/UDP/vxlan/Ether/IP2/xxx, does the flag concerns IP1 or IP2? > 'E' means 'external', it indicates the (most) outer IP header checksum error. > If you > don't think this name is not so clear, I can change it to > 'PKT_RX_OUTER_IP_CHSUM_BAD'. > For inner IP header checksum error, it will be indicated by > PKT_RX_IP_CKSUM_BAD. > >> >> If it's IP1, it's really strange compared to the current behavior (the flag >> PKT_RX_IP_CKSUM_BAD refers to IP1). Ok. But the real sense of my question was about the behavior which seems different than with previous hardware. Today, if you receive the packet Ether/IP1/UDP/vxlan/Ether/IP2/xxx on an ixgbe, the flag PKT_RX_IP_CKSUM_BAD can be set if the checksum of IP1 is wrong. From your explanation, I understand that PKT_RX_EIP_CKSUM_BAD would be set for the same thing on i40e. Is it correct? >>> #define PKT_RX_OVERSIZE (0ULL << 0) /**< Num of desc of an RX pkt >> oversize. */ >>> [Helin] I don't think it can be merge with other hardware errors. It >>> indicates the packet received needs more descriptors than hardware >>> allowed, and the part of packets can still be stored in the mbufs >>> provided. It is a good hint for users that larger size of mbuf might >>> be needed. If just put it as hardware error, users will lose this >>> information. So I >> prefer to keep it there, and just assign a new value to it. >> >> Again, a statistic counter would do the job which if it's just to provide a >> hint to the >> application. > It seems that we do not maintain a counter for packets in PMD, if I am not > wrong. Two > ways current DPDK is using. > One is hardware provide registers to do that, we can read it directly when > needed. > The other one is that applications or middle layer sw maintain its own > statistics. rte_eth_stats_get() gives the generic statistics For specific error stats, rte_eth_xstats_get() can be used from an application (the driver has to provide the full list of statistics). >> I wonder in which case this flag can happen. If you fill the ring with mbufs >> that are >> large enough compared to your ethernet network, this should not happen in >> normal conditions. I really don't believe that an application receiving an >> mbuf >> with this flag would stop the driver, then refill the rings it with larger >> mbufs. > This is not because of it is lack of available RX descriptors. It is because > of a hardware > requirement. FVL hardware requires that it should not use more than 5 rx > descriptors > for receiving a single packet. I still don't understand what the application should do when the flag is set. Maybe you could provide an example in l2fwd or testpmd? >> Last but not least: If it's really useful, should we have the same behavior >> on other >> drivers like ixgbe? I think we really need to care about not having >> different ways >> to use the different drivers. > I don't see the similar bit in ixgbe datasheet, but this restriction could be > common > for some other NICs, as it is reasonable from hardware perspective. In ixgbe, there are other error cases: - frames shorter than 64 bytes - oversize (frames larger than MAXFRS) - ... maybe others? Should we have a flag for each situation? I think not. >> To me, the only argument in favor of keeping this flag is when the mbuf >> contains >> a part of the data that could be dumped by a user for debug purposes. >> >>> #define PKT_RX_HBUF_OVERFLOW (0ULL << 0) /**< Header buffer overflow. >>> */ [Helin] It indicates the header buff size is not enough, but not >>> means hardware cannot process the packet received. It is a good hint >>> for the users to provide larger size of header buffers. I also prefer to >>> keep it >> there, and just assign new value to it. >> >> Same for this one. > It is a bit different from previous one, it always has one header buffer, > this flag means > the buffer size is not enough for the header. > These two flags are because of buffer size or number of buffers. The mbufs > are prepared > in application or up layer software. If these two flags occur, it is easier > for up layer software > to debug, and know different buffers are needed. They do not need to debug > PMD, as they > generally don't want to do. You say it's easier for the software to debug, but I cannot see the difference. When it's a statistics counter, you just have to use rte_eth_xstats_get(), which is an equivalent of "ethtool -S iface" which gives all the hardware statistics. It will work for any driver and any application. If we add these flags, the application have to know about
[dpdk-dev] RTE mempool "used count" steadily goes down to zero despite steady packet throughput
Hi Kam, On 11/28/2014 06:34 PM, Kamraan Nasim wrote: > I have ~15Gbps of traffic flowing through two 10GE ports and been profiling > the rte mempool(or rather the pktmbuf mempool) memory consumption: > > I have per lcore caching disabled(cache_size is 0) > > I have noticed that: > - Mempool FREE cnt(as given byt rte_mempool_free_count()) increases > - Mempool USED cnt(as given by rte_mempool_used_count() decreases and > eventually drops to 0. When this happens, mempool reports itself as EMPTY > - rx_nombuf stats for the eth ports start climbing > - Valgrind Memcheck does not indicate any obvious leaks in RTE mempool or > my application. > > > I was wondering if others have come across this issue? Or if people here > have used ways, besides Valgrind to profile the mempool or the pkt mbuf > pool? First, be careful with rte_mempool_free_count(): it returns the number of free entries in the internal ring of the mempool, which actually corresponds to the number of allocated objects from the mempool point of view. See: http://dpdk.org/browse/dpdk/tree/lib/librte_mempool/rte_mempool.h If you have the number of allocated objects increasing, and the statistics rx_nombuf increasing when the mbuf pool is empty, it means that you have a mbuf leak in your application. Valgrind won't see it since it does not know about mempool alloc/free functions. Regards, Olivier
[dpdk-dev] [PATCH] enicpd: Warnings and one error when built using clang compiler
On Sat, Nov 29, 2014 at 12:47:37PM +0530, Sujith Sankar wrote:
> This patch fixes the warnings and error reported by clang compiler on Linux.
>
> Reported-by: Bruce Richardson
> Signed-off-by: Sujith Sankar
This PMD now compiles up with clang on FreeBSD. The patch seems rather large
though,
are all these changes necessary for clang compilation?
On the basis that this fixes the issue though:
Acked-by: Bruce Richardson
> ---
> lib/librte_pmd_enic/enic.h | 40
> +
> lib/librte_pmd_enic/enic_compat.h | 1 +
> lib/librte_pmd_enic/enic_main.c | 31 +++-
> lib/librte_pmd_enic/vnic/vnic_dev.c | 19 ++
> lib/librte_pmd_enic/vnic/vnic_dev.h | 9 +
> 5 files changed, 78 insertions(+), 22 deletions(-)
>
> diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
> index 6400d24..f128e64 100644
> --- a/lib/librte_pmd_enic/enic.h
> +++ b/lib/librte_pmd_enic/enic.h
> @@ -154,4 +154,44 @@ static inline struct enic *pmd_priv(struct rte_eth_dev
> *eth_dev)
> return (struct enic *)eth_dev->data->dev_private;
> }
>
> +extern int enic_fdir_add_fltr(struct enic *enic,
> + struct rte_fdir_filter *params, u16 queue, u8 drop);
> +extern int enic_fdir_del_fltr(struct enic *enic,
> + struct rte_fdir_filter *params);
> +extern void enic_free_wq(void *txq);
> +extern int enic_alloc_intr_resources(struct enic *enic);
> +extern int enic_setup_finish(struct enic *enic);
> +extern int enic_alloc_wq(struct enic *enic, uint16_t queue_idx,
> + unsigned int socket_id, uint16_t nb_desc);
> +extern void enic_start_wq(struct enic *enic, uint16_t queue_idx);
> +extern int enic_stop_wq(struct enic *enic, uint16_t queue_idx);
> +extern void enic_start_rq(struct enic *enic, uint16_t queue_idx);
> +extern int enic_stop_rq(struct enic *enic, uint16_t queue_idx);
> +extern void enic_free_rq(void *rxq);
> +extern int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
> + unsigned int socket_id, struct rte_mempool *mp,
> + uint16_t nb_desc);
> +extern int enic_set_rss_nic_cfg(struct enic *enic);
> +extern int enic_set_vnic_res(struct enic *enic);
> +extern void enic_set_hdr_split_size(struct enic *enic, u16 split_hdr_size);
> +extern int enic_enable(struct enic *enic);
> +extern int enic_disable(struct enic *enic);
> +extern void enic_remove(struct enic *enic);
> +extern int enic_get_link_status(struct enic *enic);
> +extern void enic_dev_stats_get(struct enic *enic,
> + struct rte_eth_stats *r_stats);
> +extern void enic_dev_stats_clear(struct enic *enic);
> +extern void enic_add_packet_filter(struct enic *enic);
> +extern void enic_set_mac_address(struct enic *enic, uint8_t *mac_addr);
> +extern void enic_del_mac_address(struct enic *enic);
> +extern unsigned int enic_cleanup_wq(struct enic *enic, struct vnic_wq *wq);
> +extern int enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
> + struct rte_mbuf *tx_pkt, unsigned short len,
> + uint8_t sop, uint8_t eop,
> + uint16_t ol_flags, uint16_t vlan_tag);
> +extern int enic_poll(struct vnic_rq *rq, struct rte_mbuf **rx_pkts,
> + unsigned int budget, unsigned int *work_done);
> +extern int enic_probe(struct enic *enic);
> +extern int enic_clsf_init(struct enic *enic);
> +extern void enic_clsf_destroy(struct enic *enic);
> #endif /* _ENIC_H_ */
> diff --git a/lib/librte_pmd_enic/enic_compat.h
> b/lib/librte_pmd_enic/enic_compat.h
> index b3738ee..b1af838 100644
> --- a/lib/librte_pmd_enic/enic_compat.h
> +++ b/lib/librte_pmd_enic/enic_compat.h
> @@ -37,6 +37,7 @@
> #define _ENIC_COMPAT_H_
>
> #include
> +#include
>
> #include
> #include
> diff --git a/lib/librte_pmd_enic/enic_main.c b/lib/librte_pmd_enic/enic_main.c
> index 853dd04..4bbf1e4 100644
> --- a/lib/librte_pmd_enic/enic_main.c
> +++ b/lib/librte_pmd_enic/enic_main.c
> @@ -65,17 +65,17 @@ static inline int enic_is_sriov_vf(struct enic *enic)
> return enic->pdev->id.device_id == PCI_DEVICE_ID_CISCO_VIC_ENET_VF;
> }
>
> -static int is_zero_addr(char *addr)
> +static int is_zero_addr(uint8_t *addr)
> {
> return !(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]);
> }
>
> -static int is_mcast_addr(char *addr)
> +static int is_mcast_addr(uint8_t *addr)
> {
> return addr[0] & 1;
> }
>
> -static int is_eth_addr_valid(char *addr)
> +static int is_eth_addr_valid(uint8_t *addr)
> {
> return !is_mcast_addr(addr) && !is_zero_addr(addr);
> }
> @@ -105,7 +105,8 @@ static const struct rte_memzone *ring_dma_zone_reserve(
> if (mz)
> return mz;
>
> - return rte_memzone_reserve_aligned(z_name, (uint64_t) ring_size,
> + return rte_memzone_reserve_aligned((const char *)z_name,
> + (uint64_t) ring_size,
> socket_id, RTE_MEMZONE_1GB, ENIC_ALIGN);
> }
>
> @@ -430,14 +431,15 @@ static int enic_rq_indicate_buf(struct vnic_rq *rq,
> &ipv4_csum_ok, &ipv6, &ipv4, &ipv4_f
[dpdk-dev] [PATCH] ixgbe: change assignation of bitfields to fix clang compilation
On Mon, Dec 01, 2014 at 11:36:13AM +0100, Olivier Matz wrote:
> Commit 1224decaa44b3dba58e0a524fd0383969929c575 changed the way
> the bitfields are assigned in ixgbe, example:
>
> tx_offload_mask.l2_len = ~0;
>
> This result in a compilation error with clang:
>
>error: implicit truncation from 'int' to bitfield
> changes value from -1 to 127 [-Werror,-Wbitfield-constant-conversion]
>
> Replacing the '=' with a '|=' fixes the issue.
>
> Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
> ---
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index 8559ef6..5c36bff 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -381,7 +381,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> mss_l4len_idx |= (ctx_idx << IXGBE_ADVTXD_IDX_SHIFT);
>
> if (ol_flags & PKT_TX_VLAN_PKT) {
> - tx_offload_mask.vlan_tci = ~0;
> + tx_offload_mask.vlan_tci |= ~0;
> }
>
> /* check if TCP segmentation required for this packet */
> @@ -391,17 +391,17 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> IXGBE_ADVTXD_TUCMD_L4T_TCP |
> IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
>
> - tx_offload_mask.l2_len = ~0;
> - tx_offload_mask.l3_len = ~0;
> - tx_offload_mask.l4_len = ~0;
> - tx_offload_mask.tso_segsz = ~0;
> + tx_offload_mask.l2_len |= ~0;
> + tx_offload_mask.l3_len |= ~0;
> + tx_offload_mask.l4_len |= ~0;
> + tx_offload_mask.tso_segsz |= ~0;
> mss_l4len_idx |= tx_offload.tso_segsz << IXGBE_ADVTXD_MSS_SHIFT;
> mss_l4len_idx |= tx_offload.l4_len << IXGBE_ADVTXD_L4LEN_SHIFT;
> } else { /* no TSO, check if hardware checksum is needed */
> if (ol_flags & PKT_TX_IP_CKSUM) {
> type_tucmd_mlhl = IXGBE_ADVTXD_TUCMD_IPV4;
> - tx_offload_mask.l2_len = ~0;
> - tx_offload_mask.l3_len = ~0;
> + tx_offload_mask.l2_len |= ~0;
> + tx_offload_mask.l3_len |= ~0;
> }
>
> switch (ol_flags & PKT_TX_L4_MASK) {
> @@ -409,23 +409,23 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_UDP |
> IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
> mss_l4len_idx |= sizeof(struct udp_hdr) <<
> IXGBE_ADVTXD_L4LEN_SHIFT;
> - tx_offload_mask.l2_len = ~0;
> - tx_offload_mask.l3_len = ~0;
> + tx_offload_mask.l2_len |= ~0;
> + tx_offload_mask.l3_len |= ~0;
> break;
> case PKT_TX_TCP_CKSUM:
> type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_TCP |
> IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
> mss_l4len_idx |= sizeof(struct tcp_hdr) <<
> IXGBE_ADVTXD_L4LEN_SHIFT;
> - tx_offload_mask.l2_len = ~0;
> - tx_offload_mask.l3_len = ~0;
> - tx_offload_mask.l4_len = ~0;
> + tx_offload_mask.l2_len |= ~0;
> + tx_offload_mask.l3_len |= ~0;
> + tx_offload_mask.l4_len |= ~0;
> break;
> case PKT_TX_SCTP_CKSUM:
> type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_SCTP |
> IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
> mss_l4len_idx |= sizeof(struct sctp_hdr) <<
> IXGBE_ADVTXD_L4LEN_SHIFT;
> - tx_offload_mask.l2_len = ~0;
> - tx_offload_mask.l3_len = ~0;
> + tx_offload_mask.l2_len |= ~0;
> + tx_offload_mask.l3_len |= ~0;
> break;
> default:
> type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_RSV |
> --
> 2.1.0
>
[dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields
Hi Jijiang, On 12/01/2014 03:30 AM, Liu, Jijiang wrote: >> After another thought, I think that the way you proposed is a better one. >> I gives us more flexibility: >> let's say for now we'll keep both l2_len and outer_l2_len as 7 bit fields, >> and upper >> layer would have to: >> mb->l2_len = eth_hdr_in + vxlan_hdr; > > A question, how to fill the mb->l2_len for IP in IP, IP in GRE tunneling > packet that is no inner L2 header? > What is the rule? > Or you think it should be mb->l2_len = 0 + l4_tun_len; ?? We could have the following rule: - the l2_len starts after the end of outer_l2_len + outer_l3_len (if they are not 0) - l2_len is the length of all headers up to the first ip or ipv6 header Examples: Ether/IP/UDP/xxx m->outer_l2_len = 0 m->outer_l3_len = 0 m->l2_len = sizeof(ether) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) Ether/IP/IP/UDP/xxx m->outer_l2_len = sizeof(ether) m->outer_l3_len = sizeof(ip) m->l2_len = 0 m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) Ether/IP/GRE/IP/UDP/xxx m->outer_l2_len = sizeof(ether) m->outer_l3_len = sizeof(ip) m->l2_len = sizeof(gre) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) Ether/IP/UDP/vxlan/Ether/IP/UDP/xxx m->outer_l2_len = sizeof(ether) m->outer_l3_len = sizeof(ip) m->l2_len = sizeof(udp) + sizeof(vxlan) + sizeof(ether) m->l3_len = sizeof(ip) m->l4_len = sizeof(udp) Regards, Olivier
[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT
Hi, I've noticed that there is no bridge for Israel, this time. Could one be set up? On Mon, Dec 1, 2014 at 4:49 AM, Tetsuya Mukawa wrote: > Hi Tim, > > Could I explain port hotplug function at next conference call? > For this explanation, I've prepared slides. could I send a PDF to this ML? > That slides describe what is the function, how it works and what is > current progress. > And it's under 100KB. > > Regards, > Tetsuya > > (2014/11/22 1:08), O'driscoll, Tim wrote: > > We're going to hold our next community call on Tuesday 2nd December. > This time, we're going to try a time that's more suitable for participants > in Asia, so we're going to hold it at 8:00 AM GMT. The meeting time in a > variety of timezones is included below. > > > > Generally, GoToMeeting worked well last time, although there was a > limitation that Neil was unable to present slides as he joined from a Linux > system. We'll stick with GoToMeeting again this time as we don't yet have a > better solution. Details for joining the GoToMeeting session are included > below. > > > > I'll record the session again and post the video to YouTube afterwards > for anybody who can't make it. This seemed to work well last time, and as > Kevin pointed out, the audio quality on the recording is good. > > > > For the agenda, we'd like to discuss the following: > > ? Remaining 2.0 candidate features, especially PCI Hotplug as there's > been a lot of discussion on that on the mailing list. Hopefully Tetsuya > Mukawa can join us to describe his work on this. > > ? DPDK Test Suite. We hope to announce the release of this next week. > Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe the > functionality and benefits of this. > > > > > > Meeting Time: > > Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC > > Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour > > Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 > hours > > Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3 hours > > New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST > UTC+5:30 hours > > Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at > 4:00:00 PM CST UTC+8 hours > > Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours > > San Francisco (U.S.A. - California) Midnight between Monday, December 1, > 2014 and Tuesday, December 2, 2014 PST UTC-8 hours > > Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST > UTC-7 hours > > New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM EST > UTC-5 hours > > Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST > UTC-5 hours > > Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00 > > > > > > GoToMeeting Details: > > To join, follow the meeting link: > https://global.gotomeeting.com/join/772753069. This will start the > GoToMeeting web viewer. You then have two options for audio: > > > > 1. To use your computer's audio via a headset, you need to switch to the > desktop version of GoToMeeting. You can do this by clicking the GoToMeeting > icon on the top right hand side of the web viewer, and then selecting > "Switch to the desktop version". The desktop version will need to download > and install, so if you plan to use this you may want to get it set up in > advance. Once it starts, under the Audio section, you can select "Mic & > Speakers". The desktop version is only available for Windows and Mac, so if > you're using Linux then you need to use option 2 below. > > > > 2. You can join using a phone via one of the numbers listed below. The > Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is > accessible by clicking the phone icon in the GoToMeeting web viewer after > you've joined the meeting. > > ? Australia (Long distance): +61 2 9091 7601 > > ? Austria (Long distance): +43 (0) 7 2088 1036 > > ? Belgium (Long distance): +32 (0) 28 08 4345 > > ? Canada (Long distance): +1 (647) 497-9372 > > ? Denmark (Long distance): +45 (0) 69 91 89 24 > > ? Finland (Long distance): +358 (0) 942 45 0382 > > ? France (Long distance): +33 (0) 170 950 586 > > ? Germany (Long distance): +49 (0) 692 5736 7206 > > ? Ireland (Long distance): +353 (0) 15 255 598 > > ? Italy (Long distance): +39 0 694 80 31 28 > > ? Netherlands (Long distance): +31 (0) 208 084 055 > > ? New Zealand (Long distance): +64 (0) 4 974 7243 > > ? Norway (Long distance): +47 23 96 01 18 > > ? Spain (Long distance): +34 932 20 0506 > > ? Sweden (Long distance): +46 (0) 852 500 182 > > ? Switzerland (Long distance): +41 (0) 435 0824 78 > > ? United Kingdom (Long distance): +44 (0) 330 221 0098 > > ? United States (Long distance): +1 (626) 521-0013 > > Access Code 772-753-069. > > > > Info on downloading the desktop app is available at: > http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title=Download%7D > > Info on the
[dpdk-dev] Avoid stripping vlan tag with I350 VF on a VM
My application running on a VM needs to deal with multiple VLANS on packets
received over I350 using Virtual Function. But I always see the received
packets without vlan tag.
This is my setup:
- host: 3.13.6-031306-generic
- QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7)
- guest: 2.6.32-358.el6.x86_64
- dpdk: 1.6
And this is how I set up in the VM:
---
memset(&port_conf, 0, sizeof(port_conf));
if (vlanCnt > 0)
port_conf.rxmode.hw_vlan_filter = 1;
port_conf.rxmode.jumbo_frame = 1;
port_conf.rxmode.max_rx_pkt_len = 9018;
ret = rte_eth_dev_configure(port, 1, 1, &port_conf);
if (ret < 0) {
rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
ret=%d\n",
(unsigned)port, ret);
return -1;
}
for(i = 0; i < vlanCnt; i++) {
ret = rte_eth_dev_vlan_filter(port, vlan[i], 1);
if (ret < 0) {
rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
vlan%d ret=%d\n",
(unsigned)port, vlan[i], ret);
return -1;
}
}
-
If I also try to explicitly disable the stripping with next, but get an
error return -ENOSUP.
ret = rte_eth_dev_set_vlan_strip_on_queue(port, 0, 0);
I appreciate anyone can help. on how to set it up.
Thanks,
Shian Wong
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 02:36:46PM +, Bruce Richardson wrote:
> On Mon, Dec 01, 2014 at 09:25:44AM -0500, Neil Horman wrote:
> > On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> > > On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > > > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > > > Hi Bruce, Hi Neil,
> > > > >
> > > > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> > > > > >> When compiling with clang, errors were being emitted due to
> > > > > >> truncation
> > > > > >> of values when assigning to the tx_offload_mask bit fields.
> > > > > >>
> > > > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error:
> > > > > >> implicit truncation from 'int' to bitfield changes value from -1
> > > > > >> to 127 [-Wbitfield-constant-conversion]
> > > > > >>tx_offload_mask.l2_len = ~0;
> > > > > >>
> > > > > >> The fix proposed here is to define a static const value of the
> > > > > >> same type
> > > > > >> with all fields set to 1s, and use that instead of constants for
> > > > > >> assigning to.
> > > > > >>
> > > > > >> Other options would be to explicitily define the suitable
> > > > > >> constants that
> > > > > >> would not truncate for each individual field e.g. 0x7f for l2_len,
> > > > > >> 0x1FF
> > > > > >> for l3_len, etc., but this solution here has the advantage that it
> > > > > >> works
> > > > > >> without any changes to values if the field sizes are ever modified.
> > > > > >>
> > > > > >> Signed-off-by: Bruce Richardson
> > > > > >> ---
> > > > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29
> > > > > >> +++--
> > > > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > > > >>
> > > > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > >> index 8559ef6..4f71194 100644
> > > > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> > > > > >>volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
> > > > > >>uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
> > > > > >> {
> > > > > >> + static const union ixgbe_tx_offload offload_allones = { .data =
> > > > > >> ~0 };
> > > > > > Do you want to make this a static data structure? If you make it a
> > > > > > macro like
> > > > > > this:
> > > > > > #define ALLONES {.data = ~0}
> > > > > > Then you save the extra data space in the .data area (not that its
> > > > > > that much),
> > > > > > and you can define it in a header file and use it in multiple c
> > > > > > files (if you
> > > > > > need to)
> > > > >
> > > > > I found that the following code works:
> > > > >
> > > > > tx_offload_mask.l2_len |= ~0;
> > > > >
> > > > > (note the '|=' instead of '=')
> > > > >
> > > > How exactly does this work? does the or operator imply some level of
> > > > type
> > > > promotion that the assignment doesn't to avoid the truncation?
> > > > Neil
> > > >
> > >
> > > For any aithmetic, and presumably logical, operation on two values, any
> > > values
> > > smaller than "int" are promoted to type int before the operation takes
> > > place. I
> > > believe the exact rules for this are in the C specs e.g. C99.
> > >
> > Yes, but I would have thought that assignment was included in the list of
> > logical operations for that promotion to occur. The above change seems to
> > suggest it isn't, which is why I'm asking. C99 specifies |= explicitly as a
> > type of assignment operator (see 6.5.16 here:
> > http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
> > )
> >
> > So I would presume that using = should work exactly the same as |= in terms
> > of
> > type promotion. We also don't get this warning on gcc, which concerns me
> > that
> > we might just be papering over a compiler problem here.
> >
> > Looking at the error, its complaining that we're truncating an int value to
> > a
> > bitfield (which we are), and that the resultant value is 127 rather that -1
> > (which it would be if we actually intended to treat it as an integer
> >
> > Which I think is where the problem lies. That is to say we've typed the
> > bitfields in ixgbe_tx_offload as uint64_t. I'm guessing gcc just promotes
> > ~0 to
> > an unsigned int during the assignment, and supresses the warning (unless you
> > turn on -pedantic or some such), but clang does not. The correct solution I
> > think here is to either:
> >
> > 1) modify the bitfield types so that they are signed integers, thereby
> > maintaining the resultant value of -1 after the assignment
> >
> > or
> >
> > 2) Modify the ~0 to be ~0UL, so that the clang compiler sees that the
> > resultant
> > value will be MAXLONG after the assignment
> >
> > I'd think operation 2 would be the bett
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
Hi Bruce, Hi Neil,
On 11/30/2014 02:05 AM, Neil Horman wrote:
> On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
>> When compiling with clang, errors were being emitted due to truncation
>> of values when assigning to the tx_offload_mask bit fields.
>>
>> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit
>> truncation from 'int' to bitfield changes value from -1 to 127
>> [-Wbitfield-constant-conversion]
>> tx_offload_mask.l2_len = ~0;
>>
>> The fix proposed here is to define a static const value of the same type
>> with all fields set to 1s, and use that instead of constants for assigning
>> to.
>>
>> Other options would be to explicitily define the suitable constants that
>> would not truncate for each individual field e.g. 0x7f for l2_len, 0x1FF
>> for l3_len, etc., but this solution here has the advantage that it works
>> without any changes to values if the field sizes are ever modified.
>>
>> Signed-off-by: Bruce Richardson
>> ---
>> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
>> 1 file changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
>> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
>> index 8559ef6..4f71194 100644
>> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
>> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
>> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
>> volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
>> uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
>> {
>> +static const union ixgbe_tx_offload offload_allones = { .data = ~0 };
> Do you want to make this a static data structure? If you make it a macro like
> this:
> #define ALLONES {.data = ~0}
> Then you save the extra data space in the .data area (not that its that much),
> and you can define it in a header file and use it in multiple c files (if you
> need to)
I found that the following code works:
tx_offload_mask.l2_len |= ~0;
(note the '|=' instead of '=')
I would avoid to create a macro. What do you think?
Regards,
Olivier
[dpdk-dev] [PATCH] mk: fix app linking for combined libs
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, November 28, 2014 3:56 PM > > 2014-10-23 16:36, Sergio Gonzalez Monroy: > > Building combined shared libraries results in applications being > > linked against separeted/individual and combined libs altogether. > > > > Link only against combined lib when the config option is enabled. > > > > Signed-off-by: Sergio Gonzalez Monroy > > > [...] > > --- a/mk/rte.app.mk > > +++ b/mk/rte.app.mk > > @@ -217,6 +217,12 @@ endif > > > > endif # plugins > > > > +ifeq ($(RTE_BUILD_COMBINE_LIBS),y) > > +LDLIBS = --whole-archive > > You are resetting LDLIBS here. > It's not easy to read and probably not desired. > I think it would be better to explicitly disable separated libs in this case. > Yes, I am resetting LDLIBS so we just link against the combined lib instead of all the previous separated libs. I am not sure I understand what you mean with 'disable separated libs in this case'. Thanks, Sergio > > +LDLIBS += --start-group > > +LDLIBS += -l$(RTE_LIBNAME) > > +endif > > Thanks > -- > Thomas
[dpdk-dev] [PATCH] mk: fix build 32bits shared libs on 64bits system
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, November 28, 2014 3:49 PM > > Hi Sergio, > > 2014-10-22 17:36, Sergio Gonzalez Monroy: > > Incompatible libraries error when building shared libraries for 32bits > > on a 64bits system. > > Fix issue by passing CPU_CFLAGS to CC when LINK_USING_CC is enabled. > > This issue looks really strange. If that's the only way to fix it, it would be > better to have a comment in the makefile and a detailed explanation in the > commit log. > Hi Thomas, There may be a better way to deal with this, please feel free to suggest alternate method. We do specify -m32 or -m64 when building the DPDK. The issue is that we were not specifying -m32 when linking, therefore the wrong libraries were being picked. At the time CPU_CFLAGS was only being set with -m32/-m64, reason why I used such variable. Would it be better to create another var and pass it down? Thanks, Sergio > Thanks > -- > Thomas
[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT
Hi Alex, Unfortunately GoToMeeting don't provide a local access number for Israel. That means you'll either need to use VoIP via the GoToMeeting desktop client (Windows and Mac only), or else use one of the international access numbers below. Tim From: Alex Markuze [mailto:a...@weka.io] Hi, I've noticed that there is no bridge for Israel, this time. Could one be set up? On Mon, Dec 1, 2014 at 4:49 AM, Tetsuya Mukawa wrote: Hi Tim, Could I explain port hotplug function at next conference call? For this explanation, I've prepared slides. could I send a PDF to this ML? That slides describe what is the function, how it works and what is current progress. And it's under 100KB. Regards, Tetsuya (2014/11/22 1:08), O'driscoll, Tim wrote: > We're going to hold our next community call on Tuesday 2nd December. This > time, we're going to try a time that's more suitable for participants in > Asia, so we're going to hold it at 8:00 AM GMT. The meeting time in a variety > of timezones is included below. > > Generally, GoToMeeting worked well last time, although there was a limitation > that Neil was unable to present slides as he joined from a Linux system. > We'll stick with GoToMeeting again this time as we don't yet have a better > solution. Details for joining the GoToMeeting session are included below. > > I'll record the session again and post the video to YouTube afterwards for > anybody who can't make it. This seemed to work well last time, and as Kevin > pointed out, the audio quality on the recording is good. > > For the agenda, we'd like to discuss the following: > ? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a > lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can > join us to describe his work on this. > ? DPDK Test Suite. We hope to announce the release of this next week. > Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe the > functionality and benefits of this. > > > Meeting Time: > Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC > Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour > Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours > Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3 hours > New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST > UTC+5:30 hours > Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at 4:00:00 > PM CST UTC+8 hours > Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours > San Francisco (U.S.A. - California) Midnight between Monday, December 1, 2014 > and Tuesday, December 2, 2014 PST UTC-8 hours > Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST UTC-7 > hours > New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM EST > UTC-5 hours > Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST UTC-5 > hours > Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00 > > > GoToMeeting Details: > To join, follow the meeting link: > https://global.gotomeeting.com/join/772753069. This will start the > GoToMeeting web viewer. You then have two options for audio: > > 1. To use your computer's audio via a headset, you need to switch to the > desktop version of GoToMeeting. You can do this by clicking the GoToMeeting > icon on the top right hand side of the web viewer, and then selecting "Switch > to the desktop version". The desktop version will need to download and > install, so if you plan to use this you may want to get it set up in advance. > Once it starts, under the Audio section, you can select "Mic & Speakers". The > desktop version is only available for Windows and Mac, so if you're using > Linux then you need to use option 2 below. > > 2. You can join using a phone via one of the numbers listed below. The Access > Code is 772-753-069. You'll also be asked for an Audio PIN, which is > accessible by clicking the phone icon in the GoToMeeting web viewer after > you've joined the meeting. > ? Australia? ?(Long distance): +61 2 9091 7601 > ? Austria? ?(Long distance): +43 (0) 7 2088 1036 > ? Belgium? ?(Long distance): +32 (0) 28 08 4345 > ? Canada? ?(Long distance): +1 (647) 497-9372 > ? Denmark? ?(Long distance): +45 (0) 69 91 89 24 > ? Finland? ?(Long distance): +358 (0) 942 45 0382 > ? France? ?(Long distance): +33 (0) 170 950 586 > ? Germany? ?(Long distance): +49 (0) 692 5736 7206 > ? Ireland? ?(Long distance): +353 (0) 15 255 598 > ? Italy? ?(Long distance): +39 0 694 80 31 28 > ? Netherlands? ?(Long distance): +31 (0) 208 084 055 > ? New Zealand? ?(Long distance): +64 (0) 4 974 7243 > ? Norway? ?(Long distance): +47 23 96 01 18 > ? Spain? ?(Long distance): +34 932 20 0506 > ? Sweden? ?(Long distance): +46 (0) 852 500 182 > ? Switzerland? ?(Long distance): +41 (0) 435 0824 78 > ? United Kingdom? ?(Long distance): +44 (0) 330 221 0098 > ? United States? ?(Long distance): +1 (626)
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> Hi Bruce, Hi Neil,
>
> On 11/30/2014 02:05 AM, Neil Horman wrote:
> > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> >> When compiling with clang, errors were being emitted due to truncation
> >> of values when assigning to the tx_offload_mask bit fields.
> >>
> >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit
> >> truncation from 'int' to bitfield changes value from -1 to 127
> >> [-Wbitfield-constant-conversion]
> >>tx_offload_mask.l2_len = ~0;
> >>
> >> The fix proposed here is to define a static const value of the same type
> >> with all fields set to 1s, and use that instead of constants for assigning
> >> to.
> >>
> >> Other options would be to explicitily define the suitable constants that
> >> would not truncate for each individual field e.g. 0x7f for l2_len, 0x1FF
> >> for l3_len, etc., but this solution here has the advantage that it works
> >> without any changes to values if the field sizes are ever modified.
> >>
> >> Signed-off-by: Bruce Richardson
> >> ---
> >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
> >> 1 file changed, 15 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> index 8559ef6..4f71194 100644
> >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> >>volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
> >>uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
> >> {
> >> + static const union ixgbe_tx_offload offload_allones = { .data = ~0 };
> > Do you want to make this a static data structure? If you make it a macro
> > like
> > this:
> > #define ALLONES {.data = ~0}
> > Then you save the extra data space in the .data area (not that its that
> > much),
> > and you can define it in a header file and use it in multiple c files (if
> > you
> > need to)
>
> I found that the following code works:
>
> tx_offload_mask.l2_len |= ~0;
>
> (note the '|=' instead of '=')
>
> I would avoid to create a macro. What do you think?
>
> Regards,
> Olivier
Nice one - cleanest solution thus far, so I suggest we go with that option. Have
you got a patch for it ready?
/Bruce
[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT
Hi Tetsuya, It would be great if you could explain your work on hotplug at tomorrow's call. I think this is a topic that lots of people will be interested in. I'm not sure of the policy for sending attachments to the list. Perhaps that's something that Thomas can clarify. Can you send the slides to me anyway, just in case there's any problem with you presenting them in GoToMeeting tomorrow. I will also record the session and post the video for those who can't attend. Tim > -Original Message- > From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp] > Sent: Monday, December 1, 2014 2:50 AM > To: O'driscoll, Tim; dev at dpdk.org > Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 > AM GMT > > Hi Tim, > > Could I explain port hotplug function at next conference call? > For this explanation, I've prepared slides. could I send a PDF to this ML? > That slides describe what is the function, how it works and what is > current progress. > And it's under 100KB. > > Regards, > Tetsuya > > (2014/11/22 1:08), O'driscoll, Tim wrote: > > We're going to hold our next community call on Tuesday 2nd December. > This time, we're going to try a time that's more suitable for participants in > Asia, so we're going to hold it at 8:00 AM GMT. The meeting time in a variety > of timezones is included below. > > > > Generally, GoToMeeting worked well last time, although there was a > limitation that Neil was unable to present slides as he joined from a Linux > system. We'll stick with GoToMeeting again this time as we don't yet have a > better solution. Details for joining the GoToMeeting session are included > below. > > > > I'll record the session again and post the video to YouTube afterwards for > anybody who can't make it. This seemed to work well last time, and as Kevin > pointed out, the audio quality on the recording is good. > > > > For the agenda, we'd like to discuss the following: > > ? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a > lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can > join us to describe his work on this. > > ? DPDK Test Suite. We hope to announce the release of this next week. > Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe > the functionality and benefits of this. > > > > > > Meeting Time: > > Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC > > Paris (France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour > > Tel Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours > > Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3 > hours > > New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 PM IST > UTC+5:30 hours > > Shanghai (China - Shanghai Municipality) Tuesday, December 2, 2014 at > 4:00:00 PM CST UTC+8 hours > > Tokyo (Japan) Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours > > San Francisco (U.S.A. - California) Midnight between Monday, December 1, > 2014 and Tuesday, December 2, 2014 PST UTC-8 hours > > Phoenix (U.S.A. - Arizona) Tuesday, December 2, 2014 at 1:00:00 AM MST > UTC-7 hours > > New York (U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM > EST UTC-5 hours > > Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 AM EST > UTC-5 hours > > Corresponding UTC (GMT) Tuesday, December 2, 2014 at 08:00:00 > > > > > > GoToMeeting Details: > > To join, follow the meeting link: > https://global.gotomeeting.com/join/772753069. This will start the > GoToMeeting web viewer. You then have two options for audio: > > > > 1. To use your computer's audio via a headset, you need to switch to the > desktop version of GoToMeeting. You can do this by clicking the > GoToMeeting icon on the top right hand side of the web viewer, and then > selecting "Switch to the desktop version". The desktop version will need to > download and install, so if you plan to use this you may want to get it set up > in advance. Once it starts, under the Audio section, you can select "Mic & > Speakers". The desktop version is only available for Windows and Mac, so if > you're using Linux then you need to use option 2 below. > > > > 2. You can join using a phone via one of the numbers listed below. The > Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is > accessible by clicking the phone icon in the GoToMeeting web viewer after > you've joined the meeting. > > ? Australia (Long distance): +61 2 9091 7601 > > ? Austria (Long distance): +43 (0) 7 2088 1036 > > ? Belgium (Long distance): +32 (0) 28 08 4345 > > ? Canada (Long distance): +1 (647) 497-9372 > > ? Denmark (Long distance): +45 (0) 69 91 89 24 > > ? Finland (Long distance): +358 (0) 942 45 0382 > > ? France (Long distance): +33 (0) 170 950 586 > > ? Germany (Long distance): +49 (0) 692 5736 7206 > > ? Ireland (Long distance): +353 (0) 15 255 598 > > ? Italy (Long distance): +39 0 694 80 31 28 > > ? Netherlands (Long distance
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 11:24:58AM +, Bruce Richardson wrote:
> On Mon, Dec 01, 2014 at 06:18:17AM -0500, Neil Horman wrote:
> > On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> > > Hi Bruce, Hi Neil,
> > >
> > > On 11/30/2014 02:05 AM, Neil Horman wrote:
> > > > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> > > >> When compiling with clang, errors were being emitted due to truncation
> > > >> of values when assigning to the tx_offload_mask bit fields.
> > > >>
> > > >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error:
> > > >> implicit truncation from 'int' to bitfield changes value from -1 to
> > > >> 127 [-Wbitfield-constant-conversion]
> > > >>tx_offload_mask.l2_len = ~0;
> > > >>
> > > >> The fix proposed here is to define a static const value of the same
> > > >> type
> > > >> with all fields set to 1s, and use that instead of constants for
> > > >> assigning to.
> > > >>
> > > >> Other options would be to explicitily define the suitable constants
> > > >> that
> > > >> would not truncate for each individual field e.g. 0x7f for l2_len,
> > > >> 0x1FF
> > > >> for l3_len, etc., but this solution here has the advantage that it
> > > >> works
> > > >> without any changes to values if the field sizes are ever modified.
> > > >>
> > > >> Signed-off-by: Bruce Richardson
> > > >> ---
> > > >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
> > > >> 1 file changed, 15 insertions(+), 14 deletions(-)
> > > >>
> > > >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > >> index 8559ef6..4f71194 100644
> > > >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> > > >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> > > >>volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
> > > >>uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
> > > >> {
> > > >> + static const union ixgbe_tx_offload offload_allones = { .data =
> > > >> ~0 };
> > > > Do you want to make this a static data structure? If you make it a
> > > > macro like
> > > > this:
> > > > #define ALLONES {.data = ~0}
> > > > Then you save the extra data space in the .data area (not that its that
> > > > much),
> > > > and you can define it in a header file and use it in multiple c files
> > > > (if you
> > > > need to)
> > >
> > > I found that the following code works:
> > >
> > > tx_offload_mask.l2_len |= ~0;
> > >
> > > (note the '|=' instead of '=')
> > >
> > How exactly does this work? does the or operator imply some level of type
> > promotion that the assignment doesn't to avoid the truncation?
> > Neil
> >
>
> For any aithmetic, and presumably logical, operation on two values, any values
> smaller than "int" are promoted to type int before the operation takes place.
> I
> believe the exact rules for this are in the C specs e.g. C99.
>
Yes, but I would have thought that assignment was included in the list of
logical operations for that promotion to occur. The above change seems to
suggest it isn't, which is why I'm asking. C99 specifies |= explicitly as a
type of assignment operator (see 6.5.16 here:
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
)
So I would presume that using = should work exactly the same as |= in terms of
type promotion. We also don't get this warning on gcc, which concerns me that
we might just be papering over a compiler problem here.
Looking at the error, its complaining that we're truncating an int value to a
bitfield (which we are), and that the resultant value is 127 rather that -1
(which it would be if we actually intended to treat it as an integer
Which I think is where the problem lies. That is to say we've typed the
bitfields in ixgbe_tx_offload as uint64_t. I'm guessing gcc just promotes ~0 to
an unsigned int during the assignment, and supresses the warning (unless you
turn on -pedantic or some such), but clang does not. The correct solution I
think here is to either:
1) modify the bitfield types so that they are signed integers, thereby
maintaining the resultant value of -1 after the assignment
or
2) Modify the ~0 to be ~0UL, so that the clang compiler sees that the resultant
value will be MAXLONG after the assignment
I'd think operation 2 would be the better choice
Neil
> /Bruce
>
> > > I would avoid to create a macro. What do you think?
> > >
> > > Regards,
> > > Olivier
> > >
>
[dpdk-dev] [BUG] ixgbe vector cannot compile without bulk alloc
2014-12-01 17:18, Bruce Richardson: > On Mon, Dec 01, 2014 at 06:10:18PM +0100, Thomas Monjalon wrote: > > These 2 configuration options are incompatible: > > CONFIG_RTE_LIBRTE_IXGBE_RX_ALLOW_BULK_ALLOC=n > > CONFIG_RTE_IXGBE_INC_VECTOR=y > > Building this config gives this error: > > lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:69:24: > > error: ?struct igb_rx_queue? has no member named ?fake_mbuf? > > > > I'd like a confirmation that it will be always incompatible. > > Thanks > > Hi Thomas, > > I don't think these options should always be incompatible, though as you point > out you do need to turn on bulk alloc support in order to use the vector PMD. > Why do you ask? There are no immediate plans to remove the dependency on our > end. I think the compilation shouldn't fail without a proper message. In order to distinguish a real compilation error from an incompatibility, we should add a warning in the makefile. Ideally, the build system should handle dependencies. But waiting this ideal time, a warning would be graceful. -- Thomas
[dpdk-dev] Fwd: Avoid vlan tag stripped with I350 VF on VM
My application on a VM needs to deal with multiple VLANS on packets
received over I350 using Virtual Function. But I always see the received
packets without vlan tag.
This is my setup:
- host: 3.13.6-031306-generic
- guest: 2.6.32-358.el6.x86_64
- dpdk: 1.6
And this is how I set up in the VM:
---
memset(&port_conf, 0, sizeof(port_conf));
if (vlanCnt > 0)
port_conf.rxmode.hw_vlan_filter = 1;
port_conf.rxmode.jumbo_frame = 1;
port_conf.rxmode.max_rx_pkt_len = 9018;
ret = rte_eth_dev_configure(port, 1, 1, &port_conf);
if (ret < 0) {
rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
ret=%d\n",
(unsigned)port, ret);
return -1;
}
for(i = 0; i < vlanCnt; i++) {
ret = rte_eth_dev_vlan_filter(port, vlan[i], 1);
if (ret < 0) {
rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "Error on config port%u,
vlan%d ret=%d\n",
(unsigned)port, vlan[i], ret);
return -1;
}
}
-
If I also try to explicitly disable the stripping with next, but get an
error return -ENOSUP.
ret = rte_eth_dev_set_vlan_strip_on_queue(port, 0, 0);
I appreciate anyone can help. on how to set it up.
Thanks,
Shian Wong
[dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
On Mon, Dec 01, 2014 at 10:09:38AM +0100, Olivier MATZ wrote:
> Hi Bruce, Hi Neil,
>
> On 11/30/2014 02:05 AM, Neil Horman wrote:
> > On Fri, Nov 28, 2014 at 03:31:00PM +, Bruce Richardson wrote:
> >> When compiling with clang, errors were being emitted due to truncation
> >> of values when assigning to the tx_offload_mask bit fields.
> >>
> >> dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit
> >> truncation from 'int' to bitfield changes value from -1 to 127
> >> [-Wbitfield-constant-conversion]
> >>tx_offload_mask.l2_len = ~0;
> >>
> >> The fix proposed here is to define a static const value of the same type
> >> with all fields set to 1s, and use that instead of constants for assigning
> >> to.
> >>
> >> Other options would be to explicitily define the suitable constants that
> >> would not truncate for each individual field e.g. 0x7f for l2_len, 0x1FF
> >> for l3_len, etc., but this solution here has the advantage that it works
> >> without any changes to values if the field sizes are ever modified.
> >>
> >> Signed-off-by: Bruce Richardson
> >> ---
> >> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++--
> >> 1 file changed, 15 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> index 8559ef6..4f71194 100644
> >> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> >> @@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
> >>volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
> >>uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
> >> {
> >> + static const union ixgbe_tx_offload offload_allones = { .data = ~0 };
> > Do you want to make this a static data structure? If you make it a macro
> > like
> > this:
> > #define ALLONES {.data = ~0}
> > Then you save the extra data space in the .data area (not that its that
> > much),
> > and you can define it in a header file and use it in multiple c files (if
> > you
> > need to)
>
> I found that the following code works:
>
> tx_offload_mask.l2_len |= ~0;
>
> (note the '|=' instead of '=')
>
How exactly does this work? does the or operator imply some level of type
promotion that the assignment doesn't to avoid the truncation?
Neil
> I would avoid to create a macro. What do you think?
>
> Regards,
> Olivier
>
[dpdk-dev] [PATCH] kni: create KNI interface in current network namespace
> 2014-11-21 12:10, Takayuki Usui: > > With this patch, KNI interface (e.g. vEth0) is created in the network > > namespace where the DPDK application is running. > > Otherwise, all interfaces are created in the default namespace in the > > host. > > > > Signed-off-by: Takayuki Usui > > --- > > lib/librte_eal/linuxapp/kni/kni_misc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c > > b/lib/librte_eal/linuxapp/kni/kni_misc.c > > index ba6..f4a9965 100644 > > --- a/lib/librte_eal/linuxapp/kni/kni_misc.c > > +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c > > @@ -354,6 +354,8 @@ kni_ioctl_create(unsigned int ioctl_num, unsigned > long ioctl_param) > > return -EBUSY; > > } > > > > + dev_net_set(net_dev, get_net_ns_by_pid(current->pid)); > > + Another way to get it done is by the following. It will be init_net for the root container. #ifdef CONFIG_NET_NS net_dev->nd_net = current->nsproxy->net_ns; #endif > > kni = netdev_priv(net_dev); > > > > kni->net_dev = net_dev;
[dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields
> -Original Message- > From: Ananyev, Konstantin > Sent: Sunday, November 30, 2014 10:51 PM > To: Olivier MATZ; Liu, Jijiang > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change > three fields > > Hi Olver, > > > -Original Message- > > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > > Sent: Friday, November 28, 2014 10:46 AM > > To: Ananyev, Konstantin; Liu, Jijiang > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and > > change three fields > > > > Hi Konstantin, > > > > On 11/27/2014 06:01 PM, Ananyev, Konstantin wrote: > > >> Yes, I think it could be done that way too. > > >> Though I still prefer to keep l4tun_len - it makes things a bit cleaner > > >> (at least > to me). > > >> After all we do have space for it in mbuf's tx_offload. > > > > > > As one more thing in favour of separate l4tun_len field: > > > l2_len is 7 bit long, so in theory it might be not enough, as for FVL: > > > 12:18 L4TUNLEN L4 Tunneling Length (Teredo / GRE header / VXLAN header) > defined in Words. > > > > The l2_len field is 7 bits long because it was mapped to ixgbe hardware. > > If it's not enough (although I'm not sure it's possible to have a > > header larger than 128 bytes in this case), it's probably because we > > should not have been doing that. > > Maybe these generic fields should be generic :) If it's not enough, > > what about changing l2_len to 8 bits? > > > > Often in the recent discussions, I see as an argument "fortville needs > > this so we need to add it in the mbuf". I agree that currently > > fortville is the only hardware supported for the new features, so it > > can make sense to act like this, but we have to accept to come back to > > this API in the future if it makes less sense with other drivers. > > > > Also, application developers can be annoyed to see that the mbuf flags > > and meta data are just duplicating information that is already present > > in the packet. > > > > About the l4tun_len, it's another field the application has to fill, > > but it's maybe cleaner. I just wanted to clarify why I'm discussing > > these points. > > After another thought, I think that the way you proposed is a better one. > I gives us more flexibility: > let's say for now we'll keep both l2_len and outer_l2_len as 7 bit fields, > and upper > layer would have to: > mb->l2_len = eth_hdr_in + vxlan_hdr; A question, how to fill the mb->l2_len for IP in IP, IP in GRE tunneling packet that is no inner L2 header? What is the rule? Or you think it should be mb->l2_len = 0 + l4_tun_len; ?? > for VXLAN packets. > Then if in the future, we'll realise that 7 bit is not enough we can either: > - increase size of l2_len and outer_l2_len > - introduce new field (l4tun_len as we planned now) In both cases backward > compatibility wouldn't be affected. > From other side - if we'' introduce a new field now (l4tun_len), it would be > very > hard to get rid of it in the future. > So, I think we'd better follow your approach here. > > Thanks > Konstantin > > > > > > Regards, > > Olivier
[dpdk-dev] [PATCH] i40e: Use one bit flag for all hardware detected RX packet errors
Hi Olivier > -Original Message- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > Sent: Friday, November 28, 2014 4:48 PM > To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org > Cc: Cao, Waterman; Cao, Min > Subject: Re: [PATCH] i40e: Use one bit flag for all hardware detected RX > packet > errors > > Hi Helin, > > On 11/28/2014 09:07 AM, Zhang, Helin wrote: > > After I have completed another task, I read the datasheet carefully > > again. For those 5 error bits I introduced for a long time, I'd like to > > explain one > by one as below. > > > > #define PKT_RX_EIP_CKSUM_BAD (0ULL << 0) /**< External IP header > > checksum error. */ [Helin] Nobody complains it, so we will keep it there, > > and > just assign a new value to it. > > ok. > > But it would be nice to have a better definition of this flag: does external > mean > outer header? For instance, when you receive a > Ether/IP1/UDP/vxlan/Ether/IP2/xxx, does the flag concerns IP1 or IP2? 'E' means 'external', it indicates the (most) outer IP header checksum error. If you don't think this name is not so clear, I can change it to 'PKT_RX_OUTER_IP_CHSUM_BAD'. For inner IP header checksum error, it will be indicated by PKT_RX_IP_CKSUM_BAD. > > If it's IP1, it's really strange compared to the current behavior (the flag > PKT_RX_IP_CKSUM_BAD refers to IP1). > > > #define PKT_RX_OVERSIZE (0ULL << 0) /**< Num of desc of an RX pkt > oversize. */ > > [Helin] I don't think it can be merge with other hardware errors. It > > indicates the packet received needs more descriptors than hardware > > allowed, and the part of packets can still be stored in the mbufs > > provided. It is a good hint for users that larger size of mbuf might > > be needed. If just put it as hardware error, users will lose this > > information. So I > prefer to keep it there, and just assign a new value to it. > > Again, a statistic counter would do the job which if it's just to provide a > hint to the > application. It seems that we do not maintain a counter for packets in PMD, if I am not wrong. Two ways current DPDK is using. One is hardware provide registers to do that, we can read it directly when needed. The other one is that applications or middle layer sw maintain its own statistics. > > I wonder in which case this flag can happen. If you fill the ring with mbufs > that are > large enough compared to your ethernet network, this should not happen in > normal conditions. I really don't believe that an application receiving an > mbuf > with this flag would stop the driver, then refill the rings it with larger > mbufs. This is not because of it is lack of available RX descriptors. It is because of a hardware requirement. FVL hardware requires that it should not use more than 5 rx descriptors for receiving a single packet. > Last but not least: If it's really useful, should we have the same behavior > on other > drivers like ixgbe? I think we really need to care about not having different > ways > to use the different drivers. I don't see the similar bit in ixgbe datasheet, but this restriction could be common for some other NICs, as it is reasonable from hardware perspective. > > To me, the only argument in favor of keeping this flag is when the mbuf > contains > a part of the data that could be dumped by a user for debug purposes. > > > #define PKT_RX_HBUF_OVERFLOW (0ULL << 0) /**< Header buffer overflow. > > */ [Helin] It indicates the header buff size is not enough, but not > > means hardware cannot process the packet received. It is a good hint > > for the users to provide larger size of header buffers. I also prefer to > > keep it > there, and just assign new value to it. > > Same for this one. It is a bit different from previous one, it always has one header buffer, this flag means the buffer size is not enough for the header. These two flags are because of buffer size or number of buffers. The mbufs are prepared in application or up layer software. If these two flags occur, it is easier for up layer software to debug, and know different buffers are needed. They do not need to debug PMD, as they generally don't want to do. > > > #define PKT_RX_RECIP_ERR (0ULL << 0) /**< Hardware processing error. > */ > > [Helin] In the latest data sheet, it is not opened to external users. > > So we can just remove it from here. > > ok > > > #define PKT_RX_MAC_ERR (0ULL << 0) /**< MAC error. */ > > [Helin] This indicates a real hardware error happens. > > And what is the content of the mbuf data in this case? Does the application > really > need an mbuf? Mbuf contains both the data and other information. I prefer to let the up layer software to decide how to deal with the packet, no matter it is correct or bad. In addition, even hardware errors happened, it still can set a special bit to enable storing the whole packet to the mbuf, for debug purpose. Hardware error bit can be used for all hardware errors. As we do
