Re: [PATCH net-next v4 2/5] ipv6: ioam: Data plane support for Pre-allocated Trace

[Jakub Kicinski <kuba@kernel.org>]

On Sun, 30 May 2021 16:50:31 +0200 (CEST) Justin Iurman wrote:
> >> 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?