All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Ariel Levkovich <lariel@mellanox.com>,
	netdev@vger.kernel.org, kuba@kernel.org,
	xiyou.wangcong@gmail.com, ast@kernel.org, daniel@iogearbox.net
Subject: Re: [PATCH net-next v2 0/3] ] TC datapath hash api
Date: Thu, 9 Jul 2020 07:00:26 -0400	[thread overview]
Message-ID: <908144ff-315c-c743-ed2e-93466d40523c@mojatatu.com> (raw)
In-Reply-To: <20200708144508.GB3667@nanopsycho.orion>

On 2020-07-08 10:45 a.m., Jiri Pirko wrote:
> Wed, Jul 08, 2020 at 03:54:14PM CEST, jhs@mojatatu.com wrote:
>> On 2020-07-07 6:05 a.m., Jiri Pirko wrote:


[..]
>> IMO:
>> For this specific case where _offload_ is the main use case i think
>> it is not a good idea because flower on ingress is slow.
> 
> Eh? What do you mean by that?
> 
> 
>> The goal of offloading classifiers to hardware is so one can reduce
>> consumed cpu cycles on the host. If the hardware
>> has done the classification for me, a simple hash lookup of the
>> 32 bit skbhash(similar to fw) in the host would be a lot less
>> compute intensive than running flower's algorithm.
> 
> It is totally up to the driver/fw how they decide to offload flower.
> There are multiple ways. So I don't really follow what do you mean by
> "flower's algorithm"
> 

Nothing to do with how a driver offloads. That part is fine.

By "flower's algorithm" I mean the fact you have to parse and
create the flow cache from scratch on ingress - that slows down
the ingress path. Compare, from cpu cycles pov, to say fw
classifier which dereferences skbmark and uses it as a key
to lookup a hash table.
An skbhash classifier would look the same as fw in its
approach.
subtle point i was making was: if your goal was to save cpu cycles
by offloading the lookup(whose result you then use to do
less work on the host) then you need all the cycles you can
save.

Main point is: classifying based on hash(and for that
matter any other metadata like mark) is needed as a general
utility for the system and should not be only available for
flower. The one big reason we allow all kinds of classifiers
in tc is in the name of "do one thing and do it well".
It is impossible for any one classifier to classify everything
and do a good job at it. For example, I hope you are NEVER
going to add string classification in flower.

Note, what i am describing has precendence:
I can do the same thing with skbmark offloading today.
On ingress I use fw classifier (not u32 or flower).

> 
>>
>> I think there is a line for adding everything in one place,
>> my main concern is that this feature this is needed
>> by all classifiers and not just flower.
> 
> "All" is effectively only flower. Let's be clear about that.
> 

Unless I am misunderstanding, why is it just about flower?
u32 does offload to some hardware. RSS can set this value
and various existing things like XDP, tc ebpf and the action
posted by Ariel.

cheers,
jamal

  reply	other threads:[~2020-07-09 11:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 18:47 [PATCH net-next v2 0/3] ] TC datapath hash api Ariel Levkovich
2020-07-01 18:47 ` [PATCH net-next v2 1/3] net/sched: Introduce action hash Ariel Levkovich
2020-07-01 22:20   ` kernel test robot
2020-07-01 22:20     ` kernel test robot
2020-07-02 20:52   ` Cong Wang
2020-07-01 18:47 ` [PATCH net-next v2 2/3] net/flow_dissector: add packet hash dissection Ariel Levkovich
2020-07-01 18:47 ` [PATCH net-next v2 3/3] net/sched: cls_flower: Add hash info to flow classification Ariel Levkovich
2020-07-03 11:22 ` [PATCH net-next v2 0/3] ] TC datapath hash api Jamal Hadi Salim
2020-07-05 17:26   ` Ariel Levkovich
2020-07-05 21:50     ` Jamal Hadi Salim
2020-07-06  0:28       ` Cong Wang
2020-07-09 13:52         ` Ariel Levkovich
2020-07-06  0:23     ` Cong Wang
2020-07-07 10:05   ` Jiri Pirko
2020-07-08 13:54     ` Jamal Hadi Salim
2020-07-08 14:45       ` Jiri Pirko
2020-07-09 11:00         ` Jamal Hadi Salim [this message]
2020-07-09 12:19           ` Jiri Pirko
2020-07-10 12:04             ` Jamal Hadi Salim
2020-08-07 10:41               ` Jamal Hadi Salim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=908144ff-315c-c743-ed2e-93466d40523c@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=lariel@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.