On Fri, 23 Sep 2016 13:25:10 -0700, John Fastabend wrote: > On 16-09-23 01:17 PM, Jakub Kicinski wrote: > > On Fri, 23 Sep 2016 10:22:59 -0700, Samudrala, Sridhar wrote: > >> On 9/23/2016 8:29 AM, Jakub Kicinski wrote: > [...] > [...] > >> > >> The 'accel' parameter in dev_queue_xmit_accel() is currently only passed > >> to ndo_select_queue() via netdev_pick_tx() and is used to select the tx > >> queue. > >> Also, it is not passed all the way to the driver specific xmit routine. > >> Doesn't it require > >> changing all the driver xmit routines if we want to pass this parameter? > >> > [...] > >> > >> Yes. The VFPR netdevs don't have any HW queues associated with them and > >> we would like > >> to use the PF queues for the xmit. > >> I was also looking into some way of passing the port id via skb > >> parameter to the > >> dev_queue_xmit() call so that the PF xmit routine can do a directed > >> transmit to a specifc VF. > >> Is skb->cb an option to pass this info? > >> dst_metadata approach would work too if it is acceptable. > > > > I don't think we can trust skb->cb to be set to anything meaningful > > when the skb is received by the lower device. > > Agreed. I wouldn't recommend using skb->cb. How about passing it through > dev_queue_xmit_accel() through to the driver? > > If you pass the metadata through the dev_queue_xmit_accel() handle tx > queue selection would work using normal mechanisms (xps, select_queue, > cls hook, etc.). If you wanted to pick some specific queue based on > policy the policy could be loaded into one of those hooks.
Do you mean without extending how accel is handled by dev_queue_xmit_accel() today? If my goal is to not have extra HW queues then I don't see how I could mux in the lower dev without extra locking (as I tried to explain two emails ago). Sorry for being slow here :(
