DASH Community Weekly, 17 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SONiC DASH Workgroup Community Meeting May 17 2023

Description

-More Tags, bitmap API, rule expansion discussion.
-Should NB 'look like' SB ?
-(Problem is ACL Tag definition(Tags API) - although this is Optional for technology supplier)
-Does the bitmap scale to a large # of tags? The opposite API is more efficient. Can different SAI implementations size up to larger # of tags (such as 256)?
-Should we think about handwriting SAI API for tags, with code above bmv2 to expand prefix list and place into bmv2?
-If anyone has an alternative, please do propose a new SB API.

A

For coming to the dash Community call for May 17th, it's our 69th meeting today, so um I'm showing on my screen, is what we talked about last week in the the meeting notes from last week, and we had a huge long discussion around Apple tags matching again and again how it relates to the P4 behavioral model.

A

So um I don't know if y'all read my notes, but it looks like the takeaways that we we needed to come up with a well-designed PSI interface and we wanted P4 to implement the match logic of the feature that was kind of the takeaway. That I got from the conversation from last week and that pretty much took up the entire hour.

A

um I took these notes. I hope you all got them and were able to go through them and could someone on the call tell me if you're getting these.

B

A

Okay, cool cool, all right, and so um so that's what we had for last week, I, don't know if anyone had some ideas in the seven days since we've talked about, um you know how to go about coming together on this or, if I need to start joining the P4 calls, or something like that. um Did you guys have any ideas.

C

So I did some experimentation and basically did a quick check on the P4 code, updated it to basically produce um the prop. What I think is the proper apis um and I did integrate that into my site and did some testing and it worked good, but you know obviously recorder.

C

It's the P4 change lookup that doesn't really you know, I'll just added it here, make sure that it gets compiled and generates what's needed, I needed to add some stuff to RPC to support list and whatnot, but bottom line is how do you test out in P4, like.

B

C

Part of the bmv2 regression I.

B

C

What I do know is I can produce the proper apis to me proper meaning. What was intended.

A

C

So I'm not sure how we go from there to. In my opinion, it's a control plane feature, but it's nice to have apis for that, because everybody can benefit from that.

C

You know yeah now, whether or not you do a data plane lookup to figure out your tag, I mean that's, that's the that's the problem. How do you? How do you figure that one out it's actually from a prefix? You figure out all the tags that are possible because it's at least and then you use that list alongside the um alongside the uh sorry, the prefix and and the F4 ports into the ACL lookup.

C

So for my API it can be done. Okay,.

A

Thanks Vincent for doing that, um do anyone have any questions for Vincent on that.

D

Yeah I had one question: is it possible to use and use this I'm not uh not very conversant with the P4 and the BMV to model, but is it possible to use an extern to do this.

C

Choose the next turn, what do you mean for.

D

The ACL lookup per se instead of a direct table.

C

C

The problem is to to to model this I API is generated based on P4, which is unfortunate for these case or whatever we have now. Those email opinion doesn't work. It's not even related to the ecl itself.

C

This yard itself still has um the pro. The definition now that is run by bme2 is not exactly what we should be running because it doesn't use list at all, but it's got the source tag and the destination tag there. Now the ternary so I changed that, because that's not proper. In my opinion, it should be just a list of tags, so I changed that, but that's minor and that can be changed easily. That's fine! The problem is the ecl tag diffusion itself, so you kind of need to do a a table lookup.

C

If you will with the proper argument in this case it would be uh attack to to get the proper API. That is a tag with attributes which is a bunch of prefix. You basically need a table lookup that takes the tag and gives you a prefix.

C

And then you have some of the rides on the on the side, types and whatnot, but that's the lookup you need which doesn't really make sense as a lookup. But that's what you need as far as stable definition and doing the pry on in the P4 code to get all that side. Api generated.

D

