From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets Date: Thu, 19 Jul 2018 13:29:19 +0300 Message-ID: References: <20180719012612.25907-1-saeedm@mellanox.com> <20180719012612.25907-5-saeedm@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Saeed Mahameed , Eran Ben Elisha , "David S. Miller" , Linux Netdev List , Alexander Duyck , Tom Herbert To: Eran Ben Elisha Return-path: Received: from mail-yw0-f194.google.com ([209.85.161.194]:41450 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726630AbeGSLLt (ORCPT ); Thu, 19 Jul 2018 07:11:49 -0400 Received: by mail-yw0-f194.google.com with SMTP id q129-v6so2861844ywg.8 for ; Thu, 19 Jul 2018 03:29:20 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Jul 19, 2018 at 12:02 PM, Eran Ben Elisha wrote: > On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz wrote: >> On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha >> wrote: >>> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz wrote: >>>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed wrote: >>>>> From: Eran Ben Elisha >>>>> >>>>> 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.