[dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size

Matan Azrad matan at mellanox.com
Fri Nov 8 07:54:49 CET 2019


Hi

From: Ferruh Yigit
> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> >
> 	RTE_ETHER_MAX_LEN;
> >  	}
> >
> > +	/*
> > +	 * If LRO is enabled, check that the maximum aggregated packet
> > +	 * size is supported by the configured device.
> > +	 */
> > +	if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
> > +		ret = check_lro_pkt_size(
> > +				port_id, dev_conf-
> >rxmode.max_lro_pkt_size,
> > +				dev_info.max_lro_pkt_size);
> > +		if (ret != 0)
> > +			goto rollback;
> > +	}
> > +
> 
> This check forces applications that enable LRO to provide 'max_lro_pkt_size'
> config value.

Yes.(we can break an API, we noticed it)

> - Why it is mandatory now, how it was working before if it is mandatory
> value?

It is the same as max_rx_pkt_len which is mandatory for jumbo frame offload.
So now, when the user configures a LRO offload he must to set max lro pkt len.
We don't want to confuse the user here with the max rx pkt len configurations and behaviors, they should be with same logic.

This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be the maximum size for LRO aggregated packets.
Now, the user must say what is his intension, and the ethdev can limit it according to the device capability.
By this way, also, the PMD can organize\optimize its data-path more.
Also, the application can create different mempools for LRO queues to allow bigger packet receiving for LRO traffic.
 
> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
Yes, you can see the feature description Dekel added.
This patch also updates all the PMDs support an LRO for non-0 value.

as same as max rx pkt len, no?

> - What do you think setting 'max_lro_pkt_size' config value to what PMD
> provided if application doesn't provide it?
Same answers as above.





More information about the dev mailing list