Got it yeah now what what I was this thing I was thinking was, if we could hand write these uh special apis. You know these apis, which are harder to this thing, handwrite them and use an extern to actually do whatever we want to do right. In that way, we have Best of Both. Worlds is what I was wondering.

C

It's a little bit more complicated than that, because not only do you have this IPI, but you have all the site with code. You got all a bunch of stuff that gets generated based on that, so you can actually test that you saw API in the test case in the python test case. There's a generate set of apis that move basically based on this I API. Definitely the P4 definition so there's a whole lot of things that get generated just on that, so it's fairly transparent, it's very transparent, it's great, but it's not an extern.

C

E

More yeah I can make a comment on that too. I'm creating in custom externs creates a different problem. That is what is the P4 runtime API for that customer extern, because that's ultimately how we program the bmb2 model. We translate PSI into P4, runtime and P4 runtime does not. Let's say it's not easy without modifying P4 runtime itself to create new extern definitions for the control plane, I see and we're actually working on that very topic. Right now in the P4 API working group.

D

Isaac yeah I was thinking something like that would mean uh kind of give us a tool where we can have uh when, when it's very tough to generate an API or we run into such problems, we could I thought it would be a good tool to yeah kind of be couple decouple. The uh complexity of defining the P4 natively right.

E

The clean API, the other problem that begs, is okay. What's going to execute that in our model, we'd have to modify bmv2s back-end code to execute that extern in order to get a meaningful output, so it doesn't really fix the problem. It moves it around. I.

D

See so could that be a c program or something that is written in see that we and at least uh the extern kind of defines what we do, but it's still not in P4, but in c.

E

P, plus plus back end, which is always looking for volunteers, to help extend.

C

The the question I have, though, is I think from a control plane standpoint, it's nice to have these SEO tags now. Should the lookup have vcl tags, I, don't know that it wouldn't make sense to have, though um I don't know, I really, don't know it's a hard problem to fix there. I just don't know how we do it. That's all.

F

Oh I mean this was I think discussed last week, but it I think somebody mentioned. Maybe John Carney, like the fact that you're generating a PSI API that you want from a P4 program. Unmodified is kind of like the tail wagging the dog.

A

F

From the application to the you know, the site API, you want make the piu-1 it's not that hard I, don't think I mean it doesn't need to be auto-generated. Does it not 100 like if the tag stuff is at sticking point generate that write that part by hand and draw the rest so.

C

I mean I could easily add a table and then apply in the P4 to get what I wanted, and that allows me to test it all the way through I'm, not using bmv2 as my data plane, obviously, um but that that's the easy part for me. That's the.

F

Easiest way, but if you want, but if you want to date it then you also still want a data plane that behaves yeah.

C

F

Api you want, and you want a reference model that process packets after you've integrated with that API. Yes,.

B

F

A way to do that, but I, don't think it's by making the P4 program Auto generate every bit of the site API. That seems wrong to me.

C

Okay, but at the end of the day you got it's going to take time to get that BMV to model to test this, so I think the question is, we are I, think we know what we want. I just don't know what the timeline is. What that is.

F

So if you don't want to hack on bmv2, there's a way to do it, and that would be to handwrite this I API for tags and then have a little bit of code above the behavioral model that just expands tags into their prefix list.

F

C

Should we is that part of the Json PR, like you, expand the PRT Json file.

F

No, no! No at run time. Suppose somebody says: oh I want to create a tag with this 100 prefixes. Oh I want to create another tag with this hundred. This thousand prefixes. Oh I, want to create a rule that has that Source tag and that test tag there's a little bit of code.

F

That runtime says: oh, when you create that rule, do the 100 times a thousand cross product and put that into BMV too just a little bit of c, plus c or C, plus plus code that expands out the tags before putting them in the the data plane. Yeah.

C

I, just don't know how that relates to the Epi generation and all that so anyway, the.

F

Api would be written by hand for the tags by hand exactly.

G

