On Wed, 27 Apr 2022 18:21:37 +0000 Ido Goshen <i...@cgstowernetworks.com> wrote:
> > From: Ferruh Yigit <ferruh.yi...@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.
