[dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation

Thomas Monjalon thomas.monjalon at 6wind.com
Fri Nov 4 12:35:50 CET 2016


2016-11-01 12:57, Ananyev, Konstantin:
> > > > I suggest to integrate it in the beginning of 17.02 cycle, with the hope
> > > > that you can convince other developers to implement it in other drivers,
> > > > so we could finally enable it in the default config.
> > >
> > > Ok, any insights then, how we can convince people to do that?
> > 
> > You just have to explain clearly what this new feature is bringing
> > and what will be the future possibilities.
> > 
> > > BTW,  it means then that tx_prep() should become part of mandatory API
> > > to be implemented by each PMD doing TX offloads, right?
> > 
> > Right.
> > The question is "what means mandatory"?
> 
> For me "mandatory" here would mean that:
>  - if the PMD supports TX offloads AND
>  - if to be able use any of these offloads the upper layer SW would have to:
> 	- modify the contents of the packet OR
> 	- obey HW specific restrictions
>  then it is a PMD developer responsibility to provide tx_prep() that would implement
>  expected modifications of the packet contents and restriction checks.
> Otherwise, tx_prep() implementation is not required and can be safely set to NULL.      
> 
> Does it sounds good enough to everyone?

Yes, good definition, thanks.

> > Should we block some patches for non-compliant drivers?
> 
> If we agree that it should be a 'mandatory' one - and patch in question breaks
> that requirement, then probably yes.
> 
> > Should we remove offloads capability from non-compliant drivers?
> 
> Do you mean existing PMDs?
> Are there any particular right now, that can't work properly with testpmd csumonly mode?

I cannot answer to this question.
Before txprep, there is only one API: the application must prepare the
packets checksum itself (get_psd_sum in testpmd).
With txprep, the application have 2 choices: keep doing the job itself
or call txprep which calls a PMD-specific function.
The question is: does non-Intel drivers need a checksum preparation for TSO?
Will it behave well if txprep does nothing in these drivers?

When looking at the code, most of drivers handle the TSO flags.
But it is hard to know whether they rely on the pseudo checksum or not.

git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' drivers/net/

drivers/net/bnxt/bnxt_txr.c
drivers/net/cxgbe/sge.c
drivers/net/e1000/em_rxtx.c
drivers/net/e1000/igb_rxtx.c
drivers/net/ena/ena_ethdev.c
drivers/net/enic/enic_rxtx.c
drivers/net/fm10k/fm10k_rxtx.c
drivers/net/i40e/i40e_rxtx.c
drivers/net/ixgbe/ixgbe_rxtx.c
drivers/net/mlx4/mlx4.c
drivers/net/mlx5/mlx5_rxtx.c
drivers/net/nfp/nfp_net.c
drivers/net/qede/qede_rxtx.c
drivers/net/thunderx/nicvf_rxtx.c
drivers/net/virtio/virtio_rxtx.c
drivers/net/vmxnet3/vmxnet3_rxtx.c



More information about the dev mailing list