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
