DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: oulijun <oulijun@huawei.com>, Steve Yang <stevex.yang@intel.com>,
	dev@dpdk.org
Cc: thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru
Subject: Re: [dpdk-dev] [PATCH v3 01/22] ethdev: fix MTU size exceeds max rx packet length
Date: Mon, 25 Jan 2021 12:22:03 +0000
Message-ID: <88bcfc14-acdb-19c5-857b-157af922901e@intel.com> (raw)
In-Reply-To: <c2f61061-14b2-c621-af83-31f956a654ca@huawei.com>

On 1/19/2021 8:46 AM, oulijun wrote:
> 
> 
> 在 2021/1/18 18:42, Ferruh Yigit 写道:
>> On 1/15/2021 10:44 AM, oulijun wrote:
>>> Hi Steve
>>> This is a very good job! But I have some question and suggestions.
>>> Please check it.
>>>
>>> 在 2021/1/14 17:45, Steve Yang 写道:
>>>> Ethdev is using default Ethernet overhead to decide if provided
>>>> 'max_rx_pkt_len' value is bigger than max (non jumbo) MTU value,
>>>> and limits it to MAX if it is.
>>>>
>>>> Since the application/driver used Ethernet overhead is different than
>>>> the ethdev one, check result is wrong.
>>>>
>>>> If the driver is using Ethernet overhead bigger than the default one,
>>>> the provided 'max_rx_pkt_len' is trimmed down, and in the driver when
>>>> correct Ethernet overhead is used to convert back, the resulting MTU is
>>>> less than the intended one, causing some packets to be dropped.
>>>>
>>>> Like,
>>>> app     -> max_rx_pkt_len = 1500/*mtu*/ + 22/*overhead*/ = 1522
>>>> ethdev  -> 1522 > 1518/*MAX*/; max_rx_pkt_len = 1518
>>>> driver  -> MTU = 1518 - 22 = 1496
>>>> Packets with size 1497-1500 are dropped although intention is to be able
>>>> to send/receive them.
>>>>
>>>> The fix is to make ethdev use the correct Ethernet overhead for port,
>>>> instead of default one.
>>>>
>>>> Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors")
>>>>
>>>> Signed-off-by: Steve Yang <stevex.yang@intel.com>
>>>> ---
>>>>   lib/librte_ethdev/rte_ethdev.c | 27 ++++++++++++++++++++++++---
>>>>   1 file changed, 24 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
>>>> index 17ddacc78d..19ca4c4512 100644
>>>> --- a/lib/librte_ethdev/rte_ethdev.c
>>>> +++ b/lib/librte_ethdev/rte_ethdev.c
>>>> @@ -1292,8 +1292,10 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t 
>>>> nb_rx_q, uint16_t nb_tx_q,
>>>>       struct rte_eth_dev *dev;
>>>>       struct rte_eth_dev_info dev_info;
>>>>       struct rte_eth_conf orig_conf;
>>>> +    uint16_t overhead_len;
>>>>       int diag;
>>>>       int ret;
>>>> +    uint16_t old_mtu;
>>>>       RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>>> @@ -1319,10 +1321,20 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t 
>>>> nb_rx_q, uint16_t nb_tx_q,
>>>>           memcpy(&dev->data->dev_conf, dev_conf,
>>>>                  sizeof(dev->data->dev_conf));
>>>> +    /* Backup mtu for rollback */
>>>> +    old_mtu = dev->data->mtu;
>>>> +
>>>>       ret = rte_eth_dev_info_get(port_id, &dev_info);
>>>>       if (ret != 0)
>>>>           goto rollback;
>>>> +    /* Get the real Ethernet overhead length */
>>>> +    if (dev_info.max_mtu != UINT16_MAX &&
>>>> +        dev_info.max_rx_pktlen > dev_info.max_mtu)
>>>> +        overhead_len = dev_info.max_rx_pktlen - dev_info.max_mtu;
>>>> +    else
>>>> +        overhead_len = RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN;
>>>> +
>>> The Ethernet frame header length supported by each NIC may be different, 
>>> which cause the difference of allowed packets size and drop you say.
>>> The diference of Ethernet frame header length have an impact for the maximum 
>>> Ethernet frame length, which is a boundary value
>>> of enabling jumbo frame through the ' max_rx_pkt_len '.
>>> However, we need to do the same thing you do above to get the overhead_len 
>>> every time, which will
>>> cause a lot of duplicate code in the framework and app. For examples, parsing 
>>> and processing for '--max-pkt-len=xxx' parameter,
>>>   and " cmd_config_max_pkt_len_parsed " in testpmd, and here modifying here 
>>> dev_configure API.
>>> It's a little redundant and troublesome.
>>>
>>> Maybe, it is necessary for driver to directly report the supported maximum 
>>> Ethernet frame length by rte_dev_info_get API.
>>> As following:
>>> struct rte_eth_dev_info {
>>>      xxxx
>>>      /**
>>>       * The maximum Ethernet frame length supported by each
>>>       * driver varies with the Ethernet header length.
>>>       */
>>>      uint16_t eth_max_len;
>>>      xxxx
>>> }
>>>
>>> int
>>> rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>>> {
>>>      xxx
>>>      dev_info->min_mtu = RTE_ETHER_MIN_MTU;
>>>      dev_info->max_mtu = UINT16_MAX;
>>>      dev_info->eth_max_len = RTE_ETHER_MAX_LEN;
>>>      xxx
>>> }
>>>
>>> And then:
>>> xxx_devv_infos_get(struct rte_eth_dev *eth_dev, struct rte_eth_dev_info *info)
>>> {
>>>      xxx
>>>      info->eth_max_len = xxx_ETHER_MAX _LEN;
>>>      xxx
>>> }
>>> What do you think?
>>
>> Hi Lijun,
>>
>> The 'max_mtu' has been added in the past to solve exact same problem, perhaps 
>> it would be better to add something like 'eth_max_len' at that time.
>>
>> But as Steve mentioned we are planning to switch to more MTU based 
>> configuration, which should remove the need of the field you mentioned.
>>
>>>>       /* If number of queues specified by application for both Rx and Tx is
>>>>        * zero, use driver preferred values. This cannot be done individually
>>>>        * as it is valid for either Tx or Rx (but not both) to be zero.
>>>> @@ -1410,11 +1422,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t 
>>>> nb_rx_q, uint16_t nb_tx_q,
>>>>               goto rollback;
>>>>           }
>>>>       } else {
>>>> -        if (dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN ||
>>>> -            dev_conf->rxmode.max_rx_pkt_len > RTE_ETHER_MAX_LEN)
>>>> +        uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len;
>>>> +        if (pktlen < RTE_ETHER_MIN_MTU + overhead_len ||
>>>> +            pktlen > RTE_ETHER_MTU + overhead_len)
>>>>               /* Use default value */
>>>>               dev->data->dev_conf.rxmode.max_rx_pkt_len =
>>>> -                            RTE_ETHER_MAX_LEN;
>>>> +                        RTE_ETHER_MTU + overhead_len;
>>>> +    }
>>>> +
>>>> +    /* Scale the MTU size to adapt max_rx_pkt_len */
>>>> +    if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) {
>>>> +        dev->data->mtu = dev->data->dev_conf.rxmode.max_rx_pkt_len -
>>>> +                overhead_len;
>>>>       }
>>> Now that we update mtu here when jumbo frame enabled. It is necessary to 
>>> check validity of max_rx_pkt_len.
>>> As following:
>>> if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) {
>>>      if (dev_conf->rxmode.max_rx_pkt_len > dev_info.max_rx_pktlen ||
>>>          dev_conf->rxmode.max_rx_pkt_len <=  RTE_ETHER_MTU + overhead_len) {
>>
>> It is not clear from API that if "max_rx_pkt_len <=  RTE_ETHER_MTU + 
>> overhead_len" is a valid value or not, the API says:
>> "max_rx_pkt_len;  /**< Only used if JUMBO_FRAME enabled. */"
>>
>> But it doesn't say that when 'DEV_RX_OFFLOAD_JUMBO_FRAME' is set, 
>> 'max_rx_pkt_len' should be less then 'RTE_ETHER_MTU'
>>
> The MTU setting entry does need to be adjusted. I agree! But I think this place 
> should be modified, and it's probably more reasonable.
> 
> Generally speaking, max_rx_pkt_len will be also updated with 'mtu + 
> overhead_len' also when application sets mtu > 1500, which means JUMBO_FRAME is 
> enabled.
> Namely, JUMBO_FRAME is enabled based on mtu > 1500 or max_rx_pkt_len > 1500 + 
> overhead_len.
> Besides, having following check for "rxmode.offloads & 
> DEV_RX_OFFLOAD_JUMBO_FRAME == 0":
> @@ -1410,11 +1422,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t 
> nb_rx_q, uint16_t nb_tx_q,
>                goto rollback;
>            }
>        } else {
>          uint16_t pktlen = dev_conf->rxmode.max_rx_pkt_len;
>          if (pktlen < RTE_ETHER_MIN_MTU + overhead_len ||
>              pktlen > RTE_ETHER_MTU + overhead_len)
>                /* Use default value */
>                dev->data->dev_conf.rxmode.max_rx_pkt_len =
>                          RTE_ETHER_MTU + overhead_len;
> }
> One of check condition for the branch is "pktlen > RTE_ETHER_MTU + overhead_len ".
> 
> In view of the above two aspects, when application set 
> DEV_RX_OFFLOAD_JUMBO_FRAME in offload, the max_rx_pkt_len must be greater than " 
> RTE_ETHER_MTU + overhead_len "
> 

