[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 11:34:10 UTC 2020


On Tue, Jun 02, 2020 at 04:52:36PM +0530, K Chandra wrote:
> Hi Simon,
> 
> Thanks for the feedback.
> 
> Please find my comments inline.
> 
> Best Regards
> Chandra
> On Tue, Jun 2, 2020 at 2:20 PM Simon Horman <simon.horman at netronome.com>
> wrote:
> 
> > 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).
> >
> I agree that changes are required for kernel TC as well. We identified code
> changes required for kernel TC. We will post the patch to Linux community
> as well.
> 
> >
> > 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.
> >
> All the changes are in ovs-vswitchd only. Will post a patch to ovs-dev
> after testing.

Excellent, please CC me on the patch.


More information about the discuss mailing list