Re: [dpdk-dev] [PATCH] ethdev: add lock-less txq capability flag

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Mon, 24 Apr 2017 14:34:59 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: dev@dpdk.org, bruce.richardson@intel.com, harry.van.haaren@intel.com,
>  hemant.agrawal@nxp.com, gage.eads@intel.com, nipun.gupta@nxp.com,
>  santosh.shukla@caviumnetworks.com
> Subject: Re: [dpdk-dev]  [PATCH] ethdev: add lock-less txq capability flag
> 
> 21/04/2017 14:22, Jerin Jacob:
> > if this flag is advertised by a PMD, Multiple threads can
> > invoke rte_eth_tx_burst() concurrently on the same tx queue
> > without SW lock. This is an HW feature found in some NICs
> > and useful in the following use cases if HW supports it.
> 
> Which hardware supports it?

Cavium OCTEONTX Packet transmission HW block(PKO).

> 
> [...]
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > +#define DEV_TX_OFFLOAD_TXQ_MT_LOCKFREE	0x00004000
> > +/**< Multiple threads can invoke rte_eth_tx_burst() concurrently on the
> > same + * tx queue without SW lock.
> > + */
> 
> Why TXQ in the name? DEV_TX_OFFLOAD_MT_LOCKFREE would be enough.

OK

> I wonder whether "lock free" wording is confusing because
> the locks are probably handled in HW.

Yes. Another reason why it possible because HW is not using ring like scheme(head and tail pointers)
for Tx. "lock free" wording is more from software perspective.

> I think the good wording is "offloaded multi-thread capability",
> maybe with a naming like DEV_TX_OFFLOAD_MT.

I think SW lock free is the capability here.IMO, it better to reflect the
capability in the name(DEV_TX_OFFLOAD_MT_LOCKFREE).

> 
> Anyway we should reference this flag in rte_eth_tx_burst()
> and give more details in doc/guides/prog_guide/poll_mode_drv.rst.

OK. Will address in v2.

> 
> Should we wait a first hardware PoC to add this flag?

If we are in agreement for method expose this feature through capability
flag then should we really need to wait for driver implementation to
accept the patch? Thoughts ?
This flag has impact on how we handle the even dev applications if HW support available.
We are in the process of up-streaming OCTEONTX ethdev driver, but there
are few thing like with external pool manager and eventdev integration
needs to be sorted out cleanly before that.

> Candidate for 17.08?