From: Nitin Katiyar <nitin.katiyar@ericsson.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] Issue with MTU/max_rx_pkt_len handling by different NICs/PMD drivers
Date: Tue, 24 Oct 2017 12:25:38 +0000 [thread overview]
Message-ID: <AM4PR07MB3300BBEE585BB8E6352DD12B8E470@AM4PR07MB3300.eurprd07.prod.outlook.com> (raw)
Hi,
While testing MTU configuration of physical ports using OVS-DPDK we have found that Fortville and Niantic behaves differently for Tagged packets. Both allows TX of packets with size up to programmed MTU value but in receive direction Fortville drops packets of size equal to configured MTU. Additionally, Fortville does not report any error/drop counter if packets with size more than configured MTU (max frame size) are received. In Niantic we can see error counters getting incremented if packets of size more than MTU are received.
When ports are started, device attribute max_rx_pkt_len is set during device/queue init by application (OVS in our case) and this max_rx_pkt_len is used to program hardware register in device which in turn determines the maximum size of packet/frame that it can receive.
What we have found during testing is that Niantic could receive tagged/untagged packets of size equal to max_rx_pkt_len but Fortville could only receive tagged packets (single tag) up to size <= (max_rx_pkt_len - 4). Datasheet of Niantic mentions that device implicitly accounts for VLAN tag(s) in addition to Maximum Frame size programmed which is not the case for Fortville. This causes issue with MTU settings and maximum frame size that NIC can receive with tagged and untagged traffic.
We have tested it with OVS-DPDK where it uses device attribute max_rx_pkt_len to set max frame size in accordance with the configured MTU size of port. However, Ixgbe (Niantic) and i40e (Fortville) interpret it differently. I looked at some other PMD drivers and different drivers interpret dev_conf.rxmode.max_rx_pkt_len differently i.e. some adds one or two VLAN, few don't include it and some use this field differently. It creates issue with MTU while running same application on different NICs and PMD drivers need to be fixed to have consistent behavior with MTU/Max Frame Size settings.
Regards,
Nitin Katiyar
next reply other threads:[~2017-10-24 12:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 12:25 Nitin Katiyar [this message]
2017-10-24 13:01 ` Stephen Hemminger
2017-10-25 6:26 ` Nitin Katiyar
2017-11-15 5:12 ` Nitin Katiyar
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=AM4PR07MB3300BBEE585BB8E6352DD12B8E470@AM4PR07MB3300.eurprd07.prod.outlook.com \
--to=nitin.katiyar@ericsson.com \
--cc=dev@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).