Re: [dpdk-dev] [PATCH v3 0/3] fix RTE_PROC_PRIMARY_OR_ERR_RET RTE_PROC_PRIMARY_OR_RET

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-02-05 14:58, Pattan, Reshma:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-01-05 16:34, Reshma Pattan:
> > > From: reshmapa <reshma.pattan@intel.com>
> > >
> > > Patches 1 and 2 removes RTE_PROC_PRIMARY_OR_ERR_RET and
> > > RTE_PROC_PRIMARY_OR_RET macro usage from rte_ether and rte_cryptodev
> > > libraries to allow API access to secondary process.
> > 
> > I don't understand the use case.
> 
> These changes were added for the use case where vdev has to be configured from secondary process.
> As of now,  secondary process is allowed to create vdev but not allowed to configure it.
> Ex1: tcpdump feature needs these changes. As we create & configure vdev from secondary process.
> Ex2: Sean Harte, initially reported this as limitation as part of his development related to containers proof-of concept. 
> 
> > What is the role of the primary process if queues are configured by the
> > secondary process?
> 
> There can be use cases where  primary and secondary processes needs to configure different queues of same port or needs to configure different PCI ports.
> I assume, users will be aware of PCI port & queue combinations used in primary and will not try to reconfigure them in  secondary.
> 
> > You have not answered to Michael:
> > 	http://dpdk.org/ml/archives/dev/2015-December/030811.html
> > 
> > Other question first asked by Michael
> > 	http://dpdk.org/ml/archives/dev/2015-December/030777.html
> > There are some comments asserting that it is not safe for secondary.
> > And your answer was it is safe for vdev? And what about PCI devices?
> 
> I assume, users will be aware of PCI port & queue combinations used in primary and will  not try to reconfigure them in  secondary.

OK, thanks, good answer.
Anyone against this idea?