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

Irrespective of DPDK, this is a NIC feature as offloading is done at NIC
and as VLAN normally starts from 1, it may be a NIC issue when calculating
checksums. DPDK has no concept of protocols.
If you don't need the validation, then I guess you may be able to work
without any offloading

On Tue, May 18, 2021 at 11:47 AM Jagan P <jagan2.p@altran.com> wrote:

> 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> 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>
> *Sent:* Monday, May 17, 2021 8:59 PM
> *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 **
>
>
>
> 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> 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>
> *Sent:* Monday, May 17, 2021 5:32 PM
> *To:* Jagan P <jagan2.p@altran.com>
> *Cc:* 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> 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>
> *Sent:* Monday, May 17, 2021 2:16 PM
> *To:* Jagan P <jagan2.p@altran.com>
> *Cc:* 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> 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.
> =====================================================
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

      reply	other threads:[~2021-05-18  8:47 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
2021-05-18  8:46                 ` Muhammad Zain-ul-Abideen [this message]

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=CAN7yQ2q0tU+yqVemaTB_j10ptCvZSh3OY5QNNTHRPP8LWE90uw@mail.gmail.com \
    --to=zain2294@gmail.com \
    --cc=jagan2.p@altran.com \
    --cc=users@dpdk.org \
    /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

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ https://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git