search

p4lang / p4runtime

Specification documents for the P4Runtime control-plane API
Apache License 2.0
144 stars 88 forks source link

Support multicast resource information. #472

Closed jonathan-dilorenzo closed 5 months ago

jonathan-dilorenzo commented 7 months ago

On real hardware, multicast resources are presumably finite. While we have a way of capturing that for other tables (with the size parameter) and for action profiles (with the max_group_size parameter), there is currently no way to capture this information for multicast (or for the clone session table for that matter).

This PR is a first stab at adding such a mechanism. In my mind, these fields would be populated by users in the P4 program through the @pkginfo annotation (much like the rest of pkginfo).

Obviously, this is currently a WIP and I'd want to add something to the spec too, but I wanted to see if the idea even made sense first.

jonathan-dilorenzo commented 7 months ago

Yeah, PkgInfo feels a bit weird.

But I don't think we quite want to query the platform for it... Rather, we want to tell the platform our desired capabilities and then it is up to the platform to reject them if it can't fulfill our desires or accept them otherwise. Like with all other tables really. So I think we'd want to fit it into the P4Info somehow...

But good to discuss options in the meeting!

jonathan-dilorenzo commented 7 months ago

Based on discussions in the P4 API WG with @chrispsommers, @smolkaj, and @jafingerhut, there seems to be tentative support for adding something like this (with a few changes I'm about to make) as a short-term solution to modeling multicast resources (and giving the switch a directive to reject a P4Info if it can't).

In the long-term, we want to look into treating multicast like any other P4 table, essentially specifying that a table is a multicast table by attaching something much like an ActionProfile except that it replicates packets to all actions instead of choosing one non-deterministically (or deterministically based on a hash function).

A first approach to the long-term solution might be to disallow applying multicast tables in the P4 program, and then they would instead be applied where ever the architecture uses a multicast table.

We also discussed that these would be useful to provide as capabilities, so I'm gonna try to add that in a follow-up PR. The idea will be that, if the numbers are given in the P4Info, then the capability numbers must be >= to those in the P4Info (or the P4Info should otherwise be rejected). If they are not given, then the switch can still be queried to see how many multicast entries and replicas it supports.

chrispsommers commented 7 months ago

This seems fine as a working idea, but if I were doing this, I'd probably make changes in p4c to vet the idea a bit further.

jonathan-dilorenzo commented 7 months ago

@chrispsommers, to be clear, the "changes in p4c" you're referring to is the annotation interpretation?

chrispsommers commented 7 months ago

@chrispsommers, to be clear, the "changes in p4c" you're referring to is the annotation interpretation?

Correct, the front-end which parses annotations and renders P4Info. You might find a desire to tweak the schema after trying to implement the enhancement.

jonathan-dilorenzo commented 5 months ago

Added support for this PR in https://github.com/p4lang/p4c/pull/4611 (though this would need to go in first, so that the P4Info fields exist to be set).

jonathan-dilorenzo commented 5 months ago

AI: Change multicast_table to multicast_group_table and then send out again for review and we'll try to get this in before next meeting.

jonathan-dilorenzo commented 5 months ago

I think this is now ready for a final review as discussed @chrispsommers, @smolkaj, and @jafingerhut.