Support for list-match type (P4) for ACLs, pending BMV2 fork

[KrisNey-MSFT]

Related information

Scope - BMv2. DASH ACL defines two new match types - list and range_list. They need to be handled by the simulator, so it can match a field in a packet against a list of values and generate a hit if one of the values in the list matches.

[mqasimfarooqi]

Hi @marian-pritsak,

I am working on adding the list/range_list match type in the simulator.

I needed some clarification on how this match type actually works. How different is it from adding multiple entries? Do we have any sample of how a CLI input for list/range_list will actually look like? Also it would be great if you could share some reference material (e.g any past discussion) to gain further understanding on this match type.

I have identified 3 areas of development, please correct if I'm wrong:

1. json parsing.
2. Runtime handling.
3. Datapath.

I believe support needs to be added in these 3 areas, am I correct?

Best Regards,
Qasim

[mqasimfarooqi]

It seems that support for list-match type also needs to be added in the p4c. We have observed that the table match_type does not update to list in the generated json file. For now we have manually changed the match_type to list in json file to continue development.

Is there any past discussion on how the table match_type is decided if a table contains mix types with list and range_list in them?

We have assumed that for an ipv4 key it would look something like this "0x01010100/24,0x01010200/24" etc. For other key values like protocol an entry would look like "value1&&&mask1,value2&&&mask2".

[KrisNey-MSFT]

@marian-pritsak to reply 4/21/2022

[marian-pritsak]

Hi @mqasimfarooqi

Datapath and runtime for sure, however, what section in JSON are you talking about that is not updated?

[mqasimfarooqi]

Hi @marian-pritsak

p4c generates table_match_type by parsing key match_types using the following rules:

// Decreasing order of precedence (bmv2 specification):
// 0) more than one LPM field is an error
// 1) if there is at least one RANGE field, then the table is RANGE
// 2) if there is at least one TERNARY or OPTIONAL field, then the table is TERNARY
// 3) if there is a LPM field, then the table is LPM
// 4) otherwise the table is EXACT

We have seen that when we have only "list" match-types for keys it does not change table type to "list".

[marian-pritsak]

Yes, this field needs to be also updated to "list".

List and range_list should be in positions 1 and 2 (before LPM and ternary).

[mqasimfarooqi]

@KrisNey-MSFT, I believe p4c is out of scope of this issue. Will there be separate issue for this or an extension to the current issue?

[KrisNey-MSFT]

I'll let @marian ***@***.***> respond... From: Mohammad Qasim Farooqi ***@***.***> Sent: Monday, April 25, 2022 5:39 PM To: Azure/DASH ***@***.***> Cc: Kristina Moore ***@***.***>; Mention ***@***.***> Subject: Re: [Azure/DASH] Support for list-match type (P4) for ACLs (Issue #91) @KrisNey-MSFT<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKrisNey-MSFT&data=05%7C01%7Ckristina.moore%40microsoft.com%7C0e34a211b95f4cc9f2fd08da271d1697%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865303138543425%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AERSoRso2ElNF0nf6asoV%2Fa4tkNGSden40n%2F0vRZcvo%3D&reserved=0>, I believe p4c is out of scope of this issue. Will there be separate issue for this or an extension to the current issue? - Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2FDASH%2Fissues%2F91%23issuecomment-1109173682&data=05%7C01%7Ckristina.moore%40microsoft.com%7C0e34a211b95f4cc9f2fd08da271d1697%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865303138543425%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gha1gx3USKNVkBzhRgasf6BTtNPC53HhHQQVUdMIb%2FY%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFJSI6DWUPD47VMRNXXSW4TVG43IPANCNFSM5SF34JMA&data=05%7C01%7Ckristina.moore%40microsoft.com%7C0e34a211b95f4cc9f2fd08da271d1697%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865303138543425%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hahFps%2Fff2uCCgb9eGXdy5trKDOveDJsQgMRCpftkg8%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[KrisNey-MSFT]

P4C defines the match-type of the table. The compiler code needs to be updated (?); this is out of scope b/c this is only bmv2.
@marian-pritsak is not sure if this affects anything.
Changed the table match type (.json file) to list, to continue dev process.
Based on the key values, it changes the table-match-type. List is not yet implemented in the compiler. Why does bmv2 need to know the table match type, what is it being used for? Being used to make decisions in the code.
We have no preference whether this is a new Issue or continues in this one.
Some development left on the range-list, and open PR in the coming week in Qasim's fork.

[KrisNey-MSFT]

Per @mqasimfarooqi - let's move forward and extend the scope of to encompass p4c and bmv2.

I think, in the first comment, we may change "Scope - BMv2" to "Scope - BMv2,p4c" and add a line in the end to define the other related task which should be "In the compiler, handle list and range_list key values to decide table match type based on precedence.". Rest looks okay.