From: John Fastabend <john.fastabend@gmail•com>
To: Jiri Pirko <jiri@resnulli•us>, Or Gerlitz <gerlitz.or@gmail•com>
Cc: John Fastabend <john.r.fastabend@intel•com>,
Jamal Hadi Salim <jhs@mojatatu•com>, Amir Vadai <amir@vadai•me>,
"David S. Miller" <davem@davemloft•net>,
Linux Netdev List <netdev@vger•kernel.org>,
Or Gerlitz <ogerlitz@mellanox•com>,
Saeed Mahameed <saeedm@mellanox•com>,
Hadar Har-Zion <hadarh@mellanox•com>,
Jiri Pirko <jiri@mellanox•com>
Subject: Re: [PATCH net-next 1/8] net/flower: Introduce hardware offload support
Date: Wed, 02 Mar 2016 08:22:48 -0800 [thread overview]
Message-ID: <56D71358.6040205@gmail.com> (raw)
In-Reply-To: <20160302132222.GB2122@nanopsycho.orion>
On 16-03-02 05:22 AM, Jiri Pirko wrote:
> Wed, Mar 02, 2016 at 12:14:39PM CET, gerlitz.or@gmail•com wrote:
>> On Tue, Mar 1, 2016 at 7:01 PM, Jiri Pirko <jiri@resnulli•us> wrote:
>>> Tue, Mar 01, 2016 at 05:49:27PM CET, amir@vadai•me wrote:
>>>> On Tue, Mar 01, 2016 at 03:47:19PM +0100, Jiri Pirko wrote:
>>>>> Tue, Mar 01, 2016 at 03:24:43PM CET, amir@vadai•me wrote:
>>>>>> This patch is based on a patch made by John Fastabend.
>>
>>>>>> It adds support for offloading cls_flower.
>>>>>> A filter that is offloaded successfully by hardware, will not be added to
>>>>>> the hashtable and won't be processed by software.
>>
>>>>> That is wrong. User should explicitly specify to not include rule into sw
>>>>> by SKIP_KERNEL flag (does not exist now, with John's recent patch we'll
>>>>> have only SKIP_HW). Please add that in this patchset.
>>
>>>> Why? If a rule is offloaded, why would the user want to reprocess it by software?
>>
>>>> If the user use SKIP_HW, it will be processed by SW. Else, the user
>>>> would want it to be processed by HW or fallback to SW. I don't
>>>> understand in which case the user would like to have it done twice.
>>
>>> For example if you turn on the offloading by unsetting NETIF_F_HW_TC.
>>> Or if someone inserts skbs into rx path directly, for example pktgen.
>>> We need SKIP_KERNEL to be set by user, not implicit.
>>
>> As discussed in netdev, we want to have three modes for TC offloads
>>
>> 1. SW only
>> 2. HW only (and err if can't)
>> 3. HW and if not supported fallback to SW
>>
>> Now, from your reply, I understand we want a fourth mode
>>
>> 4. Both (HW and SW)
>
> I would perhaps do it a litte bit differently:
> NO FLAG (default)- insert into kernel and HW now:
> if NETIF_F_HW_TC is off (default)
> -> push to kernel only (current behaviour)
> if NETIF_F_HW_TC is on AND push to HW fails
> -> return error
> SKIP_HW - flag to tell kernel not to insert into HW
> SKIP_SW - flag to tell kernel not to insert into kernel
>
> to achieve hw only, user has to turn on the NETIF_F_HW_TC and
> pass SKIP_SW flag.
>
The modes Jiri describes here is exactly how I planned to build
this. And at the moment the only one we are missing is SKIP_HW
which I'm reworking now and should have in a few days.
To resolve the error handling if the rule is SKIP_HW or NO_FLAG
an error will be thrown if it can not be applied to software.
Notice if an error happens on the software insert with NO_FLAG then
the hardware insert is not attempted either. With SKIP_SW I will
throw an error if the hardware insert fails because there is
no software fallback in this mode.
The only mode I haven't looked at doing is
3. HW and if not supported fallback to SW
I'm not sure I have a use case for it at the moment. It is sufficient
for me to just do a SKIP_SW command followed by a SKIP_HW command
if needed. I guess someone else could implement it if they really need
it.
>
>>
>> Do we agree that these four policies/modes make sense?
>>
>> So you want #4 to be the default? can you elaborate why? note that for
>> the HW marking
>> case a "both" mode will be very inefficient, also for actions like
>> vlan push/pop, encap/decap, etc
>
> Well when you push/pop vlan of encap/decap tunnel header in hw, you won't
> match the packet in kernel again. Most likely. But anyway, if you turn
> on NETIF_F_HW_TC you know what you are doing and you adjust the
> included rules (flags) accordingly.
>
>
>> the result will be just wrong... I don't think this should be the default.
>>
>> Or.
next prev parent reply other threads:[~2016-03-02 16:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 14:24 [PATCH net-next 0/8] cls_flower hardware offload support Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 1/8] net/flower: Introduce " Amir Vadai
2016-03-01 14:47 ` Jiri Pirko
2016-03-01 16:49 ` Amir Vadai
2016-03-01 17:01 ` Jiri Pirko
2016-03-02 11:14 ` Or Gerlitz
2016-03-02 13:22 ` Jiri Pirko
2016-03-02 16:22 ` John Fastabend [this message]
2016-03-02 16:30 ` Jiri Pirko
2016-03-01 14:53 ` Jiri Pirko
2016-03-01 16:50 ` Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 2/8] net/flow_dissector: Make dissector_uses_key() and skb_flow_dissector_target() public Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 3/8] net/act_skbedit: Utility functions for mark action Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 4/8] net/mlx5_core: Set flow steering dest only for forward rules Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 5/8] net/mlx5e: Add a new priority for kernel flow tables Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 6/8] net/mlx5e: Introduce tc offload support Amir Vadai
2016-03-01 14:52 ` Jiri Pirko
2016-03-01 17:00 ` Amir Vadai
2016-03-01 17:13 ` John Fastabend
2016-03-02 15:53 ` Amir Vadai
2016-03-02 15:58 ` Jiri Pirko
2016-03-01 15:59 ` Saeed Mahameed
2016-03-01 17:07 ` Amir Vadai
2016-03-01 14:24 ` [PATCH net-next 7/8] net/mlx5e: Support offload cls_flower with drop action Amir Vadai
2016-03-01 14:55 ` Jiri Pirko
2016-03-01 16:50 ` Amir Vadai
2016-03-01 15:03 ` Jiri Pirko
2016-03-01 14:24 ` [PATCH net-next 8/8] net/mlx5e: Support offload cls_flower with sskbedit mark action Amir Vadai
2016-03-01 14:58 ` Jiri Pirko
2016-03-01 16:53 ` Amir Vadai
2016-03-01 17:18 ` [PATCH net-next 0/8] cls_flower hardware offload support John Fastabend
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=56D71358.6040205@gmail.com \
--to=john.fastabend@gmail$(echo .)com \
--cc=amir@vadai$(echo .)me \
--cc=davem@davemloft$(echo .)net \
--cc=gerlitz.or@gmail$(echo .)com \
--cc=hadarh@mellanox$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@mellanox$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=ogerlitz@mellanox$(echo .)com \
--cc=saeedm@mellanox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox