Re: [dpdk-dev] [PATCH 7/9] net/virtio: rationalize setting of Rx/Tx handlers

[Yuanhan Liu <yliu@fridaylinux.org>]

On Wed, Sep 06, 2017 at 04:40:12PM +0200, Olivier MATZ wrote:
> On Fri, Sep 01, 2017 at 08:31:06PM +0800, Yuanhan Liu wrote:
> > On Fri, Sep 01, 2017 at 11:52:17AM +0200, Olivier MATZ wrote:
> > > > > @@ -1534,7 +1554,6 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
> > > > >  	RTE_BUILD_BUG_ON(RTE_PKTMBUF_HEADROOM < sizeof(struct virtio_net_hdr_mrg_rxbuf));
> > > > >  
> > > > >  	eth_dev->dev_ops = &virtio_eth_dev_ops;
> > > > > -	eth_dev->tx_pkt_burst = &virtio_xmit_pkts;
> > > > >  
> > > > >  	if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> > > > >  		if (!hw->virtio_user_dev) {
> > > > > @@ -1544,12 +1563,8 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
> > > > >  		}
> > > > >  
> > > > >  		virtio_set_vtpci_ops(hw);
> > > > > -		if (hw->use_simple_rxtx) {
> > > > > -			eth_dev->tx_pkt_burst = virtio_xmit_pkts_simple;
> > > > > -			eth_dev->rx_pkt_burst = virtio_recv_pkts_vec;
> > > > > -		} else {
> > > > > -			rx_func_get(eth_dev);
> > > > > -		}
> > > > > +		set_rxtx_funcs(eth_dev);
> > > > 
> > > > No need to invoke it here?
> > > 
> > > I wanted to stay consistent with previous code.
> > > 
> > > I'm not very used to work with secondary processes, so I'm not 100% it
> > > is ok, but in my understanding, in that case the configuration is done
> > > first by the primary process, and the secondary the pointers to the
> > > rx/tx funcs. I suppose their value can be different than primary ones.
> > 
> > It probably needs some testing, but I think it should be okay, because
> > the rx/tx funcs will always be updated at dev_start in this patch.
> 
> I still have one doubt about this: looking in
> examples/multi_process/symmetric_mp/main.c, I can see that rte_eth_dev_start()
> is only called on the primary process. So if I remove set_rxtx_funcs() from
> eth_virtio_dev_init(), it looks that the rx functions won't be initialized.
> 
> Again, I'm not a user of multi_proc, so I may be wrong, but I think
> it would be safer to keep it.

Yes, you are right.

	--yliu