Hi Lijun,

Most probably intention was like you said, but that is not implemented or 
documented that way.

The API doc only says 'max_rx_pkt_len' is valid only when 'JUMBO_FRAME' is set, 
but it doesn't say what is the valid range.

And when 'JUMBO_FRAME' is set, the check in the 'rte_eth_dev_configure()' is 
same from the beggining of the project, and it is between 'RTE_ETHER_MIN_LEN' to 
'dev_info.max_rx_pktlen', and changing it will be the behaviour change.

So I suggest lets not add this new config restriction, but it is application's 
responsiblity to set/unset the 'JUMBO_FRAME' flag based on the packet size, and 
we can implemet this in the testpmd.

> Since DEV_RX_OFFLOAD_JUMBO_FRAME is not removed, so the check is necessary.
> 
>>>              xxxx
>>>          }
>>> } else {
>>>          xxx
>>> }
>>>
>>> If it does not thing above, which will cause an unreasonable case.
>>> Like,
>>> dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME == 1
>>> dev_conf->rxmode.max_rx_pkt_len = 1500
>>> overhead_len = 26
>>> dev->data->mtu = dev_conf->rxmode.max_rx_pkt_len - overhead_len = 1500 - 26 = 
>>> 1474
>>>
>>
>> This looks correct, if the applicatin is requesting 'max_rx_pkt_len = 1500', 
>> the requeted MTU is 1474,
>> if application wants an MTU as 1500, it should set the 'max_rx_pkt_len' as 
>> "1500 + overhead".
>>
>>> In fact, DEV_RX_OFFLOAD_JUMBO_FRAME is set to rxmode.offloads when mtu > 1500.
>>
>> Overall the 'max_rx_pkt_len' setting is a little messy, it has been tried to 
>> fix in last release but we reverted them because of unexpected side affects.
>>
>> Current long term plan is,
>> - Switch both 'rte_eth_dev_configure()' & 'rte_eth_dev_set_mtu()' to work on 
>> MTU values. (instead one working on frame lenght and other on MTU)
>> - Remove the 'DEV_RX_OFFLOAD_JUMBO_FRAME' and decide jumbo frame request by 
>> requested MTU value check
>> - App decide the jumbo frame capability from the 'max_mtu' check
>> - App calculate Ethernet overhead using 'max_mtu' and 'max_rx_pktlen'
>>
>>>>       /*
>>>> @@ -1549,6 +1568,8 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t 
>>>> nb_rx_q, uint16_t nb_tx_q,
>>>>       eth_dev_tx_queue_config(dev, 0);
>>>>   rollback:
>>>>       memcpy(&dev->data->dev_conf, &orig_conf, sizeof(dev->data->dev_conf));
>>>> +    if (old_mtu != dev->data->mtu)
>>>> +        dev->data->mtu = old_mtu;
>>>>       rte_ethdev_trace_configure(port_id, nb_rx_q, nb_tx_q, dev_conf, ret);
>>>>       return ret;
>>>>
>>
>> .
>>


  parent reply	other threads:[~2021-01-25 12:22 UTC|newest]

Thread overview: 115+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  3:16 [dpdk-dev] [PATCH v1 00/12] fix rx packets dropped issue Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 01/12] net/dpaa2: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 02/12] net/e1000: " Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 03/12] net/hns3: " Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 04/12] net/i40e: fix the jumbo frame flag condition Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 05/12] net/iavf: " Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 06/12] net/ice: " Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 07/12] net/ipn3ke: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 08/12] net/octeontx: " Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 09/12] net/octeontx2: fix the jumbo frame flag condition for mtu Steve Yang
2020-12-21  7:16   ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 10/12] net/qede: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 11/12] net/sfc: " Steve Yang
2020-12-09  3:16 ` [dpdk-dev] [PATCH v1 12/12] net/thunderx: " Steve Yang
2020-12-11  4:31 ` [dpdk-dev] [PATCH v1 00/12] fix rx packets dropped issue Guo, Jia
2020-12-14 17:44 ` Ferruh Yigit
2020-12-17  9:22 ` [dpdk-dev] [PATCH v2 00/22] " Steve Yang
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 01/22] ethdev: fix MTU size exceeds max rx packet length Steve Yang
2020-12-28 14:51     ` Andrew Rybchenko
2021-01-13 10:32       ` Ferruh Yigit
2020-12-30 10:19     ` oulijun
     [not found]       ` <DM6PR11MB43627F10DDAFC9801816FF5BF9D00@DM6PR11MB4362.namprd11.prod.outlook.com>
2021-01-13 10:25         ` Ferruh Yigit
2021-01-13 11:04         ` Ferruh Yigit
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 02/22] app/testpmd: fix max rx packet length for VLAN packets Steve Yang
2021-01-13 11:26     ` Ferruh Yigit
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 03/22] net/dpaa: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 04/22] net/dpaa2: " Steve Yang
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 05/22] net/e1000: " Steve Yang
2020-12-18  2:42     ` Guo, Jia
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 06/22] net/hns3: " Steve Yang
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 07/22] net/i40e: fix the jumbo frame flag condition Steve Yang
2020-12-18  2:44     ` Guo, Jia
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 08/22] net/iavf: " Steve Yang
2020-12-17  9:22   ` [dpdk-dev] [PATCH v2 09/22] net/ice: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 10/22] net/ipn3ke: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-19  0:54     ` Xu, Rosen
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 11/22] net/octeontx: " Steve Yang
2020-12-21 15:04     ` [dpdk-dev] [EXT] " Harman Kalra
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 12/22] net/octeontx2: fix the jumbo frame flag condition for mtu Steve Yang
2020-12-18 10:15     ` Nithin Dabilpuram
2020-12-21  7:19     ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 13/22] net/qede: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 14/22] net/sfc: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 15/22] net/thunderx: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 16/22] net/ixgbe: fix the jumbo frame flag condition Steve Yang
2020-12-18  2:43     ` Guo, Jia
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 17/22] net/cxgbe: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 18/22] net/axgbe: fix the jumbo frame flag condition for mtu set Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 19/22] net/enetc: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 20/22] net/hinic: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 21/22] net/nfp: " Steve Yang
2020-12-17  9:23   ` [dpdk-dev] [PATCH v2 22/22] net/liquidio: " Steve Yang
2021-01-13 11:32   ` [dpdk-dev] [PATCH v2 00/22] fix rx packets dropped issue Ferruh Yigit
2021-01-14  9:45   ` [dpdk-dev] [PATCH v3 " Steve Yang
2021-01-14  9:45   ` [dpdk-dev] [PATCH v3 01/22] ethdev: fix MTU size exceeds max rx packet length Steve Yang
2021-01-14 16:36     ` Ferruh Yigit
2021-01-14 17:13       ` Ferruh Yigit
2021-01-14 17:29         ` Andrew Boyer
2021-01-14 20:44           ` Ferruh Yigit
2021-01-15 10:44     ` oulijun
2021-01-18 10:42       ` Ferruh Yigit
2021-01-19  8:46         ` oulijun
2021-01-23  9:05           ` oulijun
2021-01-25 12:22           ` Ferruh Yigit [this message]
2021-01-18  7:04     ` [dpdk-dev] [PATCH v4 00/22] fix rx packets dropped issue Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 01/22] ethdev: fix MTU size exceeds max rx packet length Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 02/22] app/testpmd: fix max rx packet length for VLAN packets Steve Yang
2021-01-21 15:27         ` Lance Richardson
2021-01-22 14:26           ` Lance Richardson
2021-01-25 12:14           ` Ferruh Yigit
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 03/22] net/dpaa: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 04/22] net/dpaa2: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 05/22] net/e1000: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 06/22] net/hns3: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 07/22] net/i40e: fix the jumbo frame flag condition Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 08/22] net/iavf: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 09/22] net/ice: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 10/22] net/ipn3ke: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 11/22] net/octeontx: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 12/22] net/octeontx2: fix the jumbo frame flag condition for mtu Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 13/22] net/qede: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 14/22] net/sfc: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 15/22] net/thunderx: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 16/22] net/ixgbe: fix the jumbo frame flag condition Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 17/22] net/cxgbe: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 18/22] net/axgbe: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 19/22] net/enetc: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 20/22] net/hinic: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 21/22] net/nfp: " Steve Yang
2021-01-18  7:04       ` [dpdk-dev] [PATCH v4 22/22] net/liquidio: " Steve Yang
2021-01-18 11:54       ` [dpdk-dev] [PATCH v4 00/22] fix rx packets dropped issue Ferruh Yigit
2021-01-14  9:45   ` [dpdk-dev] [PATCH v3 02/22] app/testpmd: fix max rx packet length for VLAN packets Steve Yang
2021-01-14  9:45   ` [dpdk-dev] [PATCH v3 03/22] net/dpaa: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-14 10:26     ` Hemant Agrawal
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 04/22] net/dpaa2: " Steve Yang
2021-01-14 10:27     ` Hemant Agrawal
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 05/22] net/e1000: " Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 06/22] net/hns3: " Steve Yang
2021-01-18  1:30     ` oulijun
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 07/22] net/i40e: fix the jumbo frame flag condition Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 08/22] net/iavf: " Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 09/22] net/ice: " Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 10/22] net/ipn3ke: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 11/22] net/octeontx: " Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 12/22] net/octeontx2: fix the jumbo frame flag condition for mtu Steve Yang
2021-01-14  9:46   ` [dpdk-dev] [PATCH v3 13/22] net/qede: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 14/22] net/sfc: " Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 15/22] net/thunderx: " Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 16/22] net/ixgbe: fix the jumbo frame flag condition Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 17/22] net/cxgbe: " Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 18/22] net/axgbe: fix the jumbo frame flag condition for mtu set Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 19/22] net/enetc: " Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 20/22] net/hinic: " Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 21/22] net/nfp: " Steve Yang
2021-01-14  9:47   ` [dpdk-dev] [PATCH v3 22/22] net/liquidio: " Steve Yang

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=88bcfc14-acdb-19c5-857b-157af922901e@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=oulijun@huawei.com \
    --cc=stevex.yang@intel.com \
    --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

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