Simple_switch's Control invoking stack is wrong.

[MaoJianwei]

Hi all,

As follow codes,

I track the log-console output as the bottom, ingress goes into callee from A, but when callee returns, callee will return to ingress's B line, and do B.

It looks like the function invoking stack is wrong. How can it happen?

Thanks!

control ingress {

   callee() callee;

    apply{

    if (...) {
      callee.apply();
      do something A.....
   } else {
      if(...) {
          callee.apply();
          do another thing B....
      }
   }
   }
}

[antoninbas]

Juts like https://github.com/p4lang/behavioral-model/issues/465, this looks like a compiler issue.

In this case it actually looks very much like a duplicate of https://github.com/p4lang/p4c/issues/986. bmv2 does not support your program because of its internal table graph representation. You cannot apply the same control twice - even in mutually-exclusive branches - if what you do after each "apply" is not exactly the same. The most recent version of the compiler should reject your program since the issue is marked as resolved. If it's not the case you may want to re-open the compiler issue and submit your program there.

[MaoJianwei]

In my memory, I don't see any exposition for this 'internal table graph representation' in P4-16/14 spec, so is it a limitation just in BMv2? or in Tofino either?

Thanks.

[antoninbas]

@MaoJianwei This is not the appropriate forum to discuss what Tofino can or cannot do. If you have a question about Tofino, please contact Barefoot customer engineering.

[MaoJianwei]

okay, thanks, so this is a special limitation for bmv2?

In my memory, I don't see any exposition for this 'internal table graph representation' in P4-16/14 spec

[antoninbas]

yes, my comment in https://github.com/p4lang/p4c/issues/457 explains why this is a limitation of the current bmv2 implementation and of the JSON representation.

[MaoJianwei]

So it looks like that we can say this is a known bug for a long time in BMv2, do you have a plan to resolve it?

by refactoring bmv2 to avoid 'internal table graph representation' and some way else.

thanks.

[jafingerhut]

@MaoJianwei I would say it is a known limitation in BMv2 that has existed for a long time, by choice and design, because it is considered low priority relative to many other enhancements and bugs being worked on.

If you really, really want a program like this:

if (some_condition) {
    t1.apply();
    t2.apply();
} else {
    t2.apply();
    t1.apply();
}

you can modify your program to duplicate the table t1 as 2 tables with different names, but the same keys and actions, e.g. 't1_copy1' and 't1_copy2'. Then this program should compile:

if (some_condition) {
    t1_copy1.apply();
    t2.apply();
} else {
    t2.apply();
    t1_copy2.apply();
}

If you want t1_copy1 and t1_copy2 to have the same table entries, you can write control plane code that will always add and remove entries to both of them together.

[jafingerhut]

Actually, I should amend my statement somewhat to say that the following program with equivalent behavior should compile:

if (some_condition) {
    t1_copy1.apply();
}
t2.apply();
if (!some_condition) {
    t1_copy2.apply();
}

You could also choose to duplicate t2 if you wish, and then not as many changes would need to be made to the original program in order to successfully compile.

[MaoJianwei]

well