I think I think we have. uh We have discussed it uh last week as well. So the point is: we have a definition Now with uh PSI actual bitmap uh stuck right, and uh if there is another proposal the community can propose- and we can discuss on that, but I think in the current model.

G

This is all flexible like we have a capability and if the implementation provides a capability of bitmap, we will go with the the current model and then, if, if there is another capability that the implementation can provide, then we can go with the second. The other proposal so I think look.

C

The prime we talked about that again last week, I recover all these current P4 code with the bitmap just doesn't serve the proper site API. It just doesn't work so.

G

So for the the currents IAP where it shows 32-bit.

B

G

Bitmap is that what is the concern.

C

It's just you basically flip the problem.

G

Yeah yeah, so what I'm saying is we'll it? It depends on the sign implementation because we have the capability right. So if there is a different capability that the implementation can support, we'll go with the second approach or or the next or the The Proposal that you are providing so Define, the the rest of the things are cycled. What how we want the accult roles to be, and then we can discuss it here there as a it's a different proposal.

C

So what we thought about last week- and it's one in the slides here is not only is this IPI, it's the match, Aussie. What you have now doesn't work. It doesn't no.

G

C

You have there the.

G

C

And what you have are different I guess. That's one point.

G

The Northbound is for uh Sonic and the orcasian to to to implement right, so we don't want one-to-one mapping from the Northbound to the size. So today we have a side definition with bitmap and we have also introduced the capability model so with that capability model. If uh if that is not the implementation that supports it, fine like so provide a different implementation and we can. We can discuss the proposal. No.

C

I'm not even looking about Northbound I'm, I'm above side, yeah, I'm, right, I'm right at the side level, I, don't.

G

Care about Sony, we have SI um right.

C

Just one thing: the site API that you have could make it work the model you have doesn't have on the left side. Here you see the rule mat Logic, the lookup you do is told it's not that it's it's incorrect doesn't match the requirement. The requirement still is at the side level and the bmv2 behavior. What you have now doesn't match I'm. Sorry. It.

G

It it matches our requirement right, I mean no.

C

No, it doesn't. We proved last week that that there are problems, so it's like, or instead of being it's an N instead of being.

G

An order clarified in the in the pr like if it is ordered, we will expand the rule, so uh I'm not sure like if you again like last week also, we discussed like to go and look at the the pr that was um yeah or the requirement. So so, basically, if there is a Northbound that has uh both tags and prefix, the the work agent will will expand that so I I, don't know why we are keep saying like Okay.

G

There is an implicit or assumption that uh the PSI implementation has to take so I think the can contention here is about that. The tag bitmap, which there is one proposal and based on capability, we will use either that or no tags or if there is a third proposal. Okay, let's have it in the community, and we can discuss that French.

E

For clarification, are you? Are you saying when you keep saying capability? Maybe we need to unpack that a bit? Are you saying that the PSI implementation can expose the capabilities? Okay, I support this particular version of the API, the bitmap one or in the future. If we have an improved one, I support this one and you're saying it's up to the Target to decide which one and we can accommodate different ones as optimizations of.

G

This, yes, that's what I meant like here in this uh section I what I Define this? If the bitmap is something that uh the implementation cannot support, it can return, let's say value 0, so we will not use the bitmap at all.

E

um We Define the capability API for oh for.

G

That we can Define easily right I mean that's not something.

H

Complemented the com, common uh capability, API or.

G

Will there be I mean that that capability we can incorporate to to either the comment section or actual capability section, so I think that's not the concern. So I thought we. What we have as a problem is the the whole notion of this bitmap and reverse uh mapping from the prefix to the tag. So we we have this proposal. We have the the PSI APS based on this. If there is a second one, I think, let's have it as a proposal and uh we can.

I

G

How that works.

I

I I think the other problem with the tag. Sorry, this is John I'm speaking.

I

um The other problem with the tag is that it forced like a multiplication or a cross product of rules to be inserted. So.

G

Again like if, if that's that's all depends on how the PSI is going to be implemented right, if.

I

