Hi Bruce -- >The sharing of the mbuf pool is not an issue, but sharing of rx/tx queues is. >The ethdev queues are not multi-thread safe, so to share a queue between processes >or threads, you need to put in locks or other access control mechanisms. [This >also implies a performance hit due to the locking] >Regards, >/Bruce
Right. So now we have only one process to do rx/tx on queue 0 if we detect that max queue support is 1. However, we have noticed that if our process, which does rx/tx, is not primary, then we can't transmit the packet out with SR-IOV. Is there any specific limitation on SR-IOV (the vf driver in dpdk) that only primary process should receive and transmit packets? In our model, we have an agent process which monitor links and another process which does packet processing. If we make our agent process as primary then our secondary process is not able to send the packets -- rte_eth_tx_burst() succeed but recipient does not receive the packet. Thanks, /Saurabh On Sat, Jan 23, 2016 at 8:09 AM, Bruce Richardson < bruce.richardson at intel.com> wrote: > On Thu, Jan 21, 2016 at 08:35:20PM -0800, Saurabh Mishra wrote: > > Hi, > > > > > > Is it possible for two or more processes to share the same mbuf_pool in > > SR-IOV with single rx/tx queue? > > > > > The sharing of the mbuf pool is not an issue, but sharing of rx/tx queues > is. > The ethdev queues are not multi-thread safe, so to share a queue between > processes > or threads, you need to put in locks or other access control mechanisms. > [This > also implies a performance hit due to the locking] > > Regards, > /Bruce > >
