Mon, May 15, 2017 at 10:02:08PM CEST, dan...@iogearbox.net wrote:
>On 05/15/2017 10:38 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <j...@mellanox.com>
>>
>> Introduce new type of termination action called "goto_chain". This allows
>> user to specify a chain to be processed. This action type is
>> then processed as a return value in tcf_classify loop in similar
>> way as "reclassify" is, only it does not reset to the first filter
>> in chain but rather reset to the first filter of the desired chain.
>>
>> Signed-off-by: Jiri Pirko <j...@mellanox.com>
>[...]
>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>> index 1112a2b..98cc689 100644
>> --- a/net/sched/cls_api.c
>> +++ b/net/sched/cls_api.c
>> @@ -304,10 +304,14 @@ int tcf_classify(struct sk_buff *skb, const struct
>> tcf_proto *tp,
>> continue;
>>
>> err = tp->classify(skb, tp, res);
>> - if (unlikely(err == TC_ACT_RECLASSIFY && !compat_mode))
>> + if (err == TC_ACT_RECLASSIFY && !compat_mode) {
>> goto reset;
>> - if (err >= 0)
>> + } else if (TC_ACT_EXT_CMP(err, TC_ACT_GOTO_CHAIN)) {
>> + old_tp = res->goto_tp;
>> + goto reset;
>> + } else if (err >= 0) {
>> return err;
>> + }
>
>Given this goto chain feature is pretty much only interesting for hw
>offloads, can we move this further away from the sw fast path to not
>add up to the cost per packet? (I doubt anyone is using TC_ACT_RECLASSIFY
>in sw as well ...)
I don't think so. First of all, the whole thing would be broken then in
sw. It is useful to have it in sw, at least for testing reasons.
So I would leave the unlikely and add it to the second check as well.
>
>> }
>>
>> return TC_ACT_UNSPEC; /* signal: continue lookup */
>>