So if you say you're capable of doing like multiple tags per rule, then only a single rule will be inserted if you're.

G

I

Capable of that, then multiple rules will be inserted. Okay,.

C

I

C

I have is, why are we then okay? Well, we have now here doesn't make sense to me. I already said that.

G

G

C

Ponies? Why do we even have that then, because it's it's not really usable? In my opinion, that's.

G

What I'm saying implementation that is capable of supporting bitmap or size, 8 or 32, or what not right they can leverage this okay.

C

Let me let me rephrase that, okay, if, if this IPR, doesn't look like this but looks like what we um documented last week, what's on the left side, that.

G

Is that's kind.

C

Of the the final implementation, if you will now you have this solution here that, in my opinion, doesn't work doesn't work properly.

C

Backward, it doesn't make sense to me the appliance with the set. There are problems with various things at this IPI level. You're gonna basically have the occasion probably replicate rules. Do all this extra work. Until maybe you finalize a different model, you go to to another model, and then we all have to rework everything.

C

This IPI will need to change. It's it's constant work for something that. Why do we even bother right now? I guess right.

G

No I think that's the whole point. I make mistake like we are continued to discuss the same thing over and.

B

G

Again like so, we can have all these as a as a as a record like okay for first capability. This stacking is using the bitmap construct. If, if it's a different one, then let's have a proposal and maybe the work engine implementation can do, do it in a different way.

C

But but because you flip the API itself, it's not even a tag, it's a list of prefix anymore. So what's going to be the next one, it's going to be totally different. It's gonna, I, don't know if we don't have a proper solution now, I, don't I, don't even know why we bother adding.

G

It I think this solution um has its Advantage. If, if there is a bitmap that can be supported by the side, implementation right um and where the the mapping is just based on single, but.

I

I think the problem with the bitmap I mean one problem with the bitmap is that it just doesn't scale to a large. You know number of tags. What you end up, having is an API where you program a prefix with like an extremely sparse bitmap like maybe one bit is set or two bits or set in the bitmap.

I

It seems like completely inefficient for like a large number of tags, where the, where the opposite API it's efficient, no matter whether you have a large number of tags or a small number of tags, it's like a much more efficient API, um uh so I I I, you know- maybe someone says okay, I'm capable of the bitmap API, with a width of 32 I. Just don't see how a width of 32 tags is even useful. You know and for um uh you know, any kind of deployment, um so it you know the API can exist.

I

You could say you're capable of it, but if you're not capable of it at some large scale,.

A

G

But but that's that's again like if the the PSI implementation can specify the bitmap size of let's say, 256 or something it can be. It is flexible right like it. It can extend up to that size. We.

C

Go to 4K tags, don't we yeah.

G

For the Northbound, that's for the Northbound So, based on the PSI capability, the the old kitchen can tune to that. So our requirement from from a Northbound side perspective is 4K. Yeah.

A

G

Don't know outside.

A

G

No South Side is southbound is based on the capability.

I

Right so Prince I think my my understanding of like why we even want to express tags in the southbound interface is because the data plane implementation might be able to take advantage of it to save memory footprint or you know, um I I think that that I I I, you know I think in theory. Maybe you know yes, I understand that statement, I think in practice um it's almost meaningless. I think that the that the memory is completely dominated by the flow table.

I

um You know- uh maybe perhaps if someone were implementing this with tcam I.

G

Mean that part I think we can let the implementation Force to chime and right like if they, uh if they do save memory based on this model, right.

I

Yeah I mean I I, I, I I, think that you know what it is. It's like it's like anything else. It's a memory, verse verse time trade-off. The the tags require you to do more lookup that lookup can take extra time or extra memory accesses, and in exchange for that, you can save memory, there's a trade-off there, but but I I I mean looking at this myself. I I don't see like any benefit to even supporting tags in the data plane.

I

um I think like you.

B

G

I

You would say, is that's fine, you just say you're, not capable of.

G

