On Thu, Jul 19, 2018 at 12:02 PM, Eran Ben Elisha <eranlinuxmella...@gmail.com> wrote: > On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: >> On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha >> <eranlinuxmella...@gmail.com> wrote: >>> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz <gerlitz...@gmail.com> wrote: >>>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <sae...@mellanox.com> >>>> wrote: >>>>> From: Eran Ben Elisha <era...@mellanox.com> >>>>> >>>>> Driver is yet to support aRFS for encapsulated packets, return early >>>>> error in such case. >>>> >>>> >>>> Eran, >>>> >>>> Isn't that something which is done wrong by the arfs stack code? >>>> >>>> If the kernel has an SKB which has encap set and an arfs steering >>>> rule is programed into the driver, the API should include a driver neutral >>>> description for the encap header for the HW to match, so maybe we can just >>>> do >>>> >>> >>> Hi Or, >>> This could break existing drivers support for tunneled aRFS, and hurts >>> their RX performance dramatically.. >> >>> IMHO, it is expected from the driver to figure out that the skb holds >>> encap packet and act accordingly. >> >> I don't think this one bit indication on the skb is enough for >> any HW driver (e.g mlx4, mlx5 and others) to properly set >> the steering rules. > > why do you think it is not enough? > mlx5e currently cannot offload tunneled packets, so this info is > perfectly fit in order to reject.
Do we know that all the flows in stack that deals with reception of packets do this marking for encapsulated packets? is this documented some/where? if this is what we think, then the patch is ok.
