All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Simon Horman <simon.horman@netronome.com>,
	john.hurley@netronome.com, David Ahern <dsahern@gmail.com>,
	mlxsw@mellanox.com, sridhar.samudrala@intel.com
Subject: Re: [patch net-next v4 03/12] net: sched: introduce chain object to uapi
Date: Thu, 26 Jul 2018 09:38:39 +0200	[thread overview]
Message-ID: <20180726073839.GB2222@nanopsycho> (raw)
In-Reply-To: <CAM_iQpU8EQ+GDPROek7f12oJJeXB5Jp2sUaBSKP4hPBSLNN1dg@mail.gmail.com>

Wed, Jul 25, 2018 at 06:40:44PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, Jul 24, 2018 at 11:49 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Wed, Jul 25, 2018 at 01:20:08AM CEST, xiyou.wangcong@gmail.com wrote:
>> >So, you only send out notification when the last refcnt is gone.
>> >
>> >If the chain that is being deleted by a user is still used by an action,
>> >you return 0 or -EPERM?
>>
>> 0 and the chain stays there until the action is removed. Hmm, do you thing
>> that -EPERM should be returned in that case? The thing is, we have to
>> flush the chain in order to see the action references are there. We would
>> have to have 2 ref counters, one for filter, one for actions.
>> What do you think?
>
>_If_ RTM_DELCHAIN does decrease the chain refcnt, then it is
>broken:
>
># tc chain add X... (refcnt == 1)
># tc action add ... goto chain X (refcnt==2)
># tc chain del X ... (refcnt== 1)
># tc chain del X ... (refcnt==0)
>
>RTM_DELCHAIN should just test if refcnt is 1, if it is, delete it,
>otherwise return -EPERM. This is how we handle tc standalone
>actions, see tcf_idr_delete_index().
>
>Yes, you might need two refcnt's here.

Okay. Sounds good. I'm on it. 

  reply	other threads:[~2018-07-26  8:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-23  7:23 [patch net-next v4 00/12] sched: introduce chain templates support with offloading to mlxsw Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 01/12] net: sched: push ops lookup bits into tcf_proto_lookup_ops() Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 02/12] net: sched: Avoid implicit chain 0 creation Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 03/12] net: sched: introduce chain object to uapi Jiri Pirko
2018-07-24 22:30   ` Cong Wang
2018-07-24 23:20     ` Cong Wang
2018-07-25  6:46       ` Jiri Pirko
2018-07-25 16:40         ` Cong Wang
2018-07-26  7:38           ` Jiri Pirko [this message]
2018-07-26 10:06             ` Jiri Pirko
2018-07-26 12:27               ` Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 04/12] net: sched: introduce chain templates Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 05/12] net: sched: cls_flower: move key/mask dumping into a separate function Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 06/12] net: sched: cls_flower: change fl_init_dissector to accept mask and dissector Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 07/12] net: sched: cls_flower: implement chain templates Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 08/12] net: sched: cls_flower: propagate chain teplate creation and destruction to drivers Jiri Pirko
2018-07-23  7:23 ` [patch net-next v4 09/12] mlxsw: spectrum: Implement chain template hinting Jiri Pirko
2018-07-23  7:24 ` [patch net-next v4 10/12] selftests: forwarding: move shblock tc support check to a separate helper Jiri Pirko
2018-07-23  7:24 ` [patch net-next v4 11/12] selftests: forwarding: add tests for TC chains creation adn destruction Jiri Pirko
2018-07-23  7:24 ` [patch net-next v4 12/12] selftests: forwarding: add tests for TC chain templates Jiri Pirko
2018-07-23  7:24 ` [patch iproute2/net-next v4] tc: introduce support for " Jiri Pirko
2018-07-25 17:03   ` David Ahern
2018-07-23 16:28 ` [patch net-next v4 00/12] sched: introduce chain templates support with offloading to mlxsw David Miller
2018-07-23 23:36 ` Jakub Kicinski
2018-07-24  3:45 ` David Miller

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=20180726073839.GB2222@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jhs@mojatatu.com \
    --cc=john.hurley@netronome.com \
    --cc=mlxsw@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=simon.horman@netronome.com \
    --cc=sridhar.samudrala@intel.com \
    --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.