From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cong Wang <xiyou.wangcong@gmail.com>
Subject: Re: [PATCH net-next v3 4/5] net/tc: introduce TC_ACT_REINJECT.
Date: Tue, 24 Jul 2018 13:50:44 -0700
Message-ID: <CAM_iQpWEUz8ASVkAR7-dpAOB75f5To0KL32VgaNciwx-JaqOOA@mail.gmail.com>
References: <cover.1532437050.git.pabeni@redhat.com> <3c20787be0fd5d64728ffed46ae0a7dff10d7e05.1532437050.git.pabeni@redhat.com>
 <CAM_iQpUHjoohcMgXd8y9GVn8hdFwMRGJeCJ5wSfphModf0qZ-A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
        Eyal Birger <eyal.birger@gmail.com>,
        David Miller <davem@davemloft.net>
To: Paolo Abeni <pabeni@redhat.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pl0-f65.google.com ([209.85.160.65]:45934 "EHLO
        mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2388787AbeGXV7M (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 24 Jul 2018 17:59:12 -0400
Received: by mail-pl0-f65.google.com with SMTP id j8-v6so2209748pll.12
        for <netdev@vger.kernel.org>; Tue, 24 Jul 2018 13:50:57 -0700 (PDT)
In-Reply-To: <CAM_iQpUHjoohcMgXd8y9GVn8hdFwMRGJeCJ5wSfphModf0qZ-A@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, Jul 24, 2018 at 1:38 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Tue, Jul 24, 2018 at 1:07 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > +static inline void skb_tc_reinject(struct sk_buff *skb, struct tcf_result *res)
> > +{
> > +       struct gnet_stats_queue *stats = res->qstats;
> > +       int ret;
> > +
> > +       if (res->ingress)
> > +               ret = netif_receive_skb(skb);
> > +       else
> > +               ret = dev_queue_xmit(skb);
> > +       if (ret && stats)
> > +               qstats_overlimit_inc(res->qstats);
>
> Why increasing overlimit? Overlimit is typically increased
> by traffic shapers to indicate there is no bandwidth to send
> out the packet.
>
> I fail to understand why overlimit is increased in your case
> here. I guess you want to increase 'drops' instead.

Hmm, actually the current mirred code increases overlimit too.
But I still don't think it makes sense.