Testing exactly that's the point, you just say it is expand. It.

E

Yeah, just looking at this as sort of an outsider since we're not not implementing anything ourselves, will help test. There's a there's, a risk that the particular proposal as it's been. The initial proposal would have been that it's gonna it's selling a bit of compute. We have a bit of confusion now and if you define it as a capability, that's optional, why would any vendor I'll just ask this rhetorical question? Why would anyone implement it?

E

How would they be motivated if it's optional at this point, someone could say well, ah this is kind of murky, I think I'll pass and we haven't gained anything because it doesn't seem to be compelling enough and there's no mandatory requirement to do it. Why would someone do it unless there was real benefits that are.

G

Compatible yeah, so so, basically, if if they provide uh so here like again, if you don't provide the bitmap, uh what happens is for each actual rule, we'll expand the entire list of prefixes to the side right and that can.

G

Implementation, so if they, if they can leverage with the the bitmap and can save the memory for their implementation, that's that's where it comes into.

E

I see so there.

G

E

Be a built-in incentive for some range.

G

E

Absolutely is enough to cover use cases of Interest no.

G

Not 32 right like it, it is based on their capability that bitmap size is based on the capability. So if I, if they return 128 bit, then it can save like enormous amount of memory by not replicating the the prefixes all.

E

Right any you know, without identifying anybody has have you embedded with any vendors that this is going to be compelling value. I mean outside of this meeting without naming names.

G

C

White vendors are fine with the bitmap implementation, because I wouldn't.

G

Be I mean, but yeah I mean that that's what we got the feedback.

C

The other thing, too, is um even from a BME to model um they work. Okay, let's say you stay with that and you do your RPM lookup. Well, you got to figure out. There were cases with different prefixes lengths and stuff like that overlap, basically, where you wouldn't even resolve to the right tag. I think Andy was talking about that.

A

um You would not resolve to the.

C

Right all right, that's weird I think we had to test cases where uh we we had a thought at least to put together, uh I, think and decorum, if I'm wrong, but uh a case where it wouldn't be obvious that you would fetch the proper attack.

C

Maybe I'm misunderstood that my.

F

Understanding is if the, if the proposal is that with the bitmaps is, if you've got like a I, don't know a source rule that has I, don't know 50 bit set in a two Fitbit map and a destination address bitmap that has 30 bit set. Then some layer of software before the data plane is going to expand that into 50 times, 30.

F

bitmaps. That sounds correct.

F

Because I know, that's that's correct Behavior according to what they're, what they want. It's it's some expansion, it's much less expansion than if you expanded up to 50 times, 30 list the prefixes I. Imagine so there is some memory savings that I guess.

I

But but Andy I think that that expansion is only necessary if you don't support the the match logic you know like. If, if the ACL implementation could support like the correct match or Style Match logic, then you wouldn't need any rule. Expansion uh to support tags right so.

F

That's like I, don't have a hardware that does that, but I can imagine Harvard. That does that right.

I

I mean you know, like we talked about this last week, like you know, certainly like in a c um uh algorithm. I could just Loop over everything and I I could support that kind of match. Logic right um and uh you know, might not perform well, but but but you can perform that kind of match logic and so I think that that also has to be a capability. It's not just. Do you support tags? Do you support tags? Do you support bitmap? Do you require rule expansion right because, like.

B

I

The rule expansion, I think, is a big problem like I. Think that that you know so maybe supporting tags is good, um but you know one implementation might say: hey I, support tags, but I don't want rule expansion.

I

um So, like I think you know, I think if the like, in order for this, to be sort of flexible enough to allow the implementations to take advantage of of of you, know, tags in order to save memory or in order to perform better. Like it's multiple capabilities that have to be expressed. For this feature not just.

G

So so in that is what I'm saying: that is what also uh um I'm, also saying where, if the bitmap size is zeroed, we can introduce another capability. That says, don't do rule expansion, but I do support tag right, yes, and that can be another capability and the and the work agent can be implemented to just pass the tag list and um and and uh match to that that particular implementation so do.

