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

Adrien Mazarguil adrien.mazarguil at 6wind.com
Thu Dec 1 08:19:34 CET 2016


Hi Tomasz,

On Wed, Nov 30, 2016 at 10:30:54AM +0000, Kulasek, TomaszX wrote:
[...]
> > > In my opinion the second approach is both faster to applications and
> > > more friendly from a usability perspective, am I missing something
> > obvious?
> > 
> > I think it was not clearly explained in this patchset, but this is my
> > understanding:
> > tx_prepare and tx_burst can be called at different stages of a pipeline,
> > on different cores.
> 
> Yes, this API is intended to be used optionaly, not only just before tx_burst.
> 
> 1. Separating both stages:
>    a) We may have a control over burst (packet content, validation) when needed.
>    b) For invalid packets we may restore them or do some another task if needed (even on early stage of processing).
>    c) Tx burst keep as simple as it should be.
> 
> 2. Joining the functionality of tx_prepare and tx_burst have some disadvantages:
>    a) When packet is invalid it cannot be restored by application should be dropped.
>    b) Tx burst needs to modify the content of the packet.
>    c) We have no way to eliminate overhead of preparation (tx_prepare) for the application where performance is a key.
> 
> 3. Using tx callbacks
>    a) We still need to have different implementations for different devices.
>    b) The overhead in performance (comparing to the pair tx_prepare/tx_burst) will not be better while both ways uses very similar mechanism.
> 
> In addition, tx_prepare mechanism can be turned off by compilation flag (as discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory dereference and check can have significant impact on performance).

Thanks for the reminder, also I've missed v12 for some reason and still
thought rte_phdr_cksum_fix() was some generic function that applications had
to use directly regardless.

Although I agree with your description, I still think there is an issue,
please see my reply to Konstantin [1].

[1] http://dpdk.org/ml/archives/dev/2016-December/050970.html

-- 
Adrien Mazarguil
6WIND


More information about the dev mailing list