<div dir="ltr"><div dir="ltr">Hi Simon,<div><br></div></div>Thanks for the feedback. <div><br></div><div>Please find my comments inline.</div><div><br></div><div>Best Regards</div><div>Chandra<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 2:20 PM Simon Horman <<a href="mailto:simon.horman@netronome.com">simon.horman@netronome.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, May 29, 2020 at 01:45:16PM -0700, Ben Pfaff wrote:<br>
> This seems like something for Simon to look at.<br>
> <br>
> On Fri, May 29, 2020 at 04:56:11PM +0530, K Chandra wrote:<br>
> > OVS-TC offload sends only fields that are not completely masked out to the<br>
> > TC kernel module. Some of the hardware we work with requires all fields<br>
> > extracted from the packet along with the mask to be sent to the driver.<br>
> > Hardware may optimise tables based on entire fields of packet and mask of<br>
> > field, even though certain fields are masked out. OVS when offloading to<br>
> > ovs kernel datapath sends the entire key along with the mask. Proposal<br>
> > requests for similar behaviour in ovs-vswitchd in case of tc-offload. While<br>
> > constructing netlink messages, ovs-vswitchd is removing completely masked<br>
> > out fields. Sending additional masked fields should not impact existing<br>
> > drivers. TC internally uses dissectors to extract non masked fields, so it<br>
> > should not impact existing drivers in tc.<br>
> > <br>
> > Example:<br>
> > <br>
> > ovs-rule:ovs-ofctl add-flow br0 \<br>
> > <br>
> >     "table=0, dl_dst=00:a1:45:23:23:11/ff:ff:ff:ff:ff:ff, actions=1"<br>
> > <br>
> > If we have above rule in ovs and an icmp packet matching destination MAC<br>
> > 00:a1:45:23:23:11 arrives, ovs prepares the key and mask with all relevant<br>
> > fields. When sending to TC it removes fields which are completely masked<br>
> > out. In this case ethertype, ip-proto and dst_mac fields are sent as part<br>
> > of netlink message to tc.<br>
<br>
Hi K Chandra,<br>
<br>
I agree that this is reasonable from a HW perspective and should not pose<br>
a problem for existing HW offload that does not require this (though<br>
perhaps kernel TC or offlaod driver code may need to be updated).<br></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It does seem likely to me that the bulk of this work would likely lie<br>
in modifications to ovs-vswitchd. Are you aware of any existing work in<br>
this area - I am not.<br></blockquote><div>All the changes are in ovs-vswitchd only. Will post a patch to ovs-dev after testing.               </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Kind regards,<br>
Simon<br></blockquote><div><br></div><div> </div></div></div></div>