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. > > The problem you indicate typically doesn't come into play in the presence > of VMs, since the host TCP stack isn't active on such traffic. > > This is maybe why it wasn't pointed earlier. > > I believe that more drivers are broken (mlx4?) We can do a fix for that latter. > > Looking now on bnxt, I see they dissect the skb and then check the > FLOW_DIS_ENCAPSULATION flag but not always err. > > If we want to make sure we don't break anyone else, we can indeed have > the check done in our drivers. > > It seems that the check done by bnxt is more general, thoughts? I see bnxt driver checking protocol using this mechanism as well, in mlx5e it was selected via skb metadata, let's keep going with this approach. > > Or.
