DPDK usage discussions
 help / color / mirror / Atom feed
From: Jagan P <jagan2.p@altran.com>
To: Muhammad Zain-ul-Abideen <zain2294@gmail.com>
Cc: users <users@dpdk.org>
Subject: Re: [dpdk-users] DPDK support for vlan id 0
Date: Tue, 18 May 2021 06:47:31 +0000	[thread overview]
Message-ID: <MAXPR01MB32782D6B706F9BB4C2C89972DC2C9@MAXPR01MB3278.INDPRD01.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAN7yQ2pGc8nC8fO9R1_ViqV3jPUSxYdoyS4P9JD8zkqSSSBDfA@mail.gmail.com>

Please find the update below.

What NICs are you using? Now need to understand the NIC limitations if any.
>> The NIC we are using is “82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb".

Yes, for vlan0 don't set checksum calculation offload and insert via software but u won't get line rate for vlan0
>> Does this mean there is no support for vlan 0 in DPDK. Can this be achieved in DPDK as there will be a compromise in performance when done in software.

First thing first do you need checksum validation at reciever?
>> Actually we may not require checksum validation at receiver end. Checksum on transmission alone is fine. But could you please explain the reason behind this ask

Thanks,
Jagan P

From: Muhammad Zain-ul-Abideen <zain2294@gmail.com>
Sent: Tuesday, May 18, 2021 12:23 AM
To: Jagan P <jagan2.p@altran.com>
Cc: users <users@dpdk.org>
Subject: Re: [dpdk-users] DPDK support for vlan id 0

** This mail has been sent from an external source **

Good to hear. What NICs are you using? Now need to understand the NIC limitations if any.
Yes, for vlan0 don't set checksum calculation offload and insert via software but u won't get line rate for vlan0.. need to toy around a bit .
First thing first do you need checksum validation at reciever?

On Mon, May 17, 2021, 11:32 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote:
Thanks a lot Muhammad for your inputs.

We tried removing tx offloading in DPDK and now the packet is proper(IP control flag and UDP dest port values).
Attaching the packets for reference.

Should we change any flag settings in mbuf’s ol_flags for vlan id 0 since checksum offloading is proper for other vlans.

Following flags are set for ol_flags to offload checksum.
L3 checksum:
PKT_TX_IPV4 and PKT_TX_IP_CKSUM Flags.

L4 checksum:
PKT_TX_IPV4, PKT_TX_IP_CKSUM and PKT_TX_UDP_CKSUM for UDP packets.

With the above flags rte_ipv4_phdr_cksum API is triggered

Port config:
{link_speeds = 0, rxmode = {mq_mode = ETH_MQ_RX_NONE, max_rx_pkt_len = 9728, max_lro_pkt_size = 0, split_hdr_size = 0, offloads = 2, reserved_64s = {
      0, 0}, reserved_ptrs = {0x0, 0x0}}, txmode = {mq_mode = ETH_MQ_TX_NONE, offloads = 2, pvid = 0, hw_vlan_reject_tagged = 0 '\000',
    hw_vlan_reject_untagged = 0 '\000', hw_vlan_insert_pvid = 0 '\000', reserved_64s = {0, 0}, reserved_ptrs = {0x0, 0x0}}, lpbk_mode = 0, rx_adv_conf = {
   rss_conf = {rss_key = 0x0, rss_key_len = 0 '\000', rss_hf = 0}, vmdq_dcb_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 '\000',
      default_pool = 0 '\000', nb_pool_maps = 0 '\000', pool_map = {{vlan_id = 0, pools = 0} <repeats 64 times>}, dcb_tc = "\000\000\000\000\000\000\000"},
    dcb_rx_conf = {nb_tcs = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, vmdq_rx_conf = {nb_queue_pools = (unknown: 0),
      enable_default_pool = 0 '\000', default_pool = 0 '\000', enable_loop_back = 0 '\000', nb_pool_maps = 0 '\000', rx_mode = 0, pool_map = {{vlan_id = 0,
          pools = 0} <repeats 64 times>}}}, tx_adv_conf = {vmdq_dcb_tx_conf = {nb_queue_pools = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"},
    dcb_tx_conf = {nb_tcs = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, vmdq_tx_conf = {nb_queue_pools = (unknown: 0)}}, dcb_capability_en = 0,
  fdir_conf = {mode = RTE_FDIR_MODE_NONE, pballoc = RTE_FDIR_PBALLOC_64K, status = RTE_FDIR_NO_REPORT_STATUS, drop_queue = 0 '\000', mask = {
      vlan_tci_mask = 0, ipv4_mask = {src_ip = 0, dst_ip = 0, tos = 0 '\000', ttl = 0 '\000', proto = 0 '\000'}, ipv6_mask = {src_ip = {0, 0, 0, 0},
        dst_ip = {0, 0, 0, 0}, tc = 0 '\000', proto = 0 '\000', hop_limits = 0 '\000'}, src_port_mask = 0, dst_port_mask = 0,
      mac_addr_byte_mask = 0 '\000', tunnel_id_mask = 0, tunnel_type_mask = 0 '\000'}, flex_conf = {nb_payloads = 0, nb_flexmasks = 0, flex_set = {{
          type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {
          type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {
          type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {
          type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}},
      flex_mask = {{flow_type = 0, mask = '\000' <repeats 15 times>} <repeats 24 times>}}}, intr_conf = {lsc = 0, rxq = 0, rmv = 0}}

Thanks,
Jagan P


From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>>
Sent: Monday, May 17, 2021 8:59 PM
To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>>
Cc: users <users@dpdk.org<mailto:users@dpdk.org>>
Subject: Re: [dpdk-users] DPDK support for vlan id 0

** This mail has been sent from an external source **

Remove all offloading at any side!
U may set bytes of ipv4 flags to zero specially before sending out . And also remove any type of rx tx offloading.. and share the port config on dpdk

On Mon, May 17, 2021, 8:24 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote:
Please find the update below.
1) What are the trailing bytes at the end of UDP packets?
                >> Thank you will check it.

2) Are you reusing the buffer and/or initializing it correctly?
                >> Yes, we are re-using it. We are doing memset to zero of rte_mbuf’s buf_addr.

3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not)
                >> Yes, we are doing tx offloading. From the packet capture in wireshark, it looks like, IPV4 control flags and checksum are swapped for vlan 0 alone.

Try forcing these bytes zero before and after sending the packet to see the impact
                >> Sorry, I am not getting this point.  Which bytes you are referring to? You mean not to do offloading and to set .offloads as zero in rte_eth_conf?

Thanks,
Jagan P

From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>>
Sent: Monday, May 17, 2021 5:32 PM
To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>>
Cc: users@dpdk.org<mailto:users@dpdk.org>
Subject: Re: [dpdk-users] DPDK support for vlan id 0

** This mail has been sent from an external source **

Ok, it seems that there is some issue initializing the buffer and/or freeing it after use. It is not a DPDK issue not regenerated.
1) What are the trailing bytes at the end of UDP packets?
2) Are you reusing the buffer and/or initializing it correctly?
3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not)
Try forcing these bytes zero before and after sending the packet to see the impact


