2016-02-05 14:58, Pattan, Reshma: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-01-05 16:34, Reshma Pattan: > > > From: reshmapa <reshma.pattan at 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?
