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: Mon, 17 May 2021 20:28:59 +0500	[thread overview]
Message-ID: <CAN7yQ2o-Z6yN=mun7rxAFPgZC0cg+R97gyohrazwNVfAWt6_xg@mail.gmail.com> (raw)
In-Reply-To: <MAXPR01MB327890A63FAA27FF34CF057BDC2D9@MAXPR01MB3278.INDPRD01.PROD.OUTLOOK.COM>

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.
> =====================================================
>

  reply	other threads:[~2021-05-17 15:29 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 [this message]
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

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='CAN7yQ2o-Z6yN=mun7rxAFPgZC0cg+R97gyohrazwNVfAWt6_xg@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
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).