On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote:
Hi Muhammad,

We are using a single node connected to spirent Testcenter application(to send and receive traffic).
The dpdk version used is 20.05 version.

I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file).
We printed the packet in ixgbe_xmit_pkts API for vlan 0 and 12 and the captured dump is attached in “vlan_0 pkt_dump” file.

We are sending IP packet with vlan tag along with UDP header. The packet flow will be as below.
ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP lookup => egress port pkt forwarding(rte_eth_tx_burst).

We added packet dump before and after calling rte_eth_tx_burst API in our application. The dump looks good. So we added packet dump in ixgbe_xmit_pkts API as well to confirm whether the packet in proper in driver and the packet is proper here as well.

We are not sure why the IP control flags and UDP dest port values are modified. Should we handle anything specifically for packets with vlan id 0 in rte_mbuf structure?

Please share us your thoughts on this.
Please let us know if any details are needed further.

Thanks,
Jagan P

From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>>
Sent: Monday, May 17, 2021 2:16 PM
To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>>
Cc: users@dpdk.org<mailto:users@dpdk.org>
Subject: Re: [dpdk-users] DPDK support for vlan id 0

** This mail has been sent from an external source **

Kindly tell us more about the setup and which dpdk you are using. and what is the packet life at sender and receiver.




On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote:
Hi,
We were trying to forward packets with vlan id as 0. But the packet is getting altered when we do so.
The IP flag and the destination port fields are getting changed. We doubt if this is happening in DPDK because till the rte_eth_tx_burst API, the packet is proper.
But the packet captured at the destination is altered.
Could you please let us know if there is support in DPDK for forwarding packet with vlan id 0 or if we are missing something.

Packet at rte_eth_tx_burst:
dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304
  pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, ptype=0x211
  segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1
  Dump data at [0x1706dae04], len=200
00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | ................
00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | ..E.......?.....
00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | ......b.b.......
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
000000C0: 00 00 00 00 00 00 00 00

Packet captured at spirent(destination):
00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00
08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02
02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


Thanks,
Jagan P

=====================================================
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=====================================================
=====================================================
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=====================================================
=====================================================
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=====================================================
=====================================================
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=====================================================
=====================================================
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=====================================================

  reply	other threads:[~2021-05-20  8:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 15:40 Jagan P
2021-05-17  8:45 ` Muhammad Zain-ul-Abideen
2021-05-17 11:45   ` Jagan P
2021-05-17 12:02     ` Muhammad Zain-ul-Abideen
2021-05-17 15:24       ` Jagan P
2021-05-17 15:28         ` Muhammad Zain-ul-Abideen
2021-05-17 18:32           ` Jagan P
2021-05-17 18:52             ` Muhammad Zain-ul-Abideen
2021-05-18  6:47               ` Jagan P [this message]
2021-05-18  8:46                 ` Muhammad Zain-ul-Abideen

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=MAXPR01MB32782D6B706F9BB4C2C89972DC2C9@MAXPR01MB3278.INDPRD01.PROD.OUTLOOK.COM \
    --to=jagan2.p@altran.com \
    --cc=users@dpdk.org \
    --cc=zain2294@gmail.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).