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 <jagan...@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 <zain2...@gmail.com> > *Sent:* Tuesday, May 18, 2021 12:23 AM > *To:* Jagan P <jagan...@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 <jagan...@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 <zain2...@gmail.com> > *Sent:* Monday, May 17, 2021 8:59 PM > *To:* Jagan P <jagan...@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 <jagan...@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 <zain2...@gmail.com> > *Sent:* Monday, May 17, 2021 5:32 PM > *To:* Jagan P <jagan...@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 <jagan...@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 <zain2...@gmail.com> > *Sent:* Monday, May 17, 2021 2:16 PM > *To:* Jagan P <jagan...@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 <jagan...@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>