From: Petr Machata <petrm@mellanox.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Ido Schimmel <idosch@idosch.org>,
netdev@vger.kernel.org, davem@davemloft.net, jiri@mellanox.com,
jhs@mojatatu.com, xiyou.wangcong@gmail.com, mlxsw@mellanox.com,
Ido Schimmel <idosch@mellanox.com>
Subject: Re: [PATCH net-next 2/6] net: sched: Add centralized RED flag checking
Date: Wed, 11 Mar 2020 00:53:29 +0100 [thread overview]
Message-ID: <87lfo7ydfq.fsf@mellanox.com> (raw)
In-Reply-To: <20200310160052.72e7e09b@kicinski-fedora-PC1C0HJN>
Jakub Kicinski <kuba@kernel.org> writes:
> On Tue, 10 Mar 2020 23:23:23 +0100 Petr Machata wrote:
>> Jakub Kicinski <kuba@kernel.org> writes:
>>
>> > On Tue, 10 Mar 2020 10:48:24 +0100 Petr Machata wrote:
>> >> > The only flags which are validated today are the gRED per-vq ones, which
>> >> > are a recent addition and were validated from day one.
>> >>
>> >> Do you consider the validation as such to be a problem? Because that
>> >> would mean that the qdiscs that have not validated flags this way
>> >> basically cannot be extended ever ("a buggy userspace used to get a
>> >> quiet slicing of flags, and now they mean something").
>> >
>> > I just remember leaving it as is when I was working on GRED, because
>> > of the potential breakage. The uAPI policy is what it is, then again
>> > we probably lose more by making the code of these ancient Qdiscs ugly
>> > than we win :(
>> >
>> > I don't feel like I can ack it with clear conscience tho.
>>
>> Just to make sure -- are you opposed to adding a new flag, or to
>> validation?
>
> They are both uABI changes, so both.
>
>> At least the adaptative flag was added years after the
>> others in 2011. I wasn't paying much attention to kernel back then, but
>> I think the ABI rules are older than that.
>
> Yes, but some (e.g. TC subsystem) didn't really care much about those
> rules until more recently.
>
> The alternative to validation/adding flag in place is obviously to add
> a new netlink attribute which would be validated from the start. Can you
> give it a try and see how ugly it gets?
Yeah, I'll give it a stab tomorrow.
next prev parent reply other threads:[~2020-03-10 23:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 18:34 [PATCH net-next 0/6] RED: Introduce an ECN tail-dropping mode Ido Schimmel
2020-03-09 18:34 ` [PATCH net-next 1/6] selftests: qdiscs: Add TDC test for RED Ido Schimmel
2020-03-10 15:40 ` Roman Mashak
2020-03-10 16:56 ` Petr Machata
2020-03-10 17:28 ` Roman Mashak
2020-03-09 18:34 ` [PATCH net-next 2/6] net: sched: Add centralized RED flag checking Ido Schimmel
2020-03-09 22:18 ` Jakub Kicinski
2020-03-10 9:48 ` Petr Machata
2020-03-10 19:53 ` Jakub Kicinski
2020-03-10 22:23 ` Petr Machata
2020-03-10 23:00 ` Jakub Kicinski
2020-03-10 23:53 ` Petr Machata [this message]
2020-03-09 18:35 ` [PATCH net-next 3/6] net: sched: RED: Introduce an ECN tail-dropping mode Ido Schimmel
2020-03-09 22:12 ` Jakub Kicinski
2020-03-10 9:48 ` Petr Machata
2020-03-09 18:35 ` [PATCH net-next 4/6] mlxsw: spectrum_qdisc: Offload RED " Ido Schimmel
2020-03-09 18:35 ` [PATCH net-next 5/6] selftests: qdiscs: RED: Add taildrop tests Ido Schimmel
2020-03-09 18:35 ` [PATCH net-next 6/6] selftests: mlxsw: RED: Test RED ECN taildrop offload Ido Schimmel
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=87lfo7ydfq.fsf@mellanox.com \
--to=petrm@mellanox.com \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=idosch@mellanox.com \
--cc=jhs@mojatatu.com \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--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.