All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Iurman <justin.iurman@uliege.be>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, tom@herbertland.com
Subject: Re: [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for Pre-allocated Trace
Date: Mon, 31 May 2021 13:50:44 +0200 (CEST)	[thread overview]
Message-ID: <1696168387.35309838.1622461844972.JavaMail.zimbra@uliege.be> (raw)
In-Reply-To: <20210530130519.2fc95684@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>

>> >> Last two sentences are repeated.
>> > 
>> > One describes net.ipv6.conf.XXX.ioam6_id (per interface) and the other describes
>> > net.ipv6.ioam6_id (per namespace). It allows for defining an IOAM id to an
>> > interface and, also, the node in general.
>> >   
>> >> Is 0 a valid interface ID? If not why not use id != 0 instead of
>> >> having a separate enabled field?
>> > 
>> > Mainly for semantic reasons. Indeed, I'd prefer to keep a specific "enable" flag
>> > per interface as it sounds more intuitive. But, also because 0 could very well
>> > be a "valid" interface id (more like a default value).
>> 
>> Actually, it's more than for semantic reasons. Take the following topology:
>> 
>>  _____              _____              _____
>> |     | eth0  eth0 |     | eth1  eth0 |     |
>> |  A  |.----------.|  B  |.----------.|  C  |
>> |_____|            |_____|            |_____|
>> 
>> If I only want IOAM to be deployed from A to C but not from C to A,
>> then I would need the following on B (let's just focus on B):
>> 
>> B.eth0.ioam6_enabled = 1 // enable IOAM *on input* for B.eth0
>> B.eth0.ioam6_id = B1
>> B.eth1.ioam6_id = B2
>> 
>> Back to your suggestion, if I only had one field (i.e., ioam6_id != 0
>> to enable IOAM), I would end up with:
>> 
>> B.eth0.ioam6_id = B1 // (!= 0)
>> B.eth1.ioam6_id = B2 // (!= 0)
>> 
>> Which means in this case that IOAM would also be enabled on B for the
>> reverse path. So we definitely need two fields to distinguish both
>> the status (enabled/disabled) and the IOAM ID of an interface.
> 
> Makes sense. Is it okay to assume 0 is equivalent to ~0, though:
> 
> +		raw32 = dev_net(skb->dev)->ipv6.sysctl.ioam6_id;
> +		if (!raw32)
> +			raw32 = IOAM6_EMPTY_u24;
> 
> etc. Quick grep through the RFC only reveals that ~0 is special (not
> available). Should we init ids to ~0 instead of 0 explicitly?

Yes, I think so. And it is indeed correct to assume that. So, if it's fine for you to init IDs to ~0, then it'd be definitely a big yes from me.

  reply	other threads:[~2021-05-31 11:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 15:16 [PATCH net-next v4 0/5] Support for the IOAM Pre-allocated Trace with IPv6 Justin Iurman
2021-05-27 15:16 ` [PATCH net-next v4 1/5] uapi: IPv6 IOAM headers definition Justin Iurman
2021-05-27 15:16 ` [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for Pre-allocated Trace Justin Iurman
2021-05-29 21:05   ` Jakub Kicinski
2021-05-30 10:36     ` Justin Iurman
2021-05-30 14:50       ` Justin Iurman
2021-05-30 20:05         ` Jakub Kicinski
2021-05-31 11:50           ` Justin Iurman [this message]
2021-06-01  4:20             ` Jakub Kicinski
2021-05-30 20:02       ` Jakub Kicinski
2021-05-31 11:43         ` Justin Iurman
2021-06-01  4:21           ` Jakub Kicinski
2021-05-27 15:16 ` [PATCH net-next v4 3/5] ipv6: ioam: IOAM Generic Netlink API Justin Iurman
2021-05-29 21:06   ` Jakub Kicinski
2021-05-30 11:18     ` Justin Iurman
2021-05-30 20:13       ` Jakub Kicinski
2021-05-27 15:16 ` [PATCH net-next v4 4/5] ipv6: ioam: Support for IOAM injection with lwtunnels Justin Iurman
2021-05-29 21:06   ` Jakub Kicinski
2021-05-30 10:48     ` Justin Iurman
2021-05-27 15:16 ` [PATCH net-next v4 5/5] ipv6: ioam: Documentation for new IOAM sysctls Justin Iurman
2021-05-29 15:58 ` [PATCH net-next v4 0/5] Support for the IOAM Pre-allocated Trace with IPv6 David Ahern
2021-05-29 16:24   ` Justin Iurman
2021-05-31  1:24     ` David Ahern
2021-05-31 12:04       ` Justin Iurman
2021-06-03  3:31         ` David Ahern
2021-05-29 21:10 ` Jakub Kicinski
2021-05-30 10:49   ` Justin Iurman

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=1696168387.35309838.1622461844972.JavaMail.zimbra@uliege.be \
    --to=justin.iurman@uliege.be \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.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.