On 6/8/2016 1:43 PM, Jerin Jacob wrote:

On Wed, Jun 08, 2016 at 01:30:28PM +0100, Ferruh Yigit wrote:

quoted

On 6/7/2016 5:40 PM, Jerin Jacob wrote:

quoted

Jerin Jacob (20):
  thunderx/nicvf/base: add hardware API for ThunderX nicvf inbuilt NIC
  thunderx/nicvf: add pmd skeleton
  thunderx/nicvf: add link status and link update support
  thunderx/nicvf: add get_reg and get_reg_length support
  thunderx/nicvf: add dev_configure support
  thunderx/nicvf: add dev_infos_get support
  thunderx/nicvf: add rx_queue_setup/release support
  thunderx/nicvf: add tx_queue_setup/release support
  thunderx/nicvf: add rss and reta query and update support
  thunderx/nicvf: add mtu_set and promiscuous_enable support
  thunderx/nicvf: add stats support
  thunderx/nicvf: add single and multi segment tx functions
  thunderx/nicvf: add single and multi segment rx functions
  thunderx/nicvf: add dev_supported_ptypes_get and rx_queue_count
    support
  thunderx/nicvf: add rx queue start and stop support
  thunderx/nicvf: add tx queue start and stop support
  thunderx/nicvf: add device start,stop and close support
  thunderx/config: set max numa node to two
  thunderx/nicvf: updated driver documentation and release notes
  maintainers: claim responsibility for the ThunderX nicvf PMD

Hi Jerin,

In patch subject, as tag, other drivers are using only driver name, and
Intel drivers also has "driver/base", since base code has some special
case. For thunderx, what do you think about keeping subject as:
 "thunderx: ...."

Hi Ferruh,

We may add crypto or other builtin ThunderX HW accelerated block drivers
in future to DPDK.
So that is the reason why I thought of keeping the subject as thunderx/nicvf.
If you don't have any objection then I would like to keep it as
thunderx/nicvf or just nicvf.

Ring has similar problem, but we are using same tag "ring:" for both
ring_pmd and ring library.

For this case perhaps we can use net/thunderx, crypto/thunderx ?

I am not aware of any defined convention for the case.

Thanks,
ferruh