DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ido Goshen <Ido@cgstowernetworks.com>
Cc: Ferruh Yigit <ferruh.yigit@xilinx.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Danny Raveh <Danny@cgstowernetworks.com>
Subject: Re: [PATCH] net/pcap: support MTU set
Date: Wed, 27 Apr 2022 12:14:32 -0700	[thread overview]
Message-ID: <20220427121432.5dc81957@hermes.local> (raw)
In-Reply-To: <AS4PR09MB5525EC8C3533A0C397DB0254D6FA9@AS4PR09MB5525.eurprd09.prod.outlook.com>

On Wed, 27 Apr 2022 18:21:37 +0000
Ido Goshen <Ido@cgstowernetworks.com> wrote:

> > From: Ferruh Yigit <ferruh.yigit@xilinx.com>
> > Sent: Tuesday, 26 April 2022 20:04
> > 
> > On 3/22/2022 1:02 PM, Ido Goshen wrote:  
> > > This test
> > > https://doc.dpdk.org/dts/test_plans/jumboframes_test_plan.html#test-ca
> > > se-jumbo-frames-with-no-jumbo-frame-support fails for pcap pmd Jumbo
> > > packet is unexpectedly received and transmitted
> > >  
> > 
> > Hi Ido,
> > 
> > Yes, pcap ignores MTU, but I don't see why it should use MTU (except from
> > making above DTS test pass).
> > 
> > For the cases packets written to .pcap file or read from a .pcap file, most
> > probably user is interested in all packets, I don't think using MTU to filter the
> > packets is a good idea, missing packets (because of MTU) can confuse users.  
> 
> [idog] 
> receiving/sending unexpected packets may be confusing too (it is subjective)
> The rx-err counter should clarify it. More advanced PMDs also have a rx_oversize counter 
> but this will require xstats which seems an overkill.
> It is also out of bound memory access prone if app is not expecting segmented mbufs and 
> refers to data within mbuf->pkt_len which is beyond the 1st segment mbuf->data_len
> 
> As is there is no control, packets will pass whether one likes it or not
> This patch provides the control.
> If the current behaviour (not to drop) seems better then it can become the default
> i.e. auto set the initial mtu to 9K or 16K
> 
> > 
> > Unless there is a good use case, I am for rejecting this feature.  
> 
> [idog] 
> The main use case is for testing, which is probably the main reason for pcap pmd. 
> We support jumbo and mtu in our products but our pcap based CI tests cannot cover it.
> We also have a SW pcap based simulator which we’d like to behave the same as possible
> as our HW products.
> Is there a good reason that pcap pmd will behave different then other pmds?

Why not use existing tools to filter the pcap file before you feed it to CI tests?

Other drivers may (or may not) receive packets greater than MTU. It is really driver
and hardware dependent.

  reply	other threads:[~2022-04-27 19:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 17:43 ido g
2022-03-17 18:20 ` Stephen Hemminger
2022-03-17 19:11   ` Ido Goshen
2022-03-22 13:02     ` Ido Goshen
2022-04-26 17:03       ` Ferruh Yigit
2022-04-27 18:21         ` Ido Goshen
2022-04-27 19:14           ` Stephen Hemminger [this message]
2022-05-23  7:48             ` Ido Goshen
2022-05-30 10:36 ` [PATCH v3] pcap: " Ido Goshen
2022-05-30 18:05   ` Ferruh Yigit
2022-05-31 13:12     ` Ido Goshen
2022-06-06  9:40     ` Ido Goshen
2022-06-06 16:21 ` [PATCH v4] " Ido Goshen
2022-06-06 17:10   ` Stephen Hemminger
2022-06-06 19:07     ` Ido Goshen
2022-06-07  6:27 ` [PATCH v5] pcap: support MTU set for linux interafces Ido Goshen
2022-06-08 16:04   ` [PATCH v6] " Ido Goshen
2022-06-08 16:23     ` Stephen Hemminger
2022-06-19  9:30 ` [PATCH v7 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-19  9:30   ` [PATCH v7 1/3] " Ido Goshen
2022-06-19  9:30   ` [PATCH v7 2/3] pcap: support MTU set for linux interfaces TX enhancment Ido Goshen
2022-06-20 22:52     ` Stephen Hemminger
2022-06-21  9:07       ` Ido Goshen
2022-06-19  9:30   ` [PATCH v7 3/3] pcap: support MTU set for linux interfaces count ierrors Ido Goshen
2022-06-20  8:39 ` [PATCH v8 0/3] pcap: support MTU set for linux interfaces Ido Goshen
2022-06-20  8:39   ` [PATCH v8 1/3] " Ido Goshen
2022-06-20  8:39   ` [PATCH v8 2/3] pcap: support MTU set for linux interfaces TX enhancment Ido Goshen
2022-06-20  8:39   ` [PATCH v8 3/3] pcap: support MTU set for linux interfaces count ierrors Ido Goshen
2023-07-04 17:43 ` [PATCH] pcap: support MTU set Stephen Hemminger
2023-07-04 21:02 ` [PATCH v2] " Stephen Hemminger
2023-07-05 11:37   ` Ferruh Yigit
2023-07-05 15:18     ` Stephen Hemminger
2023-07-06 10:45       ` Ido Goshen
2023-07-10 16:45 ` [PATCH] net/pcap: " Stephen Hemminger
2023-07-10 17:46   ` Ferruh Yigit
2023-07-11  9:41     ` Ido Goshen

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=20220427121432.5dc81957@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=Danny@cgstowernetworks.com \
    --cc=Ido@cgstowernetworks.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@xilinx.com \
    /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).