Wed, Mar 02, 2016 at 12:14:39PM CET, gerlitz...@gmail.com wrote:
>On Tue, Mar 1, 2016 at 7:01 PM, Jiri Pirko <j...@resnulli.us> wrote:
>> Tue, Mar 01, 2016 at 05:49:27PM CET, a...@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, a...@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.
>
>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.
