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

On Mon, 31 May 2021 13:50:44 +0200 (CEST) Justin Iurman wrote:

quoted

quoted

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.

Yes, we can init the sysctl to ~0, I don't see why not.