From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B7C1BA0A02 for ; Tue, 18 May 2021 10:47:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 376134068E; Tue, 18 May 2021 10:47:03 +0200 (CEST) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by mails.dpdk.org (Postfix) with ESMTP id 8746A40041 for ; Tue, 18 May 2021 10:47:01 +0200 (CEST) Received: by mail-qt1-f181.google.com with SMTP id f8so6880591qth.6 for ; Tue, 18 May 2021 01:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eM7Frv4sDARkAWNlxRdtrVf8XHbIYMJ8eeLScIBW20E=; b=Yyg9g1BI2SvCt2AYxeE72TRfW8Nqo/m3p8vLlDNYENpaug4k540mxfeOU+92WYka+z DlS9RRvUrqQo3CCpfLIqcKZlPsomYMOHAajcK82KtaBAiLLZO1okmbHeH52CUVJAIq49 YbkIrZt97TBjdzyIP0uj5p6Ggn68qj3xvEg7ArEAAW/NhBO2cir15svSeeLlMtfwCprJ nKMLb+4EVXNmDAANB9T9EiKUbRcf/OCQ/Z6a3njOJBV36GSjPDKx5ygcyfe8g+Bdw+o1 Ws+zUsIJXe0hZ6KmhNtJoKCwkjIQLw3qTl00kM3MYhJ4wJyFdTW/hrVS9fmv0xSTpEKn 1HYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eM7Frv4sDARkAWNlxRdtrVf8XHbIYMJ8eeLScIBW20E=; b=TWFwmHbVfjCu8Vwa8YVf6wZ3vT/X60NZyXAOI4o17q9lFG35EWUPWx7Ba/Tqzx9Dl4 +lScVT1nb9p/CCwrchemN4lwxayprAdCLNavg7hW3EqUyeP5khlikwELpM5OO8/p2gCe 9fHgGbygNr7KXXm4w+7z0vd1MKDc+/bFJee2gIWT/ilGq7pobCVrSaoJ+dxWt5IrIDgI 27QiTDjPiLXWvSV0MfpPF71kl6mY+ZiNt8/PYmqpdO0AmRD5VmzKmvmA4JzpiGxtaV0d UdtDTdQ6KnRJ+gKU9BEFfUae6yKs0haidKZ/ZOl8XCiwUcvVf36nlZMAIm8lXJjqz/Yf OabQ== X-Gm-Message-State: AOAM531gAH7ND6wQEOpU8PD9pjxnKfaO0GL/25CbzEwIdJELpDhuQIll yagz7FIwW9fyelQi/NBVQG0io6+gBb1PYCTpIoQ= X-Google-Smtp-Source: ABdhPJwF8xfSYQZMhrcv9vRwtS0yR32IyxAsxkXQVq7OyWqQ0aZcuhSVjfcXkW3iYDcCD/3AbA1nNxzeLHSsKifnKGA= X-Received: by 2002:ac8:45c2:: with SMTP id e2mr3817697qto.138.1621327620689; Tue, 18 May 2021 01:47:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Zain-ul-Abideen Date: Tue, 18 May 2021 13:46:50 +0500 Message-ID: To: Jagan P Cc: users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-users] DPDK support for vlan id 0 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" 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 wrote: > Please find the update below. > > > > What NICs are you using? Now need to understand the NIC limitations if an= y. > > >> The NIC we are using is =E2=80=9C*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 i= n > 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 > *Sent:* Tuesday, May 18, 2021 12:23 AM > *To:* Jagan P > *Cc:* users > *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 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=E2=80=99s 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 =3D 0, rxmode =3D {mq_mode =3D ETH_MQ_RX_NONE, max_rx_pkt_le= n =3D > 9728, max_lro_pkt_size =3D 0, split_hdr_size =3D 0, offloads =3D 2, reser= ved_64s > =3D { > > 0, 0}, reserved_ptrs =3D {0x0, 0x0}}, txmode =3D {mq_mode =3D > ETH_MQ_TX_NONE, offloads =3D 2, pvid =3D 0, hw_vlan_reject_tagged =3D 0 '= \000', > > hw_vlan_reject_untagged =3D 0 '\000', hw_vlan_insert_pvid =3D 0 '\000= ', > reserved_64s =3D {0, 0}, reserved_ptrs =3D {0x0, 0x0}}, lpbk_mode =3D 0, > rx_adv_conf =3D { > > rss_conf =3D {rss_key =3D 0x0, rss_key_len =3D 0 '\000', rss_hf =3D 0}= , > vmdq_dcb_conf =3D {nb_queue_pools =3D (unknown: 0), enable_default_pool = =3D 0 > '\000', > > default_pool =3D 0 '\000', nb_pool_maps =3D 0 '\000', pool_map =3D > {{vlan_id =3D 0, pools =3D 0} }, dcb_tc =3D > "\000\000\000\000\000\000\000"}, > > dcb_rx_conf =3D {nb_tcs =3D (unknown: 0), dcb_tc =3D > "\000\000\000\000\000\000\000"}, vmdq_rx_conf =3D {nb_queue_pools =3D (un= known: > 0), > > enable_default_pool =3D 0 '\000', default_pool =3D 0 '\000', > enable_loop_back =3D 0 '\000', nb_pool_maps =3D 0 '\000', rx_mode =3D 0, = pool_map > =3D {{vlan_id =3D 0, > > pools =3D 0} }}}, tx_adv_conf =3D > {vmdq_dcb_tx_conf =3D {nb_queue_pools =3D (unknown: 0), dcb_tc =3D > "\000\000\000\000\000\000\000"}, > > dcb_tx_conf =3D {nb_tcs =3D (unknown: 0), dcb_tc =3D > "\000\000\000\000\000\000\000"}, vmdq_tx_conf =3D {nb_queue_pools =3D (un= known: > 0)}}, dcb_capability_en =3D 0, > > fdir_conf =3D {mode =3D RTE_FDIR_MODE_NONE, pballoc =3D RTE_FDIR_PBALLO= C_64K, > status =3D RTE_FDIR_NO_REPORT_STATUS, drop_queue =3D 0 '\000', mask =3D { > > vlan_tci_mask =3D 0, ipv4_mask =3D {src_ip =3D 0, dst_ip =3D 0, tos= =3D 0 > '\000', ttl =3D 0 '\000', proto =3D 0 '\000'}, ipv6_mask =3D {src_ip =3D = {0, 0, 0, > 0}, > > dst_ip =3D {0, 0, 0, 0}, tc =3D 0 '\000', proto =3D 0 '\000', hop= _limits > =3D 0 '\000'}, src_port_mask =3D 0, dst_port_mask =3D 0, > > mac_addr_byte_mask =3D 0 '\000', tunnel_id_mask =3D 0, tunnel_type_= mask > =3D 0 '\000'}, flex_conf =3D {nb_payloads =3D 0, nb_flexmasks =3D 0, flex= _set =3D {{ > > type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, {type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, { > > type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, {type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, { > > type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, {type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, { > > type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}, {type =3D RTE_ETH_PAYLOAD_UNKNOWN, src_offset =3D {0 times>}}}, > > flex_mask =3D {{flow_type =3D 0, mask =3D '\000' = } > }}}, intr_conf =3D {lsc =3D 0, rxq =3D 0, rmv =3D 0}} > > > > Thanks, > > Jagan P > > > > > > *From:* Muhammad Zain-ul-Abideen > *Sent:* Monday, May 17, 2021 8:59 PM > *To:* Jagan P > *Cc:* users > *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 d= pdk > > > > On Mon, May 17, 2021, 8:24 PM Jagan P 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 o= f > rte_mbuf=E2=80=99s 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 > *Sent:* Monday, May 17, 2021 5:32 PM > *To:* Jagan P > *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 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 =E2=80=93 vlan_12_18_static fi= le). > > We printed the packet in *ixgbe_xmit_pkts* API for vlan 0 and 12 and the > captured dump is attached in =E2=80=9Cvlan_0 pkt_dump=E2=80=9D 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) =3D> firewall =3D>routing=3D> nhop lookup = =3D>ARP > lookup =3D> 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 > *Sent:* Monday, May 17, 2021 2:16 PM > *To:* Jagan P > *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 wha= t > is the packet life at sender and receiver. > > > > > > > > > > On Mon, May 17, 2021 at 1:01 PM Jagan P 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=3D0x1706dad80, buf_len=3D2304 > pkt_len=3D252, ol_flags=3D0xf0000000000181, nb_segs=3D1, port=3D0, vlan= _tci=3D0, > ptype=3D0x211 > segment at 0x1706dad00, data=3D0x1706dae04, len=3D252, off=3D132, refcn= t=3D1 > Dump data at [0x1706dae04], len=3D200 > 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 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>