| Message ID | 1491562925-27247-1-git-send-email-Andriy.Berestovskyy@caviumnetworks.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Thomas Monjalon |
| Headers | show |
| Context | Check | Description |
|---|---|---|
| ci/checkpatch | success | coding style OK |
| ci/Intel-compilation | fail | apply issues |
2017-04-07 13:02, Andriy Berestovskyy: > At the moment rte_eth_dev_configure() behaves inconsistent: > - for normal frames: zero max_rx_pkt_len uses a default > - for jumbo frames: zero max_rx_pkt_len gives an error > > This patch fixes this inconsistency by using a default value > if max_rx_pkt_len is zero both for normal and jumbo frames. > > Signed-off-by: Andriy Berestovskyy <Andriy.Berestovskyy@caviumnetworks.com> > --- > > Notes: > v3 changes: > - use a default only if max_rx_pkt_len is zero Looks good. Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com> It is a small API change but it is fixing an inconsistency, so I think it can be integrated in 17.05-rc2 as is. Any different opinion?
On Fri, Apr 07, 2017 at 02:15:47PM +0200, Thomas Monjalon wrote: > 2017-04-07 13:02, Andriy Berestovskyy: > > At the moment rte_eth_dev_configure() behaves inconsistent: > > - for normal frames: zero max_rx_pkt_len uses a default > > - for jumbo frames: zero max_rx_pkt_len gives an error > > > > This patch fixes this inconsistency by using a default value > > if max_rx_pkt_len is zero both for normal and jumbo frames. > > > > Signed-off-by: Andriy Berestovskyy <Andriy.Berestovskyy@caviumnetworks.com> > > --- > > > > Notes: > > v3 changes: > > - use a default only if max_rx_pkt_len is zero > > Looks good. > > Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com> > > It is a small API change but it is fixing an inconsistency, > so I think it can be integrated in 17.05-rc2 as is. > Any different opinion? Is this entirely hidden from drivers? As I said previously, I believe NICs using ixgbe/i40e etc. only use the frame size value when the jumbo frame flag is set. That may lead to further inconsistent behaviour unless all NICs are set up to behave as expected too. /Bruce
Hey Bruce, On 07.04.2017 14:29, Bruce Richardson wrote: > Is this entirely hidden from drivers? As I said previously, I believe > NICs using ixgbe/i40e etc. only use the frame size value when the jumbo > frame flag is set. That may lead to further inconsistent behaviour unless > all NICs are set up to behave as expected too. You are right. If we take just Intel PMDs: some use the max_rx_pkt_len only for jumbo frames (ixgbe), some always (i40) and some never (fm10k). What if we add to the max_rx_pkt_len description: "the effective maximum RX frame size depends on PMD, please refer the PMD guide for the details"? So with this patch we make rte_eth_dev_configure() clear and later PMDs might change or clarify their limitations in the NIC guides. Andriy
2017-04-07 16:18, Andriy Berestovskyy: > Hey Bruce, > > On 07.04.2017 14:29, Bruce Richardson wrote: > > Is this entirely hidden from drivers? As I said previously, I believe > > NICs using ixgbe/i40e etc. only use the frame size value when the jumbo > > frame flag is set. That may lead to further inconsistent behaviour unless > > all NICs are set up to behave as expected too. > > You are right. If we take just Intel PMDs: some use the max_rx_pkt_len > only for jumbo frames (ixgbe), some always (i40) and some never (fm10k). > > What if we add to the max_rx_pkt_len description: "the effective maximum > RX frame size depends on PMD, please refer the PMD guide for the details"? I think the problem is not in the documentation but in the implementations which should be more consistent. > So with this patch we make rte_eth_dev_configure() clear and later PMDs > might change or clarify their limitations in the NIC guides. If I understand well, the inconsistency between drivers was already an issue before your patch. Your patch fixes an inconsistency in ethdev without fixing the drivers. We need to know if it is a good first step and if the drivers can be fixed later.
Hey Thomas, On 07.04.2017 16:47, Thomas Monjalon wrote: >> What if we add to the max_rx_pkt_len description: "the effective maximum >> RX frame size depends on PMD, please refer the PMD guide for the details"? > > I think the problem is not in the documentation but in the implementations > which should be more consistent. The hardware is different, there is not much we can do about it. Nevertheless, we can fix the false comment and have a default for the jumbos, which is beneficial for the apps/examples. > If I understand well, the inconsistency between drivers was already an > issue before your patch. > Your patch fixes an inconsistency in ethdev without fixing the drivers. > We need to know if it is a good first step and if the drivers can be > fixed later. Thomas, some of the examples use a hard-coded jumbo frame size, which is too big for the underlaying PMDs, so those examples fail. The plan was to fix them all with this commit in ethdev but I am not sure now you are to accept the change. It is important for us to have those examples working in the upcoming release, do you think it is better to send fixes for those examples instead of this commit then? Andriy
07/04/2017 17:27, Andriy Berestovskyy: > Hey Thomas, > > On 07.04.2017 16:47, Thomas Monjalon wrote: > >> What if we add to the max_rx_pkt_len description: "the effective maximum > >> RX frame size depends on PMD, please refer the PMD guide for the > >> details"? > > > > I think the problem is not in the documentation but in the implementations > > which should be more consistent. > > The hardware is different, there is not much we can do about it. We can return an error if the max_rx_pkt_len cannot be set in the NIC. > Nevertheless, we can fix the false comment and have a default for the > jumbos, which is beneficial for the apps/examples. The examples are using a hardcoded value, so they need to be fixed anyway. > > If I understand well, the inconsistency between drivers was already an > > issue before your patch. > > Your patch fixes an inconsistency in ethdev without fixing the drivers. > > We need to know if it is a good first step and if the drivers can be > > fixed later. > > Thomas, some of the examples use a hard-coded jumbo frame size, which is > too big for the underlaying PMDs, so those examples fail. The plan was > to fix them all with this commit in ethdev but I am not sure now you are > to accept the change. This ethdev patch is about a behaviour change of the API. It is about considering 0 as a request for default value and return an error if a value cannot be set. It will require more agreements and changes in the drivers for returning an error where appropriate. > It is important for us to have those examples working in the upcoming > release, do you think it is better to send fixes for those examples > instead of this commit then? The examples can be improved independently of this patch.
Hey Thomas, On 21.04.2017 00:25, Thomas Monjalon wrote: >> The hardware is different, there is not much we can do about it. > > We can return an error if the max_rx_pkt_len cannot be set in the NIC. Yes, we pass the value to the PMD, which might check the value and return an error. >> Nevertheless, we can fix the false comment and have a default for the >> jumbos, which is beneficial for the apps/examples. > > The examples are using a hardcoded value, so they need to be fixed > anyway. We might change the hardcoded values to zeros once the patch is in. This will make the examples a bit more clear. > This ethdev patch is about a behaviour change of the API. The behaviour was not documented, so IMO it is not an issue. > It is about considering 0 as a request for default value > and return an error if a value cannot be set. Right. > It will require more agreements and changes in the drivers > for returning an error where appropriate. IMO the changes are transparent for the PMDs (please see below), but it might affect some applications. Here is the change in API behaviour: Before the patch: jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 10, RESULT: max_rx_pkt_len = ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 0, max_rx_pkt_len == 9K, RESULT: max_rx_pkt_len = ETHER_MAX_LEN jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR After the patch: jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR (changed) jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed) jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info() jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR Only the apps which requested too small or too big normal frames will be affected. In most cases it will be rather an error in the app... Also I have looked through all the PMDs to confirm they are not affected. Here is the summary: af_packet configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = ETH_FRAME_LEN (1514) ark configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128) avp configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = avp->max_rx_pkt_len rx_queue_setup() uses max_rx_pkt_len for scattering bnx2x configure() uses max_rx_pkt_len to set internal mtu info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872) bnxt configure() uses max_rx_pkt_len to set internal mtu info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4) bonding configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or ETHER_MAX_JUMBO_FRAME_LEN (0x3F00) cxgbe configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4) rx_queue_setup() checks max_rx_pkt_len boundaries dpaa2 configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240) e1000 (em) configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, 1518, 0x3f00, depends on model) e1000 (igb) configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = 0x3fff start() writes max_rx_pkt_len to HW for jumbo frames only start() uses max_rx_pkt_len for scattering ena configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = adapter->max_mtu start() checks max_rx_pkt_len boundaries enic configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = enic->max_mtu + 14 + 4 fm10k configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024) start() uses max_rx_pkt_len for scattering i40e configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728) rx_queue_config() checks max_rx_pkt_len boundaries ixgbe configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = 15872 (9728 for vf) start() writes max_rx_pkt_len to HW for jumbo frames only start() uses max_rx_pkt_len for scattering kni configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = UINT32_MAX liquidio configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K) start() checks max_rx_pkt_len boundaries mlx4 configure() uses max_rx_pkt_len for scattering info() returns max_rx_pktlen = 65536 mlx5 configure() uses max_rx_pkt_len for scattering info() returns max_rx_pktlen = 65536 nfp configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = hw->mtu null configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = (uint32_t)-1 pcap configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = (uint32_t)-1 qede configure() uses max_rx_pkt_len for scattering + internal data info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 - 4 - 4 - 12 - 8) ring configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = (uint32_t)-1 sfc configure() uses max_rx_pkt_len to set internal data info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + 16) szedata2 configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = (uint32_t)-1 tap configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + 4) thunderx configure() uses max_rx_pkt_len for scattering + sets internal mtu info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200) vhost configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = (uint32_t)-1 virtio configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U) vmxnet3 configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = 16384; xenvirt configure() does not use max_rx_pkt_len info() returns max_rx_pktlen = 2048 Regards, Andriy
We are missing some comments about this proposal. 24/04/2017 16:50, Andriy Berestovskyy: > Hey Thomas, > > On 21.04.2017 00:25, Thomas Monjalon wrote: > >> The hardware is different, there is not much we can do about it. > > > > We can return an error if the max_rx_pkt_len cannot be set in the NIC. > > Yes, we pass the value to the PMD, which might check the value and > return an error. > > >> Nevertheless, we can fix the false comment and have a default for the > >> jumbos, which is beneficial for the apps/examples. > > > > The examples are using a hardcoded value, so they need to be fixed > > anyway. > > We might change the hardcoded values to zeros once the patch is in. This > will make the examples a bit more clear. > > > > This ethdev patch is about a behaviour change of the API. > > The behaviour was not documented, so IMO it is not an issue. > > > > It is about considering 0 as a request for default value > > and return an error if a value cannot be set. > > Right. > > > > It will require more agreements and changes in the drivers > > for returning an error where appropriate. > > IMO the changes are transparent for the PMDs (please see below), but it > might affect some applications. Here is the change in API behaviour: > > Before the patch: > jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > jumbo == 0, max_rx_pkt_len == 10, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > jumbo == 0, max_rx_pkt_len == 9K, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > > jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR > jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR > jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K > jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR > > > After the patch: > jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR (changed) > jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed) > > jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info() > jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR > jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K > jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR > > Only the apps which requested too small or too big normal frames will be > affected. In most cases it will be rather an error in the app... > > > Also I have looked through all the PMDs to confirm they are not > affected. Here is the summary: > > af_packet > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = ETH_FRAME_LEN (1514) > > ark > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128) > > avp > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = avp->max_rx_pkt_len > rx_queue_setup() uses max_rx_pkt_len for scattering > > bnx2x > configure() uses max_rx_pkt_len to set internal mtu > info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872) > > bnxt > configure() uses max_rx_pkt_len to set internal mtu > info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + > ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4) > > bonding > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or > ETHER_MAX_JUMBO_FRAME_LEN (0x3F00) > > cxgbe > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4) > rx_queue_setup() checks max_rx_pkt_len boundaries > > dpaa2 > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240) > > e1000 (em) > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, > 1518, 0x3f00, depends on model) > > e1000 (igb) > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = 0x3fff > start() writes max_rx_pkt_len to HW for jumbo frames only > start() uses max_rx_pkt_len for scattering > > ena > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = adapter->max_mtu > start() checks max_rx_pkt_len boundaries > > enic > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = enic->max_mtu + 14 + 4 > > fm10k > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024) > start() uses max_rx_pkt_len for scattering > > i40e > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728) > rx_queue_config() checks max_rx_pkt_len boundaries > > ixgbe > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = 15872 (9728 for vf) > start() writes max_rx_pkt_len to HW for jumbo frames only > start() uses max_rx_pkt_len for scattering > > kni > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = UINT32_MAX > > liquidio > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K) > start() checks max_rx_pkt_len boundaries > > mlx4 > configure() uses max_rx_pkt_len for scattering > info() returns max_rx_pktlen = 65536 > > mlx5 > configure() uses max_rx_pkt_len for scattering > info() returns max_rx_pktlen = 65536 > > nfp > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = hw->mtu > > null > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = (uint32_t)-1 > > pcap > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = (uint32_t)-1 > > qede > configure() uses max_rx_pkt_len for scattering + internal data > info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 - 4 - 4 > - 12 - 8) > > ring > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = (uint32_t)-1 > > sfc > configure() uses max_rx_pkt_len to set internal data > info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + 16) > > szedata2 > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = (uint32_t)-1 > > tap > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + 4) > > thunderx > configure() uses max_rx_pkt_len for scattering + sets internal mtu > info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200) > > vhost > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = (uint32_t)-1 > > virtio > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U) > > vmxnet3 > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = 16384; > > xenvirt > configure() does not use max_rx_pkt_len > info() returns max_rx_pktlen = 2048 > > > Regards, > Andriy >
This proposal had no conclusion. The examples have been fixed: http://dpdk.org/commit/5e470a6654 But there is still an inconsistency in the API: " - for normal frames: zero max_rx_pkt_len uses a default - for jumbo frames: zero max_rx_pkt_len gives an error " 01/08/2017 00:33, Thomas Monjalon: > We are missing some comments about this proposal. > > 24/04/2017 16:50, Andriy Berestovskyy: > > Hey Thomas, > > > > On 21.04.2017 00:25, Thomas Monjalon wrote: > > >> The hardware is different, there is not much we can do about it. > > > > > > We can return an error if the max_rx_pkt_len cannot be set in the NIC. > > > > Yes, we pass the value to the PMD, which might check the value and > > return an error. > > > > >> Nevertheless, we can fix the false comment and have a default for the > > >> jumbos, which is beneficial for the apps/examples. > > > > > > The examples are using a hardcoded value, so they need to be fixed > > > anyway. > > > > We might change the hardcoded values to zeros once the patch is in. This > > will make the examples a bit more clear. > > > > > > > This ethdev patch is about a behaviour change of the API. > > > > The behaviour was not documented, so IMO it is not an issue. > > > > > > > It is about considering 0 as a request for default value > > > and return an error if a value cannot be set. > > > > Right. > > > > > > > It will require more agreements and changes in the drivers > > > for returning an error where appropriate. > > > > IMO the changes are transparent for the PMDs (please see below), but it > > might affect some applications. Here is the change in API behaviour: > > > > Before the patch: > > jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > > jumbo == 0, max_rx_pkt_len == 10, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > > jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > > jumbo == 0, max_rx_pkt_len == 9K, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > > > > jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR > > jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR > > jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > > jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K > > jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR > > > > > > After the patch: > > jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = ETHER_MAX_LEN > > jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR (changed) > > jumbo == 0, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > > jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed) > > > > jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info() > > jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR > > jumbo == 1, max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 > > jumbo == 1, max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K > > jumbo == 1, max_rx_pkt_len == 90K, RESULT: ERROR > > > > Only the apps which requested too small or too big normal frames will be > > affected. In most cases it will be rather an error in the app... > > > > > > Also I have looked through all the PMDs to confirm they are not > > affected. Here is the summary: > > > > af_packet > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = ETH_FRAME_LEN (1514) > > > > ark > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128) > > > > avp > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = avp->max_rx_pkt_len > > rx_queue_setup() uses max_rx_pkt_len for scattering > > > > bnx2x > > configure() uses max_rx_pkt_len to set internal mtu > > info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872) > > > > bnxt > > configure() uses max_rx_pkt_len to set internal mtu > > info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + > > ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4) > > > > bonding > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or > > ETHER_MAX_JUMBO_FRAME_LEN (0x3F00) > > > > cxgbe > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4) > > rx_queue_setup() checks max_rx_pkt_len boundaries > > > > dpaa2 > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240) > > > > e1000 (em) > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, > > 1518, 0x3f00, depends on model) > > > > e1000 (igb) > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = 0x3fff > > start() writes max_rx_pkt_len to HW for jumbo frames only > > start() uses max_rx_pkt_len for scattering > > > > ena > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = adapter->max_mtu > > start() checks max_rx_pkt_len boundaries > > > > enic > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = enic->max_mtu + 14 + 4 > > > > fm10k > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024) > > start() uses max_rx_pkt_len for scattering > > > > i40e > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728) > > rx_queue_config() checks max_rx_pkt_len boundaries > > > > ixgbe > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = 15872 (9728 for vf) > > start() writes max_rx_pkt_len to HW for jumbo frames only > > start() uses max_rx_pkt_len for scattering > > > > kni > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = UINT32_MAX > > > > liquidio > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K) > > start() checks max_rx_pkt_len boundaries > > > > mlx4 > > configure() uses max_rx_pkt_len for scattering > > info() returns max_rx_pktlen = 65536 > > > > mlx5 > > configure() uses max_rx_pkt_len for scattering > > info() returns max_rx_pktlen = 65536 > > > > nfp > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = hw->mtu > > > > null > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > pcap > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > qede > > configure() uses max_rx_pkt_len for scattering + internal data > > info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 - 4 - 4 > > - 12 - 8) > > > > ring > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > sfc > > configure() uses max_rx_pkt_len to set internal data > > info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + 16) > > > > szedata2 > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > tap > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + 4) > > > > thunderx > > configure() uses max_rx_pkt_len for scattering + sets internal mtu > > info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200) > > > > vhost > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > virtio > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U) > > > > vmxnet3 > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = 16384; > > > > xenvirt > > configure() does not use max_rx_pkt_len > > info() returns max_rx_pktlen = 2048 > > > > > > Regards, > > Andriy > > > > > >
Hi Andriy, I think this patch addressing just small issue in a bigger problem. The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). Currently we are forcing it to toggle multiple redundant fields. Wednesday, May 23, 2018 1:31 AM, Thomas Monjalon: > Subject: Re: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame > > > > > > IMO the changes are transparent for the PMDs (please see below), but > > > it might affect some applications. Here is the change in API behaviour: > > > > > > Before the patch: > > > jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = > > > ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 10, RESULT: > > > max_rx_pkt_len = ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == > 1200, > > > RESULT: max_rx_pkt_len = 1200 jumbo == 0, max_rx_pkt_len == 9K, > > > RESULT: max_rx_pkt_len = ETHER_MAX_LEN > > > > > > jumbo == 1, max_rx_pkt_len == 0, RESULT: ERROR jumbo == 1, > > > max_rx_pkt_len == 10, RESULT: ERROR jumbo == 1, max_rx_pkt_len == > > > 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 1, max_rx_pkt_len == > > > 9K, RESULT: ERROR or max_rx_pkt_len = 9K jumbo == 1, max_rx_pkt_len > > > == 90K, RESULT: ERROR > > > > > > > > > After the patch: > > > jumbo == 0, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = > > > ETHER_MAX_LEN jumbo == 0, max_rx_pkt_len == 10, RESULT: ERROR > > > (changed) jumbo == 0, max_rx_pkt_len == 1200, RESULT: > max_rx_pkt_len > > > = 1200 jumbo == 0, max_rx_pkt_len == 9K, RESULT: ERROR (changed) For example in the line above - the application wants to receive 9K frames. Why it is an error? Why forcing the application to set another redundant bit? IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. Same apply to DEV_RX_OFFLOAD_SCATTER flag. Application doesn't need to set it. the PMD will choose the put multiple mbufs in Rx descriptor given the mbuf size and the max_rx_packet_len. API should be informative enough for the application to expect multi-segment packets on the receive. Finally the MTU. It is correct it stands for "max transmit unit" but it is threaded in the same way max_rx_pkt_len is (i.e. MTU sets the max packet len the port receives). We need to either clarify it only address transmit or remove it completely and maybe change max_rx_pkt_len name to mtu. > > > > > > jumbo == 1, max_rx_pkt_len == 0, RESULT: max_rx_pkt_len = dev_info() > > > jumbo == 1, max_rx_pkt_len == 10, RESULT: ERROR jumbo == 1, > > > max_rx_pkt_len == 1200, RESULT: max_rx_pkt_len = 1200 jumbo == 1, > > > max_rx_pkt_len == 9K, RESULT: ERROR or max_rx_pkt_len = 9K jumbo > == > > > 1, max_rx_pkt_len == 90K, RESULT: ERROR > > > > > > Only the apps which requested too small or too big normal frames > > > will be affected. In most cases it will be rather an error in the app... > > > > > > > > > Also I have looked through all the PMDs to confirm they are not > > > affected. Here is the summary: > > > > > > af_packet > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = ETH_FRAME_LEN (1514) > > > > > > ark > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = ETH_FRAME_LEN (16K - 128) > > > > > > avp > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = avp->max_rx_pkt_len > > > rx_queue_setup() uses max_rx_pkt_len for scattering > > > > > > bnx2x > > > configure() uses max_rx_pkt_len to set internal mtu > > > info() returns max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN (15872) > > > > > > bnxt > > > configure() uses max_rx_pkt_len to set internal mtu > > > info() returns max_rx_pktlen = BNXT_MAX_MTU + ETHER_HDR_LEN + > > > ETHER_CRC_LEN + VLAN_TAG_SIZE (9000 + 14 + 4 + 4) > > > > > > bonding > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = internals->candidate_max_rx_pktlen or > > > ETHER_MAX_JUMBO_FRAME_LEN (0x3F00) > > > > > > cxgbe > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = CXGBE_MAX_RX_PKTLEN (9000 + 14 + 4) > > > rx_queue_setup() checks max_rx_pkt_len boundaries > > > > > > dpaa2 > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = DPAA2_MAX_RX_PKT_LEN (10240) > > > > > > e1000 (em) > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = em_get_max_pktlen() (0x2412, 0x1000, > > > 1518, 0x3f00, depends on model) > > > > > > e1000 (igb) > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = 0x3fff > > > start() writes max_rx_pkt_len to HW for jumbo frames only > > > start() uses max_rx_pkt_len for scattering > > > > > > ena > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = adapter->max_mtu > > > start() checks max_rx_pkt_len boundaries > > > > > > enic > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = enic->max_mtu + 14 + 4 > > > > > > fm10k > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = FM10K_MAX_PKT_SIZE (15 * 1024) > > > start() uses max_rx_pkt_len for scattering > > > > > > i40e > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = I40E_FRAME_SIZE_MAX (9728) > > > rx_queue_config() checks max_rx_pkt_len boundaries > > > > > > ixgbe > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = 15872 (9728 for vf) > > > start() writes max_rx_pkt_len to HW for jumbo frames only > > > start() uses max_rx_pkt_len for scattering > > > > > > kni > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = UINT32_MAX > > > > > > liquidio > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = LIO_MAX_RX_PKTLEN (64K) > > > start() checks max_rx_pkt_len boundaries > > > > > > mlx4 > > > configure() uses max_rx_pkt_len for scattering > > > info() returns max_rx_pktlen = 65536 > > > > > > mlx5 > > > configure() uses max_rx_pkt_len for scattering > > > info() returns max_rx_pktlen = 65536 > > > > > > nfp > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = hw->mtu > > > > > > null > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > > > pcap > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > > > qede > > > configure() uses max_rx_pkt_len for scattering + internal data > > > info() returns max_rx_pktlen = ETH_TX_MAX_NON_LSO_PKT_LEN (9700 > - 4 > > > - 4 > > > - 12 - 8) > > > > > > ring > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > > > sfc > > > configure() uses max_rx_pkt_len to set internal data > > > info() returns max_rx_pktlen = EFX_MAC_PDU_MAX (9202 + 14 + 4 + 4 + > > > 16) > > > > > > szedata2 > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > > > tap > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = ETHER_MAX_VLAN_FRAME_LEN (1518 + > 4) > > > > > > thunderx > > > configure() uses max_rx_pkt_len for scattering + sets internal mtu > > > info() returns max_rx_pktlen = NIC_HW_MAX_FRS (9200) > > > > > > vhost > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = (uint32_t)-1 > > > > > > virtio > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = VIRTIO_MAX_RX_PKTLEN (9728U) > > > > > > vmxnet3 > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = 16384; > > > > > > xenvirt > > > configure() does not use max_rx_pkt_len > > > info() returns max_rx_pktlen = 2048 > > > > > > > > > Regards, > > > Andriy > > > > > > > > > > > > > > >
-----Original Message----- > Date: Wed, 23 May 2018 05:21:43 +0000 > From: Shahaf Shuler <shahafs@mellanox.com> > To: Thomas Monjalon <thomas@monjalon.net>, Andriy Berestovskyy > <Andriy.Berestovskyy@caviumnetworks.com> > CC: "dev@dpdk.org" <dev@dpdk.org>, Bruce Richardson > <bruce.richardson@intel.com>, "ferruh.yigit@intel.com" > <ferruh.yigit@intel.com>, "arybchenko@solarflare.com" > <arybchenko@solarflare.com>, "hemant.agrawal@nxp.com" > <hemant.agrawal@nxp.com>, "jerin.jacob@cavium.com" > <jerin.jacob@cavium.com> > Subject: RE: [dpdk-dev] [PATCH v3] ether: use a default for max Rx frame > size in configure() > > Hi Andriy, > > I think this patch addressing just small issue in a bigger problem. > The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). +1 > Currently we are forcing it to toggle multiple redundant fields.
Hi Shahaf, > On 23 May 2018, at 07:21, Shahaf Shuler <shahafs@mellanox.com> wrote: > I think this patch addressing just small issue in a bigger problem. > The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). [...] > IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the normal frame size. The background behind this patch was to fix some examples on some platforms by allowing them to just set the jumbo bit in config and let the DPDK to deduct the optimal jumbo max_rx_pkt_len. There was also another patch which fixed those examples, so they first query the max_rx_pkt_len and then pass it with the config: http://dpdk.org/commit/5e470a6654 That patch has been merged, so now we can fix/change the API in any way we decide, there is no urgency anymore. Looks like the jumbo bit in config is redundant, but there might be other opinions. Andriy
On 5/24/2018 10:20 AM, Andriy Berestovskyy wrote: > Hi Shahaf, > >> On 23 May 2018, at 07:21, Shahaf Shuler <shahafs@mellanox.com> wrote: >> I think this patch addressing just small issue in a bigger problem. >> The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). > > [...] > >> IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. > > Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the normal frame size. > > The background behind this patch was to fix some examples on some platforms by allowing them to just set the jumbo bit in config and let the DPDK to deduct the optimal jumbo max_rx_pkt_len. > > There was also another patch which fixed those examples, so they first query the max_rx_pkt_len and then pass it with the config: > http://dpdk.org/commit/5e470a6654 > > That patch has been merged, so now we can fix/change the API in any way we decide, there is no urgency anymore. > > Looks like the jumbo bit in config is redundant, but there might be other opinions. Back to this old issue, the mentioned inconsistency is still exist in the current code, and this or relevant ones mentioned a few times already. What would you think about developing an unit test on 19.05 to test these on ethdev, and ask vendors to run it and fix failures in next releases? A more TDD approach, first right the test that fails, later fix it. If there is a support I can start writing it but will require support. And related issues: max_rx_pkt_len DEV_RX_OFFLOAD_JUMBO_FRAME DEV_TX_OFFLOAD_MULTI_SEGS scattered_rx mtu These are provided by user as config option, but some drivers updates some of them, initial question is, are they input only or can be modified by drivers. Like if user not requested JUMBO_FRAME but provided a large max_rx_pkt_len, should user get an error or should PMD enable jumbo frame itself? And another question around 'max_rx_pkt_len' / 'mtu', both are related and close. 'max_rx_pkt_len' is frame size as far as I can understand, and since we have capability to set 'mtu', this looks duplicate. And I assume users are mostly will be interested in 'mtu', for given 'mtu' driver can calculate 'max_rx_pkt_len' taking other config options into account affecting frame size.
Sure, Ferruh. Just let me know how can I help you. Andriy > On 23 Jan 2019, at 19:36, Ferruh Yigit <ferruh.yigit@intel.com> wrote: > >> On 5/24/2018 10:20 AM, Andriy Berestovskyy wrote: >> Hi Shahaf, >> >>> On 23 May 2018, at 07:21, Shahaf Shuler <shahafs@mellanox.com> wrote: >>> I think this patch addressing just small issue in a bigger problem. >>> The way I see it all application needs to specify is the max packet size it expects to receive, nothing else(!). >> >> [...] >> >>> IMO The "jumbo_frame" bit can be set by the underlying PMD directly to the device registers given the max_rx_pkt_len configuration. >> >> Sure, it can be deducted in PMD if max_rx_pkt_len is greater than the normal frame size. >> >> The background behind this patch was to fix some examples on some platforms by allowing them to just set the jumbo bit in config and let the DPDK to deduct the optimal jumbo max_rx_pkt_len. >> >> There was also another patch which fixed those examples, so they first query the max_rx_pkt_len and then pass it with the config: >> http://dpdk.org/commit/5e470a6654 >> >> That patch has been merged, so now we can fix/change the API in any way we decide, there is no urgency anymore. >> >> Looks like the jumbo bit in config is redundant, but there might be other opinions. > > Back to this old issue, the mentioned inconsistency is still exist in the > current code, and this or relevant ones mentioned a few times already. > > What would you think about developing an unit test on 19.05 to test these on > ethdev, and ask vendors to run it and fix failures in next releases? > A more TDD approach, first right the test that fails, later fix it. > If there is a support I can start writing it but will require support. > > > And related issues: > max_rx_pkt_len > DEV_RX_OFFLOAD_JUMBO_FRAME > DEV_TX_OFFLOAD_MULTI_SEGS > scattered_rx > mtu > > > These are provided by user as config option, but some drivers updates some of > them, initial question is, are they input only or can be modified by drivers. > > Like if user not requested JUMBO_FRAME but provided a large max_rx_pkt_len, > should user get an error or should PMD enable jumbo frame itself? > > > And another question around 'max_rx_pkt_len' / 'mtu', both are related and > close. 'max_rx_pkt_len' is frame size as far as I can understand, and since we > have capability to set 'mtu', this looks duplicate. > And I assume users are mostly will be interested in 'mtu', for given 'mtu' > driver can calculate 'max_rx_pkt_len' taking other config options into account > affecting frame size.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index 4e1e6dc..2700c69 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -790,6 +790,7 @@ rte_eth_dev_configure(uint8_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; + uint32_t max_len; int diag; RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL); @@ -858,17 +859,23 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, } /* - * If jumbo frames are enabled, check that the maximum RX packet - * length is supported by the configured device. + * Check that the maximum RX packet length is supported + * by the configured device. */ if (dev_conf->rxmode.jumbo_frame == 1) { - if (dev_conf->rxmode.max_rx_pkt_len > - dev_info.max_rx_pktlen) { + max_len = dev_info.max_rx_pktlen; + } else { + max_len = ETHER_MAX_LEN; + } + if (dev_conf->rxmode.max_rx_pkt_len == 0) { + dev->data->dev_conf.rxmode.max_rx_pkt_len = max_len; + } else { + if (dev_conf->rxmode.max_rx_pkt_len > max_len) { RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u" " > max valid value %u\n", port_id, (unsigned)dev_conf->rxmode.max_rx_pkt_len, - (unsigned)dev_info.max_rx_pktlen); + (unsigned int)max_len); return -EINVAL; } else if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN) { RTE_PMD_DEBUG_TRACE("ethdev port_id=%d max_rx_pkt_len %u" @@ -878,12 +885,6 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, (unsigned)ETHER_MIN_LEN); return -EINVAL; } - } else { - if (dev_conf->rxmode.max_rx_pkt_len < ETHER_MIN_LEN || - dev_conf->rxmode.max_rx_pkt_len > ETHER_MAX_LEN) - /* Use default value */ - dev->data->dev_conf.rxmode.max_rx_pkt_len = - ETHER_MAX_LEN; } /* diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h index d072538..ea760dc 100644 --- a/lib/librte_ether/rte_ethdev.h +++ b/lib/librte_ether/rte_ethdev.h @@ -349,7 +349,7 @@ enum rte_eth_tx_mq_mode { struct rte_eth_rxmode { /** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode; - uint32_t max_rx_pkt_len; /**< Only used if jumbo_frame enabled. */ + uint32_t max_rx_pkt_len; /**< If zero, use a default packet length. */ uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/ __extension__ uint16_t header_split : 1, /**< Header Split enable. */
At the moment rte_eth_dev_configure() behaves inconsistent: - for normal frames: zero max_rx_pkt_len uses a default - for jumbo frames: zero max_rx_pkt_len gives an error This patch fixes this inconsistency by using a default value if max_rx_pkt_len is zero both for normal and jumbo frames. Signed-off-by: Andriy Berestovskyy <Andriy.Berestovskyy@caviumnetworks.com> --- Notes: v3 changes: - use a default only if max_rx_pkt_len is zero v2 changes: - reword the commit title according to the check-git-log.sh lib/librte_ether/rte_ethdev.c | 23 ++++++++++++----------- lib/librte_ether/rte_ethdev.h | 2 +- 2 files changed, 13 insertions(+), 12 deletions(-)