diff mbox

[dpdk-dev,v3] ether: use a default for max Rx frame size in configure()

Message ID 1491562925-27247-1-git-send-email-Andriy.Berestovskyy@caviumnetworks.com (mailing list archive)
State Changes Requested, archived
Delegated to: Thomas Monjalon
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation fail apply issues

Commit Message

Andriy Berestovskyy April 7, 2017, 11:02 a.m. UTC 
  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(-)

Comments

Thomas Monjalon April 7, 2017, 12:15 p.m. UTC | #1 
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?
Bruce Richardson April 7, 2017, 12:29 p.m. UTC | #2 
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
Andriy Berestovskyy April 7, 2017, 2:18 p.m. UTC | #3 
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
Thomas Monjalon April 7, 2017, 2:47 p.m. UTC | #4 
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.
Andriy Berestovskyy April 7, 2017, 3:27 p.m. UTC | #5 
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
Thomas Monjalon April 20, 2017, 10:25 p.m. UTC | #6 
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.
Andriy Berestovskyy April 24, 2017, 2:50 p.m. UTC | #7 
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
Thomas Monjalon July 31, 2017, 10:33 p.m. UTC | #8 
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
>
Thomas Monjalon May 22, 2018, 10:30 p.m. UTC | #9 
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
> > 
> 
> 
> 
>
Shahaf Shuler May 23, 2018, 5:21 a.m. UTC | #10 
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
> > >
> >
> >
> >
> >
> 
> 
> 
>
Jerin Jacob May 23, 2018, 5:23 a.m. UTC | #11 
-----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.
Andriy Berestovskyy May 24, 2018, 9:20 a.m. UTC | #12 
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
Ferruh Yigit Jan. 23, 2019, 6:36 p.m. UTC | #13 
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.
Andriy Berestovskyy Jan. 25, 2019, 9:15 p.m. UTC | #14 
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 mbox

Patch

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. */