Added support for priority queues in switch configuration

[code-a1]

Support for simple switch priority queues in the configuration file can be useful to expand the existing exercises or for future exercises on this topic.

The priority queues number can be defined inside the topology file as follows:

...
    "switches": {
        "s1": { 
            "priority_queues": 8,
            /* Other parameters here */
     }
...

[github-actions]

Welcome to the project, @code-a1!

It looks like this is your first contribution. We noticed the DCO (Developer Certificate of Origin) check might fail if your commits aren't signed.

To fix this, please ensure every commit has a Signed-off-by: Name <email> line. You can do this automatically by using the -s flag:
git commit -s -m "Your message"

For existing commits, you can fix them with:
git commit --amend --signoff or git rebase -i HEAD~N --signoff (where N is the number of commits)
The Developer Community DCO guide also provides helpful tips on fixing DCO inconveniences. Setting a commit hook in the git repository will automate adding the DCO signoff.
See https://github.com/p4lang/governance/wiki/P4-DCO-Guidelines for information.

[Dscano]

Hi @code-a1 ,

As mentioned here you should "sign" your commits #719 (comment).

The PR you proposed only partially improves the tutorial exercises, since we don’t use priority_queues in any of them. Also, since this isn’t a P4 language feature but rather a BMv2 feature, it should be better contextualized if we want to include it.
Perhaps are you proposing this PR as a starting point to add a new exercise that uses priority_queues?

[code-a1]

Hi @Dscano,

I thought this feature would be useful for people interested in expanding existing exercises (which is my case). Allowing more customisation of the topology seems a good idea to me.

I understand that the queues aren't a P4 language feature, but since the tutorials use BMv2, I think it would be useful to show how this can be achieved using this target.

It would be interesting to add an exercise on priority queuing: perhaps someone could use this PR as a starting point.

[jafingerhut]

I have tested with these changes, and it looks what it does what it says on the label. This seems like a useful addition to me, even if no existing exercises use it right now. May as well make it easier for someone to modify an existing exercise, or add a new one, that can take advantage of this capability of bmv2.

[jafingerhut]

@code-a1 I will approve and merge as this is now, but it would be nice to find some nice Pythonic way to avoid the 2*2=4 combinations of passing optional arguments to methods, because that definitely does not scale if there is ever a 3rd or 4th option. I think Python **kwargs parameter with a dict might help here? I am happy to wait until some future PR to improve that.

[jafingerhut]

LGTM

[jafingerhut]

@Code-S1 I cannot merge this until you follow the instructions for signing the DCO. See the earlier comment for instructions on how to do this.

[code-a1]

@code-a1 I will approve and merge as this is now, but it would be nice to find some nice Pythonic way to avoid the 2*2=4 combinations of passing optional arguments to methods, because that definitely does not scale if there is ever a 3rd or 4th option. I think Python **kwargs parameter with a dict might help here? I am happy to wait until some future PR to improve that.

@jafingerhut I completely agree: I was thinking about it while writing the code, but I thought the way I did could be the best way to preserve the style currently used. I can of course implement the feature this other way, which seems cleaner to me.

I also signed the commit.