I've suggested 2 ways to do it 1. Data path enforcement by pcap pmd [PATCH v4] http://patches.dpdk.org/project/dpdk/patch/20220606162147.57218-1-...@cgstowernetworks.com/ 2. Control path only sets the underlying OS network interface MTU [PATCH v8] http://patches.dpdk.org/project/dpdk/cover/20220620083944.51517-1-...@cgstowernetworks.com/
It was pretty long ago - not sure which is in favor > -----Original Message----- > From: Stephen Hemminger <step...@networkplumber.org> > Sent: Wednesday, 5 July 2023 18:19 > To: Ferruh Yigit <ferruh.yi...@amd.com> > Cc: dev@dpdk.org; Ido Goshen <i...@cgstowernetworks.com> > Subject: Re: [PATCH v2] pcap: support MTU set > > On Wed, 5 Jul 2023 12:37:41 +0100 > Ferruh Yigit <ferruh.yi...@amd.com> wrote: > > > On 7/4/2023 10:02 PM, Stephen Hemminger wrote: > > > Support rte_eth_dev_set_mtu for pcap driver when the pcap device is > > > convigured to point to a network interface. > > > > > > This is rebased an consolidated from earlier version. > > > Added support for FreeBSD. > > > > > > > As far as I understand motivation is to make pcap PMD behave close the > > physical NIC and able to test the application MTU feature. > > If so, Ido's v4 was simpler, which doesn't distinguish if pcap backed > > by physical interface or .pcap file. > > What was wrong with that approach? > > I started with Ido's patch, then: > - combined the two patches into one. > - fixed the error handling (propogate errno correctly) > - add missing freebsd support > > Normally would just give feedback but patch was so old not sure if it was > stuck and unlikely to get merged.
