2016-02-05 14:58, Pattan, Reshma:

From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]

quoted

2016-01-05 16:34, Reshma Pattan:

quoted

From: reshmapa <redacted>

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. 

quoted

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.

quoted

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?