C

You do you realize how complicated this become now, because.

A

B

C

Is not proper I'm, just only other five we're adding now three capabilities.

G

If we don't have an agreement on one proposal, then we need to have. uh We need to have provide that flexibility right. We cannot make every sign or whether to implement the same thing that uh that's proposed here right. So we can have that's why the capability comes into play. So.

C

G

C

What I say you know with a simple P4 change: I can create the API that matches what I was expecting, what you call a Dark Bond, but to me that's the same. This IPI should look the same way. Simple one I mean.

H

G

C

Capability needed and all that now we still have to figure out the BMV to model.

G

C

G

So I think that if you have that, let's have that as a proposal and we'll discuss uh that different uh model in the in the.

C

But it doesn't require all those capability things that we keep piling.

G

On yeah, but we don't have a VMware to model right like what that's. What you're saying.

C

Okay, maybe so so you as you at that point now you have this. Now you ready to push you have all the code written for the site, maybe for event for vendors for the occasion to deal with all this complexity. Now, even if we know the model is not great and we need to do more work on the model. Yes, okay,.

F

I mean as far as I can tell if this intermediate layer software, if you turn on all the capabilities to do use bitmaps for tags, make sure that you do the cross producting of bitmaps with multiple bits sets, so that there's the most one bit set. If that's an option that you can turn on and do 2G spit wide or something like that for a like, the existing behavioral reference model I think implements that correctly.

F

It'll just do turn it's a plain, alternate tcam table now that it can do if you turn on all those options in the control plane.

F

I, don't know John if that sounds accurate, but it starts.

I

I think I I do but I also think that the requirements of dash for example, said that you needed to support A Thousand Rules. Well, what is that thousand rule requirement once you now tell the the orc agent that you're, not capable of you, know doing the match. Logic like the the cross product of all of these things is going to be way more than a thousand rules. This is my biggest concern is like that. I, don't want to see the number of rules go from a thousand to fifty thousand.

I

Just because, um like this tag feature is there when, like logically, the tag feature didn't do anything it was you know, logically, it didn't do anything it's supposed to just be a hint to optimize your your data, plane yeah, but but now like. What's the requirement for the number of rules, it shouldn't be more than a thought like you know, if I say that I can support the correct match logic, then I shouldn't be required to support more than a thousand rules.

I

But if I say that I can't support the correct match logic, what I call the correct match logic and and I'm, requiring the orc agent to do cross product expansion? Then, what's the requirement? How many rules do you need to support?

I

It's like like it's it's unknown it like it comes down to like how many cross products there are where, like the way, the simple API and the way that it like in defining the match. Logic allows us to put like a bound on the number of rules. I.

G

Think that calls for the same argument right if, uh if uh the PSI um southbound also Define the same way as not one, then we push uh that to the hardware. It doesn't mean that the hardware will have exactly that. Thousand Rules right you, the implementation, may have to expand it to a ten Thousand Rules right. So yeah.

I

Yes, the implementation may have to do that. Yeah.

G

But I think the same thing with the capability like. If you expect, if you return, zero capability will will expand to that Thousand Rules.

I

C

Doesn't that change the requirement on vendors completely.

C

I mean you're talking about now, you don't support thousand you support, ten thousand or whatever right isn't.

I

That what you said, I think I think if the Northbound says a thousand rules with this abstraction right tags and um you know no cross product expansion. You know like that. That's like the Northbound that, if you as a day, hey I, support, A, Thousand Rules and exactly that form with the with the right match logic, then you shouldn't have to support more than the Thousand right like you could support exactly what the Northbound supports and it will fit.

I

But but if you require your data plan to do cross products, then it's like not clear, like how many Northbound rules like what what do they translate to when into southbound rules. It could be tens of thousands or hundreds of thousands I just want to make sure that there's that, um if you support the rule in the form of the Northbound, then the data plane like can be bounded and how many rules it needs to support.

