[ovs-discuss] [TC] Request for changes to netlink message population for OVS-TC Flower Offload

Simon Horman simon.horman at netronome.com
Tue Jun 2 08:50:21 UTC 2020


On Fri, May 29, 2020 at 01:45:16PM -0700, Ben Pfaff wrote:
> This seems like something for Simon to look at.
> 
> On Fri, May 29, 2020 at 04:56:11PM +0530, K Chandra wrote:
> > OVS-TC offload sends only fields that are not completely masked out to the
> > TC kernel module. Some of the hardware we work with requires all fields
> > extracted from the packet along with the mask to be sent to the driver.
> > Hardware may optimise tables based on entire fields of packet and mask of
> > field, even though certain fields are masked out. OVS when offloading to
> > ovs kernel datapath sends the entire key along with the mask. Proposal
> > requests for similar behaviour in ovs-vswitchd in case of tc-offload. While
> > constructing netlink messages, ovs-vswitchd is removing completely masked
> > out fields. Sending additional masked fields should not impact existing
> > drivers. TC internally uses dissectors to extract non masked fields, so it
> > should not impact existing drivers in tc.
> > 
> > Example:
> > 
> > ovs-rule:ovs-ofctl add-flow br0 \
> > 
> >     "table=0, dl_dst=00:a1:45:23:23:11/ff:ff:ff:ff:ff:ff, actions=1"
> > 
> > If we have above rule in ovs and an icmp packet matching destination MAC
> > 00:a1:45:23:23:11 arrives, ovs prepares the key and mask with all relevant
> > fields. When sending to TC it removes fields which are completely masked
> > out. In this case ethertype, ip-proto and dst_mac fields are sent as part
> > of netlink message to tc.

Hi K Chandra,

I agree that this is reasonable from a HW perspective and should not pose
a problem for existing HW offload that does not require this (though
perhaps kernel TC or offlaod driver code may need to be updated).

It does seem likely to me that the bulk of this work would likely lie
in modifications to ovs-vswitchd. Are you aware of any existing work in
this area - I am not.

Kind regards,
Simon


More information about the discuss mailing list