On Mon, Jan 06, 2014 at 11:21:07AM +0800, Jason Wang wrote: > Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The > will cause several issues: > > - NETIF_F_LLTX was forced for macvlan device in this case which lead extra > lock > contention. > - dev_hard_start_xmit() was called with NULL txq which bypasses the net device > watchdog > - dev_hard_start_xmit() does not check txq everywhere which will lead a crash > when tso is disabled for lower device. > > Fix this by explicitly introducing a select queue method just for l2 > forwarding > offload (ndo_dfwd_select_queue), and introducing dfwd_direct_xmit() to do the > queue selecting and transmitting for l2 forwarding. > > With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no > need > to check txq against NULL in dev_hard_start_xmit(). > > In the future, it was also required for macvtap l2 forwarding support since it > provides a necessary synchronization method. > > Cc: John Fastabend <john.r.fastab...@intel.com> > Cc: Neil Horman <nhor...@tuxdriver.com> > Cc: e1000-de...@lists.sourceforge.net > Signed-off-by: Jason Wang <jasow...@redhat.com>
Instead of creating another operation here to do special queue selection, why not just have ndo_dfwd_start_xmit include a pointer to a pointer in its argument list, so it can pass the txq it used back to the caller (dev_hard_start_xmit)? ndo_dfwd_start_xmit already knows which queue set to pick from (since their reserved for the device doing the transmitting). It seems more clear to me than creating a new netdevice operation. As for the crash issue, I'm not sure what you mean. Where in dev_hard_start_xmit would we need to check txq that we're not currently, and what crash results? Also, can you elaborate on what you mean by additional lock contention? What contention do you see that goes above and beyond the normal locking required by txq access? I suppose its extra locking above and beyond in the macvtap case, where you would otherwise never hit hardware, but that not the only use case, and I think the solution there is likely to add some code in the macvlan feature set handler so that NETIF_F_LLTX is cleared if you disable the hardware forwarding acceleration via ethtool. Regards Neil > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
