All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Cc: Sasha Levin <sashal@kernel.org>, linux-sctp@vger.kernel.org
Subject: Re: [PATCH] inet_diag: fix reporting cgroup classid and fallback to priority
Date: Tue, 12 Feb 2019 15:03:40 -0800	[thread overview]
Message-ID: <85412c23-fe10-a7cd-5907-ae69ab55784e@gmail.com> (raw)
In-Reply-To: <154970855279.305165.13649851988934332761.stgit@buzz>



On 02/09/2019 02:35 AM, Konstantin Khlebnikov wrote:
> Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
> extensions has only 8 bits. Thus extensions starting from DCTCPINFO
> cannot be requested directly. Some of them included into response
> unconditionally or hook into some of lower 8 bits.
> 
> Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
> 
> This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
> reservation, and documents behavior for other extensions.
> 
> Also this patch adds fallback to reporting socket priority. This filed
> is more widely used for traffic classification because ipv4 sockets
> automatically maps TOS to priority and default qdisc pfifo_fast knows
> about that. But priority could be changed via setsockopt SO_PRIORITY so
> INET_DIAG_TOS isn't enough for predicting class.
> 
> Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
> reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
> 
> So, after this patch INET_DIAG_CLASS_ID will report socket priority
> for most common setup when net_cls isn't set and/or cgroup2 in use.
>

Nice catch Konstantin

Are you planing sending an iproute2/ss patch to output NET_DIAG_CLASS_ID values then ?

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Cc: Sasha Levin <sashal@kernel.org>, linux-sctp@vger.kernel.org
Subject: Re: [PATCH] inet_diag: fix reporting cgroup classid and fallback to priority
Date: Tue, 12 Feb 2019 23:03:40 +0000	[thread overview]
Message-ID: <85412c23-fe10-a7cd-5907-ae69ab55784e@gmail.com> (raw)
In-Reply-To: <154970855279.305165.13649851988934332761.stgit@buzz>



On 02/09/2019 02:35 AM, Konstantin Khlebnikov wrote:
> Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
> extensions has only 8 bits. Thus extensions starting from DCTCPINFO
> cannot be requested directly. Some of them included into response
> unconditionally or hook into some of lower 8 bits.
> 
> Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
> 
> This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
> reservation, and documents behavior for other extensions.
> 
> Also this patch adds fallback to reporting socket priority. This filed
> is more widely used for traffic classification because ipv4 sockets
> automatically maps TOS to priority and default qdisc pfifo_fast knows
> about that. But priority could be changed via setsockopt SO_PRIORITY so
> INET_DIAG_TOS isn't enough for predicting class.
> 
> Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
> reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
> 
> So, after this patch INET_DIAG_CLASS_ID will report socket priority
> for most common setup when net_cls isn't set and/or cgroup2 in use.
>

Nice catch Konstantin

Are you planing sending an iproute2/ss patch to output NET_DIAG_CLASS_ID values then ?

Thanks.

  parent reply	other threads:[~2019-02-12 23:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09 10:35 [PATCH] inet_diag: fix reporting cgroup classid and fallback to priority Konstantin Khlebnikov
2019-02-09 10:35 ` Konstantin Khlebnikov
2019-02-12 18:37 ` David Miller
2019-02-12 18:37   ` David Miller
2019-02-13 12:28   ` Konstantin Khlebnikov
2019-02-13 12:28     ` Konstantin Khlebnikov
2019-02-12 23:03 ` Eric Dumazet [this message]
2019-02-12 23:03   ` Eric Dumazet

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=85412c23-fe10-a7cd-5907-ae69ab55784e@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sashal@kernel.org \
    /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.