From: "Johnson, Brian" <brian.johnson@intel.com>
To: Mike DeVico <mdevico@xcom-labs.com>,
"Zhang, Xiao" <xiao.zhang@intel.com>
Cc: "Christensen, ChadX M" <chadx.m.christensen@intel.com>,
Thomas Monjalon <thomas@monjalon.net>,
"users@dpdk.org" <users@dpdk.org>,
"Xing, Beilei" <beilei.xing@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
Tia Cassett <tiac@xcom-labs.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"Wong1, Samuel" <samuel.wong1@intel.com>,
"Chilikin, Andrey" <andrey.chilikin@intel.com>
Subject: Re: [dpdk-users] [dpdk-dev] Issue with DCB with X710 Quad 10Gb NIC
Date: Thu, 19 Sep 2019 14:34:00 +0000 [thread overview]
Message-ID: <B498CCEC867ED443ABEAFB7126B4CFEAE9D63E25@FMSMSX119.amr.corp.intel.com> (raw)
In-Reply-To: <98FF56E0-C2D0-498A-A366-90F4650DC08C@xcom-labs.com>
Feedback from our architecture team that might address this use case.
The deployment is using special fronthaul raw packets over Ethernet. Problem with such packets - they use standard 0x0800 Ethertype, so default parser fails to parse and validate IPv4. To fix this problem they have to use our FlexRAN DDP package for the Intel(R) Ethernet 700 Series.
Here is the link to the FlexRAN package
https://downloadcenter.intel.com/download/28938/Intel-Ethernet-Controller-X710-XXV710-XL710-Adapters-Dynamic-Device-Personalization-Radio-Fronthaul-4G
Brian Johnson
Solutions Architect / Ethernet Networking Division
-----Original Message-----
From: users <users-bounces@dpdk.org> On Behalf Of Mike DeVico
Sent: Thursday, September 19, 2019 6:34 AM
To: Zhang, Xiao <xiao.zhang@intel.com>
Cc: Christensen, ChadX M <chadx.m.christensen@intel.com>; Thomas Monjalon <thomas@monjalon.net>; users@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Tia Cassett <tiac@xcom-labs.com>; Wu, Jingjing <jingjing.wu@intel.com>; Wong1, Samuel <samuel.wong1@intel.com>
Subject: Re: [dpdk-users] [dpdk-dev] Issue with DCB with X710 Quad 10Gb NIC
Hi Xiao,
Thanks for looking into this!
So here’s the situation...
This is a raw Ethernet packet. No IP. This exact setup works fine with an 82599ES.
It looks like the hardware limitation with the x710 is the real problem. If we have to enable RSS to make it work and RSS requires a valid IP addr/port, then it’s a catch-22 for us unless there is something we can change in the driver to account for this.
Thanks!
—Mike
> On Sep 18, 2019, at 7:52 PM, Zhang, Xiao <xiao.zhang@intel.com> wrote:
>
> [EXTERNAL SENDER]
>
>> -----Original Message-----
>> From: Mike DeVico [mailto:mdevico@xcom-labs.com]
>> Sent: Thursday, September 19, 2019 9:23 AM
>> To: Christensen, ChadX M <chadx.m.christensen@intel.com>; Zhang, Xiao
>> <xiao.zhang@intel.com>; Thomas Monjalon <thomas@monjalon.net>
>> Cc: users@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Zhang, Qi Z
>> <qi.z.zhang@intel.com>; Richardson, Bruce
>> <bruce.richardson@intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Tia Cassett <tiac@xcom-labs.com>; Wu,
>> Jingjing <jingjing.wu@intel.com>; Wong1, Samuel
>> <samuel.wong1@intel.com>
>> Subject: Re: [dpdk-dev] Issue with DCB with X710 Quad 10Gb NIC
>>
>> As suggested I tried the following:
>>
>> I have an Intel FlexRAN FerryBridge broadcasting a packet 1/s which
>> looks like the following (sudo tcpdump -i p7p1 -xx):
>>
>> 0x0000: ffff ffff ffff 0000 aeae 0000 8100 4001
>> 0x0010: 0800 0009 0000 0000 0001 8086 3600 010f
>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
>> 0x0030: 0000 0000 0000 0000 0000 0000
>
> There is error in the packets as I checked with wireshark, could you try with normal packets?
>
> No issue with following packet as I tried:
> 0000 ff ff ff ff ff ff 00 40 05 40 ef 24 81 00 40 01
> 0010 08 00 45 00 00 34 3b 64 40 00 40 06 b7 9b 83 97
> 0020 20 81 83 97 20 15 04 95 17 70 51 d4 ee 9c 51 a5
> 0030 5b 36 80 10 7c 70 12 c7 00 00 01 01 08 0a 00 04
> 0040 f0 d4 01 99 a3 fd
>
>>
>> The first 12 bytes are the dest/src MAC address followed by the
>> 802.1Q Header
>> (8100 4001) If you crack this, the MS 16 bits are the TPID which is
>> set to 8100 by the Ferrybridge.
>> The next 16 bits (0x4001) make up the PCP bits [15:13], the DEI [12]
>> and the VID [11:0]. So if you crack the 0x4001 this makes the PCP 2
>> (010b), the DEI 0 and VID
>> 1 (000000000001b).
>>
>> Given this I expect the packets to but placed in Pool 1/Queue 2
>> (based on VID 1 and PCP 2).
>> However, when I run:
>>
>> ./vmdq_dcb_app -w 0000:05:00.0 -w 0000:05:00.1 -l 1 -- -p 3
>> --nb-pools 16 --nb- tcs 8 --enable-rss
>> EAL: Detected 24 lcore(s)
>> EAL: Detected 2 NUMA nodes
>> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
>> EAL: Probing VFIO support...
>> EAL: PCI device 0000:05:00.0 on NUMA socket 0
>> EAL: probe driver: 8086:1572 net_i40e
>> EAL: PCI device 0000:05:00.1 on NUMA socket 0
>> EAL: probe driver: 8086:1572 net_i40e
>> vmdq queue base: 64 pool base 1
>> Configured vmdq pool num: 16, each vmdq pool has 8 queues Port 0
>> modified RSS hash function based on hardware
>> support,requested:0x3bffc
>> configured:0x3ef8 Port 0 MAC: e8 ea 6a 27 b5 4d Port 0 vmdq pool 0
>> set mac
>> 52:54:00:12:00:00 Port 0 vmdq pool 1 set mac 52:54:00:12:00:01 Port 0
>> vmdq pool 2 set mac 52:54:00:12:00:02 Port 0 vmdq pool 3 set mac
>> 52:54:00:12:00:03 Port 0 vmdq pool 4 set mac 52:54:00:12:00:04 Port 0
>> vmdq pool 5 set mac
>> 52:54:00:12:00:05 Port 0 vmdq pool 6 set mac 52:54:00:12:00:06 Port 0
>> vmdq pool 7 set mac 52:54:00:12:00:07 Port 0 vmdq pool 8 set mac
>> 52:54:00:12:00:08 Port 0 vmdq pool 9 set mac 52:54:00:12:00:09 Port 0
>> vmdq pool 10 set mac 52:54:00:12:00:0a Port 0 vmdq pool 11 set mac
>> 52:54:00:12:00:0b Port 0 vmdq pool 12 set mac 52:54:00:12:00:0c Port
>> 0 vmdq pool 13 set mac 52:54:00:12:00:0d Port 0 vmdq pool 14 set mac
>> 52:54:00:12:00:0e Port 0 vmdq pool 15 set mac 52:54:00:12:00:0f vmdq
>> queue base: 64 pool base 1 Configured vmdq pool num: 16, each vmdq
>> pool has 8 queues Port 1 modified RSS hash function based on hardware
>> support,requested:0x3bffc configured:0x3ef8 Port
>> 1 MAC: e8 ea 6a 27 b5 4e Port 1 vmdq pool 0 set mac 52:54:00:12:01:00
>> Port 1 vmdq pool 1 set mac 52:54:00:12:01:01 Port 1 vmdq pool 2 set
>> mac
>> 52:54:00:12:01:02 Port 1 vmdq pool 3 set mac 52:54:00:12:01:03 Port 1
>> vmdq pool 4 set mac 52:54:00:12:01:04 Port 1 vmdq pool 5 set mac
>> 52:54:00:12:01:05 Port 1 vmdq pool 6 set mac 52:54:00:12:01:06 Port 1
>> vmdq pool 7 set mac
>> 52:54:00:12:01:07 Port 1 vmdq pool 8 set mac 52:54:00:12:01:08 Port 1
>> vmdq pool 9 set mac 52:54:00:12:01:09 Port 1 vmdq pool 10 set mac
>> 52:54:00:12:01:0a Port 1 vmdq pool 11 set mac 52:54:00:12:01:0b Port
>> 1 vmdq pool 12 set mac 52:54:00:12:01:0c Port 1 vmdq pool 13 set mac
>> 52:54:00:12:01:0d Port 1 vmdq pool 14 set mac 52:54:00:12:01:0e Port
>> 1 vmdq pool 15 set mac 52:54:00:12:01:0f Core 0(lcore 1) reading
>> queues 64-191
>>
>> <SIGHUP>
>>
>> Pool 0: 0 0 0 0 0 0 0 0
>> Pool 1: 119 0 0 0 0 0 0 0
>> Pool 2: 0 0 0 0 0 0 0 0
>> Pool 3: 0 0 0 0 0 0 0 0
>> Pool 4: 0 0 0 0 0 0 0 0
>> Pool 5: 0 0 0 0 0 0 0 0
>> Pool 6: 0 0 0 0 0 0 0 0
>> Pool 7: 0 0 0 0 0 0 0 0
>> Pool 8: 0 0 0 0 0 0 0 0
>> Pool 9: 0 0 0 0 0 0 0 0
>> Pool 10: 0 0 0 0 0 0 0 0
>> Pool 11: 0 0 0 0 0 0 0 0
>> Pool 12: 0 0 0 0 0 0 0 0
>> Pool 13: 0 0 0 0 0 0 0 0
>> Pool 14: 0 0 0 0 0 0 0 0
>> Pool 15: 0 0 0 0 0 0 0 0
>>
>> Even with --enable-rss, the packets are still being placed in VLAN
>> Pool 1/Queue 0 instead of VLAN Pool 1/Queue 2.
>>
>> As I mentioned in my original email, if I use an 82599ES (dual 10G
>> NIC), it all works as expected.
>>
>> What am I missing?
>> --Mike
>>
>> On 9/18/19, 7:54 AM, "Christensen, ChadX M"
>> <chadx.m.christensen@intel.com>
>> wrote:
>>
>> [EXTERNAL SENDER]
>>
>> Hi Mike,
>>
>> Did that resolve it?
>>
>> Thanks,
>>
>> Chad Christensen | Ecosystem Enablement Manager
>> chadx.m.christensen@intel.com | (801) 786-5703
>>
>> -----Original Message-----
>> From: Mike DeVico <mdevico@xcom-labs.com>
>> Sent: Wednesday, September 18, 2019 8:17 AM
>> To: Zhang, Xiao <xiao.zhang@intel.com>; Thomas Monjalon
>> <thomas@monjalon.net>
>> Cc: users@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Zhang,
>> Qi Z <qi.z.zhang@intel.com>; Richardson, Bruce
>> <bruce.richardson@intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Christensen, ChadX M
>> <chadx.m.christensen@intel.com>; Tia Cassett <tiac@xcom-labs.com>; Wu, Jingjing <jingjing.wu@intel.com>; Wong1, Samuel <samuel.wong1@intel.com>
>> Subject: Re: [dpdk-dev] Issue with DCB with X710 Quad 10Gb NIC
>>
>> Sure enough, I see it now. I'll give it a try.
>>
>> Thanks!!!
>> --Mike
>>
>> On 9/18/19, 12:11 AM, "Zhang, Xiao" <xiao.zhang@intel.com> wrote:
>>
>> [EXTERNAL SENDER]
>>
>>> -----Original Message-----
>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>> Sent: Wednesday, September 18, 2019 3:03 PM
>>> To: Zhang, Xiao <xiao.zhang@intel.com>
>>> Cc: Mike DeVico <mdevico@xcom-labs.com>; users@dpdk.org; Xing,
>> Beilei
>>> <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
>>> Richardson,
>> Bruce
>>> <bruce.richardson@intel.com>; Ananyev, Konstantin
>>> <konstantin.ananyev@intel.com>; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; Christensen, ChadX M
>>> <chadx.m.christensen@intel.com>; Tia Cassett <tiac@xcom-labs.com>;
>>> Wu, Jingjing <jingjing.wu@intel.com>
>>> Subject: Re: [dpdk-dev] Issue with DCB with X710 Quad 10Gb NIC
>>>
>>> 18/09/2019 09:02, Zhang, Xiao:
>>>>
>>>> There is some hardware limitation and need to enable RSS to
>>>> distribute
>>> packets for X710.
>>>
>>> Is this limitation documented?
>>
>> Yes, it's documented in doc/guides/nics/i40e.rst
>>
>> "DCB works only when RSS is enabled."
>>
>>>
>>
>>
>>
>>
>
next prev parent reply other threads:[~2019-09-19 14:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <834B2FF6-9FC7-43E4-8CA7-67D861FEE70E@xcom-tech.com>
[not found] ` <2953945.eKoDkclGR7@xps>
2019-09-17 18:54 ` Mike DeVico
2019-09-18 3:32 ` Zhang, Xiao
2019-09-18 4:20 ` Mike DeVico
2019-09-18 7:02 ` Zhang, Xiao
2019-09-18 7:03 ` Thomas Monjalon
2019-09-18 7:10 ` Zhang, Xiao
2019-09-18 14:17 ` Mike DeVico
2019-09-18 14:53 ` Christensen, ChadX M
2019-09-18 20:22 ` Mike DeVico
2019-09-19 1:23 ` Mike DeVico
2019-09-19 2:52 ` Zhang, Xiao
2019-09-19 13:34 ` Mike DeVico
2019-09-19 14:34 ` Johnson, Brian [this message]
[not found] ` <0BD0EAA3-BB16-4B09-BF25-4744C0A879A0@xcom-tech.com>
[not found] ` <b9318aa4f0a943958171cc6fc53a010f@sandvine.com>
[not found] ` <61798E93-724B-4BE6-A03C-63B274E71AD2@xcom-tech.com>
[not found] ` <F35DEAC7BCE34641BA9FAC6BCA4A12E71B4ADE0E@SHSMSX103.ccr.corp.intel.com>
2019-09-26 20:31 ` Mike DeVico
2019-09-30 2:21 ` Zhang, Helin
2019-10-03 23:56 ` Mike DeVico
2019-09-20 21:57 Mike DeVico
2019-10-10 21:23 ` Christensen, ChadX M
2019-10-10 21:25 ` Mike DeVico
2019-10-10 21:12 Mike DeVico
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B498CCEC867ED443ABEAFB7126B4CFEAE9D63E25@FMSMSX119.amr.corp.intel.com \
--to=brian.johnson@intel.com \
--cc=andrey.chilikin@intel.com \
--cc=beilei.xing@intel.com \
--cc=bruce.richardson@intel.com \
--cc=chadx.m.christensen@intel.com \
--cc=ferruh.yigit@intel.com \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=mdevico@xcom-labs.com \
--cc=qi.z.zhang@intel.com \
--cc=samuel.wong1@intel.com \
--cc=thomas@monjalon.net \
--cc=tiac@xcom-labs.com \
--cc=users@dpdk.org \
--cc=xiao.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).