I

I I think this is a big problem. I think it's it's like uh it's. You know, I I, think it's a big problem, because I think someone's gonna say: okay, I'm not capable of uh multiple matches on tags in a rule and the orc agent is going to start doing the cross products and then there's like there's no bound on the number of rules that could be sent to the data plane.

F

Right where it's such a factor larger than the dash requirement rules, there.

I

Exactly like the requirement for Dash is a thousand right and I think that that thousand is like from the perspective of the Northbound and so I want to make sure that, like if we can handle an API. That's like exactly like the Northbound API to the PSI layer. Then we'd never have to support More Than A Thousand Rules like we've. We've we've done it, but if you can't support that API, then how many rules do you need to support you like I, don't even know that you could Define it.

F

I mean other than the trivial way of whatever the output of the southbound API is given.

B

That top level requirement.

F

Which is much larger right right.

J

I have a question regarding all this listening and will I be able to do at that level and side level uh yet and get back what I have said, because by hearing all these cross products and transforms, and so on, fine on your set you'll do the logic button I, do the get I want to get exactly what I said? Not you know if I set one ACL rule I don't want to get back 10 000 in the get, because that's not what I said so I hope you get to work properly.

J

After all these discussions.

J

G

Get depends on from where you are invoking the cat right, like okay,.

J

Yeah, if I do a dash API, yet I should get what I said via that API and if I don't get at side level. I should get what I said here that API so.

G

Yeah I will that's the the home Sonic design is is according to that right. Whatever gender mindsets is the fdp and whatever works is the Asic TP. So it's it's always separate, so so, depending on the the get, because I will not ex expand the the appdb entries uh based on the the PSI capability or implemented it stays as it is right, so the user will always see only what they have said.

I

Yeah I'll, just I, just want to make one more statement.

I

um You don't need tags in order to like to implement an indirection okay like where you do a prefix lookup first and then you do an ACL lookup like like you, don't need tags to do that and I know that, like you say, oh, the tags is like a hint to the data plane to be able to take advantage of it, but um you know: there's there are algorithmic ways to be able to like take any set of rules with with you know, whatever cross products and be able to to map that into multiple lookups or.

I

However, you want to do it like the tags is actually like. If someone says we require tags in order to save memory in a sense, it's that they're, it's a laziness like they didn't actually need the tags. They could have factored those tags them themselves like it's it's um you know it maybe help save some computation in like factoring the the rules but like the the tags doesn't isn't in of itself. What allows you to save memory?

I

It's the fact that the ACL can be split into like two stages of lookup, one where you look up the prefix and then, where you do. Let's say a ternary kind of match right and- and you don't need to express the rules with tags in order to be able to do that.

F

I mean here's an alternate view. Forget the data plane for a second imagine. It just works somehow, on the user's perspective. Tags are extremely useful for igniting things right.

I

Totally agree with that I totally agree with that and and I and I think that tags are like an abstraction that makes total sense to the user in the Northbound, API right and and I'm perfectly happy with tags being in the PSI apis um like I I have no problem with the tags being in the PSI apis. What I have a problem with is the bitmap being um sort of an inefficient eight API, when, when you try to scale it to a large number of tags, so.

F

I think it was I think it was sorry I, don't know if it's sunny or Prince sorry I, don't know it's Prince, yeah, I'm, sorry, yeah, I, think I, think Princeton. Well, if there's a different cell phone API that we somebody else proposed later that doesn't use a bitmap. Here's a really trivial one pass down exactly what the Nord pound API said. Unless the challenge can you do whatever it wants to expand the text? However, it wants to or not.

C

F

C

I did that's what I have exactly.

I

C

It's based on the P4 table update, but that's exactly what I.

F

Have yeah getting that into a P4 program requires some extra computation that, like with maybe different options than the orc agent, has that you talked about today with the bitmaps, but at least it allows the the southbound below the southbound to decide. However, it wants to expand those out or not.

