Re: [dpdk-dev] [PATCH 0/6] add Tx preparation

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 26 Aug 2016 18:22:52 +0200
Tomasz Kulasek <tomaszx.kulasek@intel.com> wrote:

> As discussed in that thread:
> 
> http://dpdk.org/ml/archives/dev/2015-September/023603.html
> 
> Different NIC models depending on HW offload requested might impose
> different requirements on packets to be TX-ed in terms of:
> 
>  - Max number of fragments per packet allowed
>  - Max number of fragments per TSO segments
>  - The way pseudo-header checksum should be pre-calculated
>  - L3/L4 header fields filling
>  - etc.
> 
> 
> MOTIVATION:
> -----------
> 
> 1) Some work cannot (and didn't should) be done in rte_eth_tx_burst.
>    However, this work is sometimes required, and now, it's an
>    application issue.

Why not? You are adding an additional API burden on every application.

> 
> 2) Different hardware may have different requirements for TX offloads,
>    other subset can be supported and so on.

These need to be reported by API so that application can handle it.
Doing these transformations in tx_prep seems late in the process.

> 
> 3) Some parameters (e.g. number of segments in ixgbe driver) may hung
>    device. These parameters may be vary for different devices.
> 
>    For example i40e HW allows 8 fragments per packet, but that is after
>    TSO segmentation. While ixgbe has a 38-fragment pre-TSO limit.

Seems better to handle these limits as exceptions in i40e_tx_burst etc;
rather than a pre-step. Look at how Linux driver API works, several drivers
have to have an exception linearize path.

> 
> 4) Fields in packet may require different initialization (like e.g. will
>    require pseudo-header checksum precalculation, sometimes in a
>    different way depending on packet type, and so on). Now application
>    needs to care about it.

Once again, the driver should do this in Tx.


> 
> 5) Using additional API (rte_eth_tx_prep) before rte_eth_tx_burst let to
>    prepare packet burst in acceptable form for specific device.
> 
> 6) Some additional checks may be done in debug mode keeping tx_burst
>    implementation clean.

Most of this could be done by refactoring existing tx_burst in drivers.
Much of the code seems to be written as the "let's write a 2000 line
function because that is most efficient" rather than "let's write
small steps and let the compiler optimize it"