dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: "Thomas Monjalon" <thomas@monjalon.net>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
	"matan@nvidia.com" <matan@nvidia.com>,
	"Qi Zhang" <qi.z.zhang@intel.com>,
	"Ajit Khaparde" <ajit.khaparde@broadcom.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Ray Kinsella" <mdr@ashroe.eu>,
	"Bruce Richardson" <bruce.richardson@intel.com>,
	"Damjan Marion (damarion)" <damarion@cisco.com>,
	"Roy Fan Zhang" <roy.fan.zhang@intel.com>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	"Min Hu (Connor)" <humin29@huawei.com>,
	"Konstantin Ananyev" <konstantin.ananyev@intel.com>,
	"Stokes, Ian" <ian.stokes@intel.com>,
	"David Marchand" <david.marchand@redhat.com>
Subject: MTU and frame size filtering inaccuracy
Date: Tue, 1 Mar 2022 17:50:16 +0000	[thread overview]
Message-ID: <e2554b78-cdda-aa33-ac6d-59a543a10640@intel.com> (raw)

Hi all,

There is a problem in MTU setting in DPDK.

In 'rte_eth_dev_configure()'and 'rte_eth_dev_set_mtu()', MTU is
converted to frame size.

Since L2 protocol header size changes based on what HW supports,
L2 overhead information get from PMD, but this still doesn't solve
the issue.

PMD reports max overhead based on what it supports, but there is
no way to know what will received packets have. Sample:

i40e has 26 bytes overhead: HRD_LEN + CRC_LEN + VLAN_LEN *2
when MTU set to 1500, configured frame size become 1526
When a packet received with no VLAN tag and 1504 bytes payload,
packet frame size is 1522 bytes and it is accepted.
So although MTU is set 1500 bytes, packet with 1504 bytes is accepted.

There is an inaccuracy in frame size filtering up to 8 bytes.


Damjan reported the same, and he has good point on the application
need (I hope it is OK to quote from his email):

1) information about the biggest l2 frame interface it can receive and send (1518,1522, 2000 or jumbo)
2) ability to ask hardware to help him with filtering oversized frames


We need to fix (2), I am not quite sure how, any comment is welcome.


-- 
Thanks,
ferruh

             reply	other threads:[~2022-03-01 17:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 17:50 Ferruh Yigit [this message]
2022-03-02  8:53 ` MTU and frame size filtering inaccuracy Morten Brørup
2022-03-02 16:21   ` Stephen Hemminger
2022-03-02 16:50     ` Morten Brørup
2022-03-02 17:40       ` Stephen Hemminger

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=e2554b78-cdda-aa33-ac6d-59a543a10640@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=damarion@cisco.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=humin29@huawei.com \
    --cc=ian.stokes@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=matan@nvidia.com \
    --cc=mb@smartsharesystems.com \
    --cc=mdr@ashroe.eu \
    --cc=qi.z.zhang@intel.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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).