I

Right and and I I agree with you, Andy I I, think that, like I was under the impression that the tag API was sort of a result of you know P4 Simplicity. But what I heard today is that no the tag API is a result of a vendor that can take advantage of it. The.

F

Bitmap representation of the text yeah.

B

I

Or, or even sending tags to the data plane at all is like you know uh uh that that uh that there's you know, vendors that can take advantage of that and that that that's fine and like I, said I I personally am not opposed to like the apis, including tags I. Just don't like the bitmap, API and I. Don't want to require the rule. Expansion I want to make sure that if you could support the like, you said the North Pond API, like with the all of the abstraction that it has.

I

If you could support that directly in your data plane, then you shouldn't have to do rule um rule expansion so that those are my concerns, the bitmap and the rule expansion other than that I'm perfectly happy with tags.

F

I would say: propose a southbound API that just copies everything down for the Northbound API, and even if your Hardware can't support that you've got some driver level software. That turns it into something your Hardware supports.

G

Yeah I think that's perfectly fine, I mean uh let's, let's have a proposal for that and uh and also Define the behavioral model, and then we can. um You can definitely consider that. Okay.

A

You guys are awesome. Thank you.

F

We're not at each other's throats, no.

A

No you're great conversation, I think I. Think I got more understanding just by sitting here, listening to you guys and splitting it out into the three different categories and um figuring it out. So thank you. um Was there it's 10 9 45 already geez um was there any other item to talk about today, I saw some new stuff coming into the prq.

A

um It's 15 minutes left. Did any of y'all want to talk about these items today or that.

E

Top one updated by calendar to latest so peel Vision has been, you know, improving side Challenger um regularly and they finally want to um update Dash, to let's say a recent snapshot and um I'm okay with it, and it passes all the CI tests. So I see no reason. Why not to merge this in okay.

A

All right and um this one did it have any Chris, and so you just we just need to merge. Okay, I'll, take a look at that today.

B

A

You yep yep and anyone else.

A

We just have fast path. Metering tagging the NAT hld was going to be Alibaba when they're ready, um Vladimir, who said this would take a few weeks to look at and I need to go through and do some cleanup here, um private link, mapping oriented we, oh did he drop Marion, hey Sasha. Do you know anything about this? One, the private link, mapping or Alexander I mean.

A

Okay, all right, so that's all I have guys unless you have anything else.

D

Okay, one thing: yeah one thing that Christine I.

A

H

D

To mention Vijay had raised this uh PF for B3.

H

D

To be good for the community to take a look at the beer, oh.

A

Great all right do we want to talk about it now for a few minutes and ask people to look at it or what do you want to do? Sanjay.

D

uh I think it's about the same as what.

B

Yeah I think you can discuss the requirements and the proposal is pretty much there in the agility. So.

J

B

If people can just uh take a quick look today, and then we have the uh behavior model meeting tomorrow weekend.

A

B

Discuss it tomorrow is that okay.

A

Discuss in the behavioral model, meaning is that, okay with you Prince and everyone else,.

H

We have taken a look at this PR 365 and there is PSI and also the bmv2 changes here, uh we're going to that here. Okay,.

A

Thanks thanks Vijay, that's awesome. um It looks like there's a couple of there's a comment in there for you, so yeah. Let's talk about it tomorrow, then sound good, okay, great! Let's put a note there or bmb2 meeting.

A

If I could type, okay, all right, um so I guess I'll do Andy's. Seven second rule is um anything else to talk about today in particular,.

A

So hard for me to wait seven seconds.

F

To my head after I asked the question.

A

Yeah, okay, then I guess I'll, stop the recording and hope everyone has a good day and thanks for the conversation today, it made it a lot more clear in my head.

A

Thanks for doing all that testing Vincent, that's awesome.

G

Thank you. Thank you all.

A

Right all right, you guys have a good day.

D