[ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for the upcall

Yuanhan Liu yliu at fridaylinux.org
Mon Sep 11 08:32:35 UTC 2017


On Sun, Sep 10, 2017 at 04:40:10PM +0000, Chandran, Sugesh wrote:
> 
> 
> Regards
> _Sugesh
> 
> 
> > -----Original Message-----
> > From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
> > bounces at openvswitch.org] On Behalf Of Yuanhan Liu
> > Sent: Tuesday, September 5, 2017 10:23 AM
> > To: dev at openvswitch.org
> > Subject: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for the
> > upcall
> > 
> > From: Shachar Beiser <shacharbe at mellanox.com>
> > 
> > For the DPDK flow offload, which basically just binds a MARK action to a flow,
> > the MARK is required to be used together with a QUEUE action for the most
> > NICs I'm aware of. The QUEUE action then needs a queue index, which is not
> > given in the flow content.
> [Sugesh] Looks to me this is again another hardware specific req.
> This could have impact on RSS hash distribution and queue redistribution across pmds
> at runtime.

If you have read my earlier version, you should have seen similar concerns
from me.

[...]
> > handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,
> >                       struct dp_packet *packet,
> >                       const struct netdev_flow_key *key,
> >                       struct ofpbuf *actions, struct ofpbuf *put_actions,
> > -                     int *lost_cnt, long long now)
> > +                     int *lost_cnt, long long now, int rxq)
> [Sugesh] IMHO its not really good practice to change the default packet processing path for
> some specific hardware offload. Rxq doesn't have any meaning for handling the packets in normal path.

The same: some concerns I have already expressed before. Unfortunately,
we didn't come up with something better.

> Why cant install flow on all the configured queues for a specific inport? Flow handling is per port, not per queue.
> This will assure the packets will have mark even after the rss hash distribution. 

Like how? The QUEUE action only accepts one queue index. Setting it to
many times will only let the last one take effect. The another possiblity
I'm aware of is with the RTE_FLOW_ACTION_TYPE_RSS, which, unfortunately,
is only supported by Mellanox in DPDK. Yet again, I was told it's not
functional well.

Also, even it could work, I think it still would be probematic. I'm
thinking what might happen for following case.

Assume there is a 5-tuple flow. According to the initial RSS setting by
OVS, all pkts match that flow would be ended up being recieved from one
queue only. If we re-do RSS settings on it, if the RSS settings are the
same, the behaviour might be the same. If not, those pkts which are
supposed to be distributed to one queue only might be distributed to
many queues.

Is it a valid concern?

	--yliu


More information about the dev mailing list