From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> To: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Yang, SteveX" <stevex.yang@intel.com>, "Zhang, Qi Z" <qi.z.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Cc: "Zhao1, Wei" <wei.zhao1@intel.com>, "Guo, Jia" <jia.guo@intel.com>, "Yang, Qiming" <qiming.yang@intel.com>, "Wu, Jingjing" <jingjing.wu@intel.com>, "Xing, Beilei" <beilei.xing@intel.com>, "Stokes, Ian" <ian.stokes@intel.com> Subject: Re: [dpdk-dev] [PATCH v4 3/5] net/ice: fix max mtu size packets with vlan tag cannot be received by default Date: Wed, 21 Oct 2020 10:44:07 +0000 Message-ID: <BYAPR11MB330134118F72347D1EB0D10A9A1C0@BYAPR11MB3301.namprd11.prod.outlook.com> (raw) In-Reply-To: <2b14260d-5870-1c4a-2bda-6d35f88c62c3@intel.com> > >> On 10/20/2020 10:07 AM, Ananyev, Konstantin wrote: > >>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> testpmd will initialize default max packet length to 1518 which > >>>>>>>>>>>>>>>> doesn't include vlan tag size in ether overheader. Once, send the > >>>>>>>>>>>>>>>> max mtu length packet with vlan tag, the max packet length will > >>>>>>>>>>>>>>>> exceed 1518 that will cause packets dropped directly from NIC hw > >>>>>>>>>>>> side. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ice can support dual vlan tags that need more 8 bytes for max > >>>>>>>>>>>>>>>> packet size, so, configures the correct max packet size in > >>>>>>>>>>>>>>>> dev_config > >>>>>>>>>>>>> ops. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Fixes: 50cc9d2a6e9d ("net/ice: fix max frame size") > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Signed-off-by: SteveX Yang <stevex.yang@intel.com> > >>>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>>> drivers/net/ice/ice_ethdev.c | 11 +++++++++++ > >>>>>>>>>>>>>>>> 1 file changed, 11 insertions(+) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> diff --git a/drivers/net/ice/ice_ethdev.c > >>>>>>>>>>>>>>>> b/drivers/net/ice/ice_ethdev.c index > >>>>>>>>>>>>>>>> cfd357b05..6b7098444 100644 > >>>>>>>>>>>>>>>> --- a/drivers/net/ice/ice_ethdev.c > >>>>>>>>>>>>>>>> +++ b/drivers/net/ice/ice_ethdev.c > >>>>>>>>>>>>>>>> @@ -3146,6 +3146,7 @@ ice_dev_configure(struct rte_eth_dev > >>>>>>>>>> *dev) > >>>>>>>>>>>>>>>> struct ice_adapter *ad = > >>>>>>>>>>>>>>>> ICE_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private); > >>>>>>>>>>>>>>>> struct ice_pf *pf = > >>>>>>>>>>>>>>>> ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private); > >>>>>>>>>>>>>>>> +uint32_t frame_size = dev->data->mtu + ICE_ETH_OVERHEAD; > >>>>>>>>>>>>>>>> int ret; > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> /* Initialize to TRUE. If any of Rx queues doesn't meet the @@ > >>>>>>>>>>>>>>>> -3157,6 > >>>>>>>>>>>>>>>> +3158,16 @@ ice_dev_configure(struct rte_eth_dev *dev) > >>>>>>>>>>>>>>>> if (dev->data->dev_conf.rxmode.mq_mode & > >>>>>>>>>> ETH_MQ_RX_RSS_FLAG) > >>>>>>>>>>>>>>>> dev->data->dev_conf.rxmode.offloads |= > >>>>>>>>>>>>> DEV_RX_OFFLOAD_RSS_HASH; > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> +/** > >>>>>>>>>>>>>>>> + * Considering QinQ packet, max frame size should be equal or > >>>>>>>>>>>>>>>> + * larger than total size of MTU and Ether overhead. > >>>>>>>>>>>>>>>> + */ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> +if (frame_size > dev->data->dev_conf.rxmode.max_rx_pkt_len) { > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Why we need this check? > >>>>>>>>>>>>>>> Can we just call ice_mtu_set directly > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think that without that check we can silently overwrite provided > >>>>>>>>>>>>>> by user dev_conf.rxmode.max_rx_pkt_len value. > >>>>>>>>>>>>> > >>>>>>>>>>>>> OK, I see > >>>>>>>>>>>>> > >>>>>>>>>>>>> But still have one question > >>>>>>>>>>>>> dev->data->mtu is initialized to 1518 as default , but if > >>>>>>>>>>>>> dev->data->application set > >>>>>>>>>>>>> dev_conf.rxmode.max_rx_pkt_len = 1000 in dev_configure. > >>>>>>>>>>>>> does that mean we will still will set mtu to 1518, is this expected? > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> max_rx_pkt_len should be larger than mtu at least, so we should raise > >>>>>>>>>>>> the max_rx_pkt_len (e.g.:1518) to hold expected mtu value (e.g.: 1500). > >>>>>>>>>>> > >>>>>>>>>>> Ok, this describe the problem more general and better to replace exist > >>>>>>>>>> code comment and commit log for easy understanding. > >>>>>>>>>>> Please send a new version for reword > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I didn't really get this set. > >>>>>>>>>> > >>>>>>>>>> Application explicitly sets 'max_rx_pkt_len' to '1518', and a frame bigger than > >>>>>>>>>> this size is dropped. > >>>>>>>>> > >>>>>>>>> Sure, it is normal case for dropping oversize data. > >>>>>>>>> > >>>>>>>>>> Isn't this what should be, why we are trying to overwrite user configuration > >>>>>>>>>> in PMD to prevent this? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> But it is a confliction that application/user sets mtu & max_rx_pkt_len at the same time. > >>>>>>>>> This fix will make a decision when confliction occurred. > >>>>>>>>> MTU value will come from user operation (e.g.: port config mtu 0 1500) directly, > >>>>>>>>> so, the max_rx_pkt_len will resize itself to adapt expected MTU value if its size is smaller than MTU + Ether overhead. > >>>>>>>>> > >>>>>>>>>> During eth_dev allocation, mtu set to default '1500', by ethdev layer. > >>>>>>>>>> And testpmd sets 'max_rx_pkt_len' by default to '1518'. > >>>>>>>>>> I think Qi's concern above is valid, what is user set 'max_rx_pkt_len' to '1000' > >>>>>>>>>> and mean it? PMD will not honor the user config. > >>>>>>>>> > >>>>>>>>> I'm not sure when set 'mtu' to '1500' and 'max_rx_pkt_len' to '1000', what's the behavior expected? > >>>>>>>>> If still keep the 'max_rx_pkt_len' value, that means the larger 'mtu' will be invalid. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Why not simply increase the default 'max_rx_pkt_len' in testpmd? > >>>>>>>>>> > >>>>>>>>> The default 'max_rx_pkt_len' has been initialized to generical value (1518) and default 'mtu' is '1500' in testpmd, > >>>>>>>>> But it isn't suitable to those NIC drivers which Ether overhead is larger than 18. (e.g.: ice, i40e) if 'mtu' value is preferable. > >>>>>>>>> > >>>>>>>>>> And I guess even better what we need is to tell to the application what the > >>>>>>>>>> frame overhead PMD accepts. > >>>>>>>>>> So the application can set proper 'max_rx_pkt_len' value per port for a > >>>>>>>>>> given/requested MTU value. > >>>>>>>>>> @Ian, cc'ed, was complaining almost same thing years ago, these PMD > >>>>>>>>>> overhead macros and 'max_mtu'/'min_mtu' added because of that, perhaps > >>>>>>>>>> he has a solution now? > >>>>>>>> > >>>>>>>> From my perspective the main problem here: > >>>>>>>> We have 2 different variables for nearly the same thing: > >>>>>>>> rte_eth_dev_data.mtu and rte_eth_dev_data.dev_conf.max_rx_pkt_len. > >>>>>>>> and 2 different API to update them: dev_mtu_set() and dev_configure(). > >>>>>>> > >>>>>>> According API 'max_rx_pkt_len' is 'Only used if JUMBO_FRAME enabled' > >>>>>>> Although not sure that is practically what is done for all drivers. > >>>>>> > >>>>>> I think most of Intel PMDs use it unconditionally. > >>>>>> > >>>>>>> > >>>>>>>> And inside majority of Intel PMDs we don't keep these 2 variables in sync: > >>>>>>>> - mtu_set() will update both variables. > >>>>>>>> - dev_configure() will update only max_rx_pkt_len, but will keep mtu intact. > >>>>>>>> > >>>>>>>> This patch fixes this inconsistency, which I think is a good thing. > >>>>>>>> Though yes, it introduces change in behaviour. > >>>>>>>> > >>>>>>>> Let say the code: > >>>>>>>> rte_eth_dev_set_mtu(port, 1500); > >>>>>>>> dev_conf.max_rx_pkt_len = 1000; > >>>>>>>> rte_eth_dev_configure(port, 1, 1, &dev_conf); > >>>>>>>> > >>>>>>> > >>>>>>> 'rte_eth_dev_configure()' is one of the first APIs called, it is called before > >>>>>>> 'rte_eth_dev_set_mtu(). > >>>>>> > >>>>>> Usually yes. > >>>>>> But you can still do sometimes later: dev_mtu_set(); ...; dev_stop(); dev_configure(); dev_start(); > >>>>>> > >>>>>>> > >>>>>>> When 'rte_eth_dev_configure()' is called, MTU is set to '1500' by default by > >>>>>>> ethdev layer, so it is not user configuration, but 'max_rx_pkt_len' is. > >>>>>> > >>>>>> See above. > >>>>>> PMD doesn't know where this MTU value came from (default ethdev value or user specified value) > >>>>>> and probably it shouldn't care. > >>>>>> > >>>>>>> > >>>>>>> And later, when 'rte_eth_dev_set_mtu()' is called, but MTU and 'max_rx_pkt_len' > >>>>>>> are updated (mostly). > >>>>>> > >>>>>> Yes, in mtu_set() we update both. > >>>>>> But we don't update MTU in dev_configure(), only max_rx_pkt_len. > >>>>>> That what this patch tries to fix (as I understand it). > >>>>> > >>>>> To be more precise - it doesn't change MTU value in dev_configure(), > >>>>> but instead doesn't allow max_rx_pkt_len to become smaller > >>>>> then MTU + OVERHEAD. > >>>>> Probably changing MTU value instead is a better choice. > >>>>> > >>>> > >>>> +1 to change mtu for this case. > >>>> And this is what happens in practice when there is no 'rte_eth_dev_set_mtu()' > >>>> call, since PMD is using ('max_rx_pkt_len' - OVERHEAD) to set MTU. > >>> > >>> Hmm, I don't see that happens within Intel PMDs. > >>> As I can read the code: if user never call mtu_set(), then MTU value is left intact. > >>> > >> > >> I was checking ice, > >> in 'ice_dev_start()', 'rxmode.max_rx_pkt_len' is used to configure the device. > > > > Yes, I am not arguing with that. > > What I am saying - dev_config() doesn't update MTU based on max_rx_pkt_len. > > While it probably should. > > > > Yes 'dev_configure()' doesn't update the 'dev->data->mtu' and 'max_rx_pkt_len' & > 'dev->data->mtu' may diverge there. > > I think best place to update 'dev->data->mtu' is where the device is actually > updated, but to prevent the diversion above we can update 'dev->data->mtu' in > ethdev layer, in 'rte_eth_dev_configure()' based on 'max_rx_pkt_len', will it work? I think - yes. At least, I don't foresee any implications with that. > > Only concern I see is if user reads the MTU ('rte_eth_dev_get_mtu()') after > 'rte_eth_dev_configure()' but before device configured, user will get the wrong > value, I guess that problem was already there but changing default value may > make it more visible. > > >> > >>>> But this won't solve the problem Steve is trying to solve. > >>> > >>> You mean we still need to update test-pmd code to calculate max_rx_pkt_len > >>> properly for default mtu value? > >>> > >> > >> Yes. > >> Because target of this set is able to receive packets with payload size > >> 'RTE_ETHER_MTU', if MTU is updated according to the provided 'max_rx_pkt_len', > >> device still won't able to receive those packets. > > > > Agree. > > > >> > >>>>>>> > >>>>>>> > >>>>>>>> Before the patch will result: > >>>>>>>> mtu==1500, max_rx_pkt_len=1000; //out of sync looks wrong to me > >>>>>>>> > >>>>>>>> After the patch: > >>>>>>>> mtu=1500, max_rx_ptk_len=1518; // in sync, change in behaviour. > >>>>>>>> > >>>>>>>> If you think we need to preserve current behaviour, > >>>>>>>> then I suppose the easiest thing would be to change dev_config() code > >>>>>>>> to update mtu value based on max_rx_pkt_len. > >>>>>>>> I.E: dev_configure {...; mtu_set(max_rx_pkt_len - OVERHEAD); ...} > >>>>>>>> So the code snippet above will result: > >>>>>>>> mtu=982,max_rx_pkt_len=1000; > >>>>>>>> > >>>>>>> > >>>>>>> The 'max_rx_ptk_len' is annoyance for a long time, what do you think to just > >>>>>>> drop it? > >>>>>>> > >>>>>>> By default device will be up with default MTU (1500), later > >>>>>>> 'rte_eth_dev_set_mtu' can be used to set the MTU, no frame size setting at all. > >>>>>>> > >>>>>>> Will this work? > >>>>>> > >>>>>> I think it might, but that's a big change, probably too risky at that stage... > >>>>>> > >>>> > >>>> Defintely, I was thinking for 21.11. Let me send a deprecation notice and see > >>>> what happens. > >>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> And for short term, for above Intel PMDs, there must be a place this > >>>>>>> 'max_rx_pkt_len' value taken into account (mostly 'start()' dev_ops), that > >>>>>>> function can be updated to take 'max_rx_pkt_len' only if JUMBO_FRAME set, > >>>>>>> otherwise use the 'MTU' value. > >>>>>> > >>>>>> Even if we'll use max_rx_pkt_len only when if JUMBO_FRAME is set, > >>>>>> I think we still need to keep max_rx_pkt_len and MTU values in sync. > >>>>>> > >>>>>>> > >>>>>>> Without 'start()' updated the current logic won't work after stop & start anyway. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> And why this same thing can't happen to other PMDs? If this is a problem for > >>>>>>>>>> all PMDs, we should solve in other level, not for only some PMDs. > >>>>>>>>>> > >>>>>>>>> No, all PMDs exist the same issue, another proposal: > >>>>>>>>> - rte_ethdev provides the unique resize 'max_rx_pkt_len' in rte_eth_dev_configure(); > >>>>>>>>> - provide the uniform API for fetching the NIC's supported Ether Overhead size; > >>>>>>>>> Is it feasible? > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Generally, the mtu value can be adjustable from user (e.g.: ip link > >>>>>>>>>>>> set ens801f0 mtu 1400), hence, we just adjust the max_rx_pkt_len to > >>>>>>>>>>>> satisfy mtu requirement. > >>>>>>>>>>>> > >>>>>>>>>>>>> Should we just call ice_mtu_set(dev, dev_conf.rxmode.max_rx_pkt_len) > >>>>>>>>>>>>> here? > >>>>>>>>>>>> ice_mtu_set(dev, mtu) will append ether overhead to > >>>>>>>>>>>> frame_size/max_rx_pkt_len, so we need pass the mtu value as the 2nd > >>>>>>>>>>>> parameter, or not the max_rx_pkt_len. > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> And please remove above comment, since ether overhead is already > >>>>>>>>>>>>>> considered in ice_mtu_set. > >>>>>>>>>>>> Ether overhead is already considered in ice_mtu_set, but it also > >>>>>>>>>>>> should be considered as the adjustment condition that if ice_mtu_set > >>>>>>>>>> need be invoked. > >>>>>>>>>>>> So, it perhaps should remain this comment before this if() condition. > >>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> +ret = ice_mtu_set(dev, dev->data->mtu); if (ret != 0) return > >>>>>>>>>>>>>>>> +ret; } > >>>>>>>>>>>>>>>> + > >>>>>>>>>>>>>>>> ret = ice_init_rss(pf); > >>>>>>>>>>>>>>>> if (ret) { > >>>>>>>>>>>>>>>> PMD_DRV_LOG(ERR, "Failed to enable rss for PF"); > >>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>> 2.17.1 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>> > >>> > >
next prev parent reply other threads:[~2020-10-21 10:44 UTC|newest] Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-16 5:52 [dpdk-dev] [PATCH v1 0/5] fix default max mtu size when device configured SteveX Yang 2020-09-16 5:52 ` [dpdk-dev] [PATCH v1 1/5] net/e1000: fix max mtu size packets with vlan tag cannot be received by default SteveX Yang 2020-09-16 5:52 ` [dpdk-dev] [PATCH v1 2/5] net/igc: " SteveX Yang 2020-09-16 5:52 ` [dpdk-dev] [PATCH v1 3/5] net/ice: " SteveX Yang 2020-09-16 5:52 ` [dpdk-dev] [PATCH v1 4/5] net/iavf: " SteveX Yang 2020-09-16 5:52 ` [dpdk-dev] [PATCH v1 5/5] net/i40e: " SteveX Yang 2020-09-16 14:41 ` Ananyev, Konstantin [not found] ` <DM6PR11MB4362E5FF332551D12AA20017F93E0@DM6PR11MB4362.namprd11.prod.outlook.com> 2020-09-17 12:18 ` Ananyev, Konstantin 2020-09-22 1:23 ` [dpdk-dev] [PATCH v2 0/5] fix default max mtu size when device configured SteveX Yang 2020-09-22 1:23 ` [dpdk-dev] [PATCH v2 1/5] net/e1000: fix max mtu size packets with vlan tag cannot be received by default SteveX Yang 2020-09-22 1:23 ` [dpdk-dev] [PATCH v2 2/5] net/igc: " SteveX Yang 2020-09-22 1:23 ` [dpdk-dev] [PATCH v2 3/5] net/ice: " SteveX Yang 2020-09-22 1:23 ` [dpdk-dev] [PATCH v2 4/5] net/i40e: " SteveX Yang 2020-09-22 10:47 ` Ananyev, Konstantin 2020-09-22 1:23 ` [dpdk-dev] [PATCH v2 5/5] net/iavf: " SteveX Yang 2020-09-23 4:09 ` [dpdk-dev] [PATCH v3 0/5] fix default max mtu size when device configured SteveX Yang 2020-09-23 4:09 ` [dpdk-dev] [PATCH v3 1/5] net/e1000: fix max mtu size packets with vlan tag cannot be received by default SteveX Yang 2020-09-23 4:09 ` [dpdk-dev] [PATCH v3 2/5] net/igc: " SteveX Yang 2020-09-23 4:09 ` [dpdk-dev] [PATCH v3 3/5] net/ice: " SteveX Yang 2020-09-23 4:09 ` [dpdk-dev] [PATCH v3 4/5] net/i40e: " SteveX Yang 2020-09-23 4:09 ` [dpdk-dev] [PATCH v3 5/5] net/iavf: " SteveX Yang 2020-09-28 6:55 ` [dpdk-dev] [PATCH v4 0/5] fix default max mtu size when device configured SteveX Yang 2020-09-28 6:55 ` [dpdk-dev] [PATCH v4 1/5] net/e1000: fix max mtu size packets with vlan tag cannot be received by default SteveX Yang 2020-09-28 6:55 ` [dpdk-dev] [PATCH v4 2/5] net/igc: " SteveX Yang 2020-09-28 6:55 ` [dpdk-dev] [PATCH v4 3/5] net/ice: " SteveX Yang 2020-09-29 11:59 ` Zhang, Qi Z 2020-09-29 23:01 ` Ananyev, Konstantin 2020-09-30 0:34 ` Zhang, Qi Z [not found] ` <DM6PR11MB4362515283D00E27A793E6B0F9330@DM6PR11MB4362.namprd11.prod.outlook.com> 2020-09-30 2:32 ` Zhang, Qi Z 2020-10-14 15:38 ` Ferruh Yigit [not found] ` <DM6PR11MB43628BBF9DCE7CC4D7C05AD8F91E0@DM6PR11MB4362.namprd11.prod.outlook.com> 2020-10-19 10:49 ` Ananyev, Konstantin 2020-10-19 13:07 ` Ferruh Yigit 2020-10-19 14:07 ` Ananyev, Konstantin 2020-10-19 14:28 ` Ananyev, Konstantin 2020-10-19 18:01 ` Ferruh Yigit 2020-10-20 9:07 ` Ananyev, Konstantin 2020-10-20 12:29 ` Ferruh Yigit 2020-10-21 9:47 ` Ananyev, Konstantin 2020-10-21 10:36 ` Ferruh Yigit 2020-10-21 10:44 ` Ananyev, Konstantin [this message] 2020-10-21 10:53 ` Ferruh Yigit 2020-10-19 18:05 ` Ferruh Yigit [not found] ` <DM6PR11MB4362F936BFC715BF6BABBAD0F91F0@DM6PR11MB4362.namprd11.prod.outlook.com> 2020-10-20 8:13 ` Ferruh Yigit 2020-09-28 6:55 ` [dpdk-dev] [PATCH v4 4/5] net/i40e: " SteveX Yang 2020-09-28 6:55 ` [dpdk-dev] [PATCH v4 5/5] net/iavf: " SteveX Yang 2020-10-14 9:19 ` [dpdk-dev] [PATCH v5 0/5] fix default max mtu size when device configured SteveX Yang 2020-10-14 9:19 ` [dpdk-dev] [PATCH v5 1/5] net/e1000: fix max mtu size packets with vlan tag cannot be received by default SteveX Yang 2020-10-14 9:19 ` [dpdk-dev] [PATCH v5 2/5] net/igc: " SteveX Yang 2020-10-14 9:19 ` [dpdk-dev] [PATCH v5 3/5] net/ice: " SteveX Yang 2020-10-14 11:35 ` Zhang, Qi Z 2020-10-14 9:19 ` [dpdk-dev] [PATCH v5 4/5] net/i40e: " SteveX Yang 2020-10-14 10:30 ` Ananyev, Konstantin 2020-10-14 9:19 ` [dpdk-dev] [PATCH v5 5/5] net/iavf: " SteveX Yang 2020-10-14 11:43 ` [dpdk-dev] [PATCH v5 0/5] fix default max mtu size when device configured Zhang, Qi Z 2020-10-22 8:48 ` [dpdk-dev] [PATCH v6 0/2] " SteveX Yang 2020-10-22 8:48 ` [dpdk-dev] [PATCH v6 1/2] app/testpmd: fix max rx packet length for VLAN packets SteveX Yang 2020-10-22 16:22 ` Ferruh Yigit 2020-10-22 8:48 ` [dpdk-dev] [PATCH v6 2/2] librte_ethdev: fix MTU size exceeds max rx packet length SteveX Yang 2020-10-22 16:31 ` Ferruh Yigit 2020-10-22 16:52 ` Ananyev, Konstantin 2020-10-28 3:03 ` [dpdk-dev] [PATCH v7 0/1] fix default max mtu size when device configured SteveX Yang 2020-10-28 3:03 ` [dpdk-dev] [PATCH v7 1/1] app/testpmd: fix max rx packet length for VLAN packets SteveX Yang 2020-10-29 8:41 ` Ferruh Yigit 2020-11-02 8:52 ` [dpdk-dev] [PATCH v8 0/2] fix default max mtu size when device configured SteveX Yang 2020-11-02 8:52 ` [dpdk-dev] [PATCH v8 1/2] app/testpmd: fix max rx packet length for VLAN packets SteveX Yang 2020-11-02 11:48 ` Ferruh Yigit 2020-11-03 13:29 ` Ferruh Yigit 2020-11-04 16:51 ` Thomas Monjalon 2020-11-04 17:07 ` Ferruh Yigit 2020-11-04 17:55 ` Thomas Monjalon 2020-11-04 20:19 ` Ferruh Yigit 2020-11-04 20:39 ` Thomas Monjalon 2020-11-05 8:54 ` Andrew Rybchenko [not found] ` <DM6PR11MB43622CC5DF485DD034037CD3F9EE0@DM6PR11MB4362.namprd11.prod.outlook.com> 2020-11-05 10:37 ` Ferruh Yigit 2020-11-05 10:44 ` Thomas Monjalon 2020-11-05 10:48 ` Thomas Monjalon 2020-11-05 10:50 ` Ferruh Yigit 2020-11-05 13:52 ` Olivier Matz 2020-11-05 15:11 ` Lance Richardson 2020-11-05 15:56 ` Ferruh Yigit 2020-11-05 16:23 ` Lance Richardson 2020-11-05 17:44 ` [dpdk-dev] [PATCH 1/1] app/testpmd: revert max Rx packet length adjustment Thomas Monjalon 2020-11-05 18:02 ` Lance Richardson 2020-11-05 18:11 ` Ferruh Yigit 2020-11-05 18:18 ` Thomas Monjalon 2020-11-05 10:49 ` [dpdk-dev] [PATCH v8 1/2] app/testpmd: fix max rx packet length for VLAN packets Ferruh Yigit 2020-11-02 8:52 ` [dpdk-dev] [PATCH v8 2/2] doc: annouce deprecation of jumbo frame flag condition SteveX Yang 2020-11-02 11:50 ` Ferruh Yigit 2020-11-02 13:18 ` Andrew Rybchenko 2020-11-02 13:58 ` Ferruh Yigit 2020-11-02 16:05 ` Ananyev, Konstantin [not found] ` <DM6PR11MB43625C5CF594BEDC9CE479F7F9110@DM6PR11MB4362.namprd11.prod.outlook.com> 2020-11-24 17:46 ` Ferruh Yigit 2020-11-27 12:19 ` Andrew Rybchenko 2020-11-27 17:08 ` Bruce Richardson
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=BYAPR11MB330134118F72347D1EB0D10A9A1C0@BYAPR11MB3301.namprd11.prod.outlook.com \ --to=konstantin.ananyev@intel.com \ --cc=beilei.xing@intel.com \ --cc=dev@dpdk.org \ --cc=ferruh.yigit@intel.com \ --cc=ian.stokes@intel.com \ --cc=jia.guo@intel.com \ --cc=jingjing.wu@intel.com \ --cc=qi.z.zhang@intel.com \ --cc=qiming.yang@intel.com \ --cc=stevex.yang@intel.com \ --cc=wei.zhao1@intel.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
DPDK patches and discussions This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \ dev@dpdk.org public-inbox-index dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git