DASH Behavioral Model WG, 6 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Behavioral Model WG Oct 6 2022

Description

Behavioral Model Workflow README.md
https://github.com/Azure/DASH/blob/main/dash-pipeline/README-dash-workflows.md

NVidia is working on SAI API SONiC changes in priority over bmv2, then will go back to P4c changes

https://github.com/Azure/DASH/pull/240 - Make SAI attrs mandatory for drop-on-miss tables
Big 'P4 Annotations' discussion - Chris to experiment

https://github.com/Azure/DASH/pull/246 SAI bulk add/remove implementation - the idea is to support the definition; we have entries and objects w/bulk create and bulk remove

A

um Last week we talked about a test plan that Anton had provided and oops go ahead and let people in last week we had talked about a test plan. Anton had provided. We talked about um some bulk side apis to be implemented in BMV, too, and so and also this week was wondering if we wanted to talk more about a visual representation of um the the work we need to do so maybe looks like people are still joining. Sorry guys, maybe I should give this meeting till about 1007 to start.

A

What do you guys think.

A

B

I think that would encourage the wrong Behavior.

A

Okay, all right so I'll go ahead and share my screen.

A

Okay, can you guys see.

A

Yeah yeah, okay, great.

A

So this is what we talked about last week about Anton's test plan that he submitted, and here are the bauxite apis, and so I was wondering, though um this week, if it might be a good idea to maybe instead of the list of work items we have in in our project plan, maybe represent them. Maybe I could do it in a visual representation of the different blocks of the the simulator, the compiler, the the pipeline, and maybe we could look at the work in a different way.

A

um Chris did you have a picture or.

C

Yeah I can I can share okay.

A

Yeah, let me stop sharing.

C

Yeah get the right screen up.

A

C

Give me a second and.

A

I don't know if the list of work items always resonates with people.

C

Give me a moment here sure sure no.

A

Problem, oh Vijay I got your message from earlier.

D

C

They're all trying to get this art picture I know I should have had this ready. No.

A

C

Okay, here we go.

C

So um this picture, let me know if you can see it yet I.

A

Can see yeah I can.

C

See one bit per second Uplink: it takes a while. um So this is from the dash workflow readme under dash pipelines and I. Think what we need to talk about, probably is changes to the p4c compiler and the changes to the behavioral model itself. That required and also we have lib's side, that's underway in order to make the behavioral model complete enough for dash overlay I. Think that's probably one of the topics at hand, which is that correct, Christina.

A

Yeah I think so.

C

I think so I didn't mean to do that is. Does this diagram help put a couple of those things in perspective? We have this whole workflow working, but there's just elements that need you know fleshing out will have to be a new Docker for the compiler to handle stateful constructs. You know a new back end for p4c or a modified one, and and then we need our P4 code. Sorry, the P4 code here that you know is a work in progress.

C

We need to enable those stateful behaviors, which are common, commented out right now, and you know we need to continue to grow. The sci Library, um which I know Marion, just put in a a draft pull request for the bulk apis, which is great and Mark reviewed that and we're just waiting for test cases so that we try to follow our best practices of having test cases go along with code.

C

um So hopefully that answers your your request for a diagram, and we could simplify this for just this discussion.

A

Yeah and I wonder if it would be useful to have um like a explode. You know how like in a parts, diagram they'll zero in on us part like p4c and then they'll explode it out and we could maybe have a view of what's needed in p4c or I. Don't know what does everyone think.

C

Like how do the work items in our flat list project lists relate to these things a little more pictorially, perhaps yeah, or even just a list of kind of steps that are have to be done in sequence, so that we're done right. Yeah.

A

Yeah, how does that resonate with the rest of the team, guys.

B

I I guess I'm just curious. um If you want such exploded diagrams do we know? Has anyone volunteered to take on those work items they might be the best person to to people to to create such diagrams of what they're doing.

A

Well, I don't mind creating diagrams if I know what goes where I'm so high level. I, don't exactly know what goes where all the time you know, but I'm always happy to draw Chris likes to draw I.

B

Mean I mean I could give you a very high level block diagram of I, think pieces I think need modification, but I'm, probably not the person. That's going to be making the changes. So I was just.

A

B

If there were volunteers for people actually working on the changes.

A

Yeah I had a comment for Chris, so Chris I think that Arrow from C to the purple box uh was there earlier and momentarily. We had shifted it to the left side. I think it might be a good time to shift it back to straight.

C

You're saying this line here.

A

uh No, the dotted Arrow dotted line Arrow from.

C

Oh, oh right there was uh yeah, you and I had a discussion about that and I can't remember what what happened. I was going to do some modification.

A

Right, I think at that time it was very very long time ago, uh when we didn't have the side Thrift at that time. Right so now that we have side Thrift, the arrow needs to be straightened instead of pointing directly to website.

C

This should talk to this. Yes, well, we still have some compile C, plus plus programs, actually in the repo that do this exactly they it's not the best diagram. It's kind of I took some shortcuts that we're using this is our python Thrift client Library. This is this: is our workflow right now for PTF tests, so it does go through this way, but we have some trivial tests that we haven't even actually spent much time working on, there's only maybe one that just proved the library linked and ran.

C

So we do have a C plus plus program that runs inside this container, that just talks directly.

A

C

It probably can be represented a little better sure. This is almost like by the wayside now, because we've gone beyond it.

C

Okay, that's a good point: if a diagram wages questions it needs Improvement, regardless of my opinion on it. um So thank you for feedback.

B

I guess so just sorry to harp on this, but is anybody stepping up to change, p4c or bmp2 to the enhancements, or is that just like everybody steps back in the one person you didn't is doing it.

A

You mean the drawing or the work items.

B

The work items the coding.

A

Oh yeah, the coding we we have a list of items in the GitHub project. Okay, I, don't know if we have everything I, guess that's what I'm trying to get to is. You know um once we have. You know the the overall, the the P4, the the you know, the different pieces that we could list and make sure we have everything uh underneath those.

E

No, we we do have everything we.

A

Do okay, yeah, okay,.

C

We have everything in the project list all the open items, yeah Martin at.

E

Least, what's related to the changes in BMV, 2 and p4c.

C

Do we have like a status of where it lies and when we might see light of day, what can you give us an idea of where things lie.

E

um Not really because I'm bouncing between different areas and uh right now, I saw a lot of things with the PSI API still so I put that on hold, so yeah uh cannot provide the exact date because prior uh PSI apis take priority for now, because we need to move on with the um with the Sonic changes that depend on on size, so that there is, uh there are guys from Microsoft that are working on Sonic and um we needed to provide everything for them now. I'm doing the further improvements.

E

After that I'll start, going back to uh I'll go back to the uh p4c changes which, by the way, I didn't want to touch till uh uh till we figured out what we are doing with the Dockers, but I think we um we finalize that or not Chris. Did we merge the pull request that moves Dockers to.

C

Hcr yeah no um yesterday I I touched on it. I said uh you know. I know people haven't had a chance to dive in deep, but regardless I'd like to merge it by the end of the week yeah. So.

E

Probably I'll try that and then, when we have the stable environment, I will also resume uh the work on before c. First, okay,.

C

And Marion, just just so, you know the the workflow that I describe allows you to work on the side without worrying about ACR. You can just use your own repo or even I'll make you know you can use mine to do like development Dockers and then we can. We can move it over to ACR easily. So there's no dependency. You can really just keep working the way you are and we can forklift it later.

C

um But you know, maybe maybe you want to take a look at my PR and then you know we can have a one-on-one if you want to just iron it out, because there's a lot of ways to get there without hassle or bureaucracy.

E

I'm, probably yeah.

A

Okay, great so um Marion did you want to present your PR, or did you have something you wanted to present this time? Now that we've looked at no we've done what I want to do? We chose look at the diagram, so did anyone else want to present something or referring into two.

C

Yeah I'll stop sharing unless anyone still wants to look at this, it's online well.

E

Yeah, okay, I have a couple: okay, just.

C

I'll paste the link here in case anyone wants to stero schematic, drawn by a hardware engineer.

F

E

Okay, one second now I need to reload my location, able to share.

F

All right, foreign.

E

Yeah, so this one is about PSI API generation, it's Backward Compatible, um but it's got improvements.

E

um First of all, it's a better documentation. Second, it allows for utilizing um PSI metadata, tooling and in the code implementation. So what it does is that one.

E

Let me see, probably the best way to describe this would be to go to the side template everything else is just a technical stuff that is result of this template.

E

um So we have some objects and entries that have attributes of other objects. So, for example, we have eni and it's got an attribute of v-net ID and we have also.

E

Actually, let's take what you know. We also have eni that has attributes of the ACL uh group IDs and the difference between those two is that v-net ID is mandatory. You cannot create, we cannot create eni. That does not belong to any unit.

E

You can change the v-net later, if needed, that's a possible scenario, but you cannot create eni that is outside of the v-net um and um ACL, as opposed to that ACL is optional and how it is defined in that P4 model.

E

If you go here, I think we have that already.

E

Where is the unit table? Let me find the unit table.

A

E

uh No I guess we don't have it yet. Maybe e and I.

E

Okay, so um if we have in the P4 model the table by the way, all of all of these kinds of tables will need to be uh fixed up. To look like that. If we have that by default, it should drop a packet meaning.

E

um If we cannot classify this packet to anything, we need to drop it either, be it for eni or v-net, which I showed that needs to be fixed.

E

um If we have this kind of condition, it means that we that the pipeline does not allow um the mess on that table, meaning that uh the one that references this be it Enid or the one that will reference in the action that will set that v-net, ID or Enid uh they must be.

E

These attributes must be mandatory. So this is what this change is about.

E

So in the template for filling the attributes um we have, let me see where is it so we have these parameters.

E

Now there is a heuristics in the generator that looks in the table into the table that we are pointing to and looks if that table is drop on mess if it is drop on mess.

E

We will uh set this piece of um metadata that is passed to the template and if the parameter is pointing to an object, ID that is mandatory, we will set Flags mandatory on create uh and we also allow create and set, but the difference is that um we make it mandatory so that it cannot be set to null so that um you see right. So we do not allow setting this attribute to null. So this is the change and what it results in in the PSI API.

E

Is that um attributes like v-net id eni id uh uh whatever object, ID that we have there? They will be now they will become mandatory. So this is uh the change and also similar thing for um foreign.

E

Let's see hold on so this was the uh parameter. Let me expand that because I'm a little bit lost where we are so we are iterating over the parameters, so this is valid for every parameter and um I think this is. The difference is that this is for.

E

Wait, oh sorry, this! This is just the action selector oh yeah. This is uh this is just the action selector um and the attribute, and also we need to fix the um fix the parameter itself. So we are removing uh this allow null as well, and we make a condition basically the same thing as it was before uh we either. So this is more related to sign metadata. If it's mandatory that it, then the text would be conditioned else.

E

It should be valid only in case if the action selector is right, so this stuff was there before now, it's just to conform uh to met to sign metadata, but the main thing main change is here and I will also raise uh as a reference to this pull request a size change. So it will be more clear um to look at the example what exactly changed, but right now I'm a little bit blocked by the site itself, so we need also changes to same metadata, Checker that doesn't allow that for non-object IDs.

E

So as soon as this one will be merged, it was approved already as soon as it will be merged. uh This pull request and corresponding side apis, uh say: API changes will be unblocked as well.

E

A

E

A

Is this the pr you talked about in the cycle, yeah yeah, okay,.

G

Just a quick question on your chain: you know um thanks a lot for doing that, so this for the mandatory uh parameter. Are you only taking care of just the just the create side of it or if, if the mentality parameters are required in uh other than you know, because if we, if we support this cred API right, so why limit only to create.

E

I'm not limiting them to create, they are create and set.

G

G

But but uh how about you know if there are any parameters required in the um whether David or uh you know, update or delete um I I didn't see the param any flag or metadata specifying that thing as well.

E

So, okay, let me maybe open some example.

E

So here is one of the attributes for which this metadata will change. So what I'm proposing to do is to create uh to to change the flags from create and set to mandatory oncreate create and set. So the operations that you will be able to do is to pass this attribute when you call create API and also you will be able to do. Psi API eni attribute, set and change vnet ID.

E

And so you will be able to create an eni with the v-net. You will be able to change unit ID. You won't be able to delete v-net ID attribute, meaning that you won't be able to set it to null, because those two flags will be removed.

H

um Quickly pick here, um DSL group below that is the same, which is surprising.

E

Acl group will be different, so ACL group is not mandatory because this table does not. uh uh It is not a drop on Miss.

H

I understand what you're saying, but the attributes that you describe are exactly the same, so it kind of looks to me like makes it mandatory. I've thought I understand what you're trying to do.

E

H

E

One, this won't be mandatory only event. Id will be mandatory.

H

Well, when I look at okay, maybe I missed something you you look you're showing the new generator API.

E

Right! No! No that uh sorry, I don't have the new one.

H

E

It will not pass the checks yet because it's blocked by metadata Checker right now so.

H

Okay, okay, waiting.

E

H

All right so I understand: okay,.

E

H

F

Showing you and.

E

And uh yeah just one thing uh in uh as compared to the old API. So this is a good example. What will change this ACL group ID won't change, so we can create eni without attaching any ACLS to it, which is perfectly fine, but we cannot create via eni without v-net.

E

So we will require to set this attribute, making this Flex mandatory on Create and create and set, and we won't allow this so allow null will be not set to true and there will be no default because it's mandatory and create in.

A

That point will become mandatory right, yeah, okay and they'll be interdependency both have to be created.

E

Yeah yeah: that's the intention.

C

Good morning, does this uh Auto generate um constraint, Checkers in libsi to validate.

E

Because this is, this is part of Psy uh metadata Library, which is generated by Psy, um tooling itself.

G

The way I see this thing Marianne is that you know you you correct me if I'm wrong, you know your objective here is to ensure that we are we are. We are Auto, generating some validation code right, API such that when you are, you know with your right, so so from your Tool uh from your auto generation to all going through this P4 code and then determining which parameters are essentially going to be mandatory and then also what is what should be there?

G

You know um allowed value so to speak right like saying whether or not you're allowing null or not, and whether or not you know these are the mandatory options so forth. So so this is yeah. So then, then, so in in that case, what happens is um we we have this one is like an intermediate um representation, not the individual representation, but at least the dot Edge file.

G

With all these flags that you know setting this thing and then the next set of changes that are interpreted by the code is when they generate actual implementation code. Right. We'll say that how I'm going to generate the implementation code of the validation so I can just take it from all the information on this. uh uh These header files, in the comment section as a.

E

Metadata yeah one thing is that it's not even for the library implementation, it's one layer above uh if it's used actually uh so lip side redis. If we're speaking about Sonic, ellipsi, redis utilizes, all this metadata to do uh sanity checks, even before call gets to SCI Library itself. So that's what it's intended to. So, if you look at a Sonic and from end to end point of view um between the occasion and the PSI Library, there is an RPC which also has a responsibility of verifying this metadata.

E

So it will not allow you to do a PSI API call to create eni, for example, without this attribute best.

C

Too sorry shouldn't the library do that too, to protect itself.

E

uh Libraries do that optionally, uh uh but the thing is that um this is the let's say the the unified way to do that and to handle the errors, and you don't really depend on the vendor library to have a unified sanity checking.

C

Got it let's get another discussion someday Maybe, so.

G

We have some questions. Speaking of this, you know what what is part of the Sonic versus what do you? Basically, you know in the PSI and so forth. Right I mean I I just want to refer to one like one point: I, don't know whether this came out as a discussion on this one, but in the previous uh PT last week's meeting there was a discussion that you know: Sonic, caches or or basically has some Shadow uh state right, and then there was a question about okay.

G

You know for the get part right um that we weren't going to either either fully implement or fully generate. Since you know, Sonic does this thing right so shouldn't a PSI implementation, be NOS agnostic? Why? Why should we basically Depend and say that okay, only Sonic will be running on PSI and no other NOS will be running on this side.

E

No I mean you, you can do that uh I think every Psy vendor provides that for at least the switch side which is outside of which is used outside of Sonic.

E

um But there is a question of priorities and I I. Don't really I'm not really saying that it's invalid to do that, I'm! Just saying that I don't wish to do that right now,.

C

I have a question about um when you generate this mandatory object in your in your Ginger template. uh Sorry in your site, API gen underscore pi, you you look at the table. Name you like an eye on this um and you assign mandatory's true. So your your code, generator is, is the one that has the business intelligence to make these relations right.

E

uh Well, it it figures it out from P4 code. So if the table and P4 has drop on mess policy- and it will treat this table as mandatory.

C

Is there another way to do it where we use an attribute in the P4 code like an annotation, so that, because to me, this is sort of like a hidden side effect and it couldn't. We put it explicit in the P4 code, where we have an annotation yeah.

C

E

It's natural: it's not like a workaround.

C

I didn't call it a workaround I'm, just saying the level at which it exists is kind of if you're reading P4 code. You won't see this relation right, it's inferred and you have to understand the code generator to know how this propagates, where, if you put in the P4 code, you know annotation mandatory or something like that, which you can put on virtually any entity. You can do an annotation, you can generate it from that and that's the single source of Truth versus a code generator which has a little bit of black magic in it.

C

F

An idea I have a similar question as well, uh so before that I had a basic question. So when you say uh depends on the drop on this, uh so, for example, in this in this example here right. So this eni table is draw upon this. But uh are you saying that you'll depend on the v-net tables drop on this to determine whether v-net IDs, mandatory.

E

Yeah yeah you'll need to look uh at the table that matches on that.

F

So my question is the eni table: has both types of factory groups like it has unit ID, which has to be mandatory? It has Apple group ID, which is not mandatory, so it is not dependent on that table itself. It's dependent on the table to which this attribute is pointing to right.

F

So now, uh I think similar to what Chris is asking. My question is also that. Is it true that in every case, where it's pointing to a drop on this table, it will always be mandatory, because there could be multiple tables where we could be deriving the v-net ID from and some tables it could be optional. Sometimes it could be mandatory, isn't it better to have seen the app name attribute or something like for the people that we have some tag there to indicate that this isn't mandatory.

A

I think that article is not drop on this. Is there.

F

A

F

Specific example, it works out what I'm saying is that true for every case that in every case, it will be always true that any time a table is pointing and table attribute is pointing to a drop on Miss. It.

E

Is always mandated.

F

Can we just make that assumption.

A

You're saying that if there is a drop on mess um result um on any table, those tables should become mandatory. Those objects should be mandatory.

H

That's something you keep want to do that, because looking in that table may be optional, you're, just defining the default. If you're looking into that table- and you don't find entries, that's what you define the Denard the drop, but that still requires to do the lookup itself and there's nothing in the code or in the P4 structure. That says this is a mandatory table right.

F

Yeah yeah so to derive this okay.

E

So so you have a field, you have a metadata field. Why would you set a metadata field that you will not later match on I? Think it's even providing you with um like a way to catch bugs and either the implementation or in configuration you.

H

Take an example: you get a you get a result here, you get a result. There is a you, get a field that could be used for an end cap, but you could also use it for a lookup like alcohol or whatever. It doesn't mean that these that the lookup you potentially do is mandatory. So there's nothing that says the lookup is mandatory.

H

So if you do the Rook up, yes, but there's nothing, that tells I mean if it's based on a flag on the packet that you do, the lookup there again I see what you want to do and I think having a an increased mention that having a dedicated parameter to say on the table. This is the monetary uh field. Actually, that's a military metadata, it's a whole lot better! It's explicit, and you don't have this uh behavior that sometimes you know, may not be applicable.

D

Yeah I guess one uh one. Another example would be like if the v-net ID was being derived in the pipeline in two different tables, for example, let's say: there's eni Foo and which is also giving me net ID and further down the pipeline. You have some kind of P4 logic to decide which wins and then that's the one which finally goes to uh venet ID lookup Vina table lookup uh yeah. Maybe one of the tables can just omit that attribute right. So there could be some pipeline logic.

D

uh Are we trying to like out guess the semantics of the pipeline by uh doing this in the generator.

E

Yeah I think I'm trying to do that for the reasons that I don't want to go manually and Mark these parameters as much as mandatory. That's my intention.

C

Seems to me, like that's, um hiding expertise in the code, generator and knowledge. That probably ought to just be explicit I mean. Is it that hard to mark up the P4 code? What's the what's the motive.

E

To not do it manually and not miss it.

H

But whoever creates the table has kind of the responsibility to say this is kind of mandatory chain out of the mandatory chain right.

G

Yeah but I think one of the things guys. You know if we say that the only source of Truth is before then. Why overload anywhere else like you know whether generation code of try to do this thing? I mean I, agree that you know we should have a single source of Truth from where we generate these apis, and if that means that we have to have certain annotations in the before code to help us generate this thing, then we ought to discuss that.

E

Is the source of Truth? The question is: is it a law that you need to have it mandatory or not? This is what we're trying to find out.

H

I think it does have the documentation of somebody trying to understand what are my basic required Fields. Even when you do data plane and when you do config like ellipse eye, if I know that some some fields are will always be there on the create I can do some, my backend, maybe optimize one way or another. So it's an indication that might be used. It's.

C

Yeah there's another motivation in that is people may use this tool chain, but make their own libsci code generator, and the P4 info is the starting point for all this metadata people can write tools to create libraries, just like you did here.

C

If the information is in the P4 info that comes out before code, people can do what they want with it. They don't have to pre-create varied business logic somewhere.

C

um You know the P4 annotations are very flexible and people don't even use half the power of them.

C

um Besides, just scalar annotations, like with the parentheses, there's structured annotations with square brackets, where you can put key value, Pairs and all kinds of different constructs inside an annotation, that's very rich data, so you know we don't have to go that way, but even just having an annotation mandatory.

E

Oh by the way, um not sure if, uh yes, since you're talking about annotation I'm, not sure if um before supports annotations for parameters, I'm, not sure about it, we.

F

We do have an acne that I'm interested to attributes where we actually specify the PSI API name. So I was wondering we could put something in there to annotate that this is mandatory. Yeah.

E

No, but we don't have annotations on the parameters.

C

uh Don't be so sure.

F

We do have on the table, attributes right people table attributes. We specify the name of each attribute.

E

C

Which key right key and action parameters, an action.

E

Parameters: okay, I'll need to look for the example.

C

Yeah I've done extensive work with that stuff, where I auto-generated web uis, based on annotations on P4 code. So there's a lot of tricks. You can play that most people don't go into also I. Think. If you look at Sonic pins, they might be using annotations to sort of relate P4 code to Sonic or PSI code. We.

A

A

The question is, uh we can specify what is mandatory using annotations.

A

um The pipeline is the way it is, and it is very clear that.

A

um Add-On misses in certain place where the stateless lookups are before that right and they absolutely become mandatory regardless right, I mean always for for a decision to add unnecess later right, yeah. If it's needed, we can use it.

A

That's the decision you need to make.

A

So does someone need to go? Do research about the annotations or.

F

C

A

I'm sorry go ahead.

E

First, maybe just leave a comment under yeah.

C

E

The full request: I- don't really have a strong opinion, but for me it would be easier to just do it once and follow this rule. uh If you think it's too strict, okay! Well, let's do it manually.

C

Not that it's strict, it's just.

E

Where APK will be the same anyway, yeah.

C

I'll volunteer to do a little experiment, um Marianne and annotate some parameters and and make a branch, and you can look at the output of the P4 info.

E

Yeah, that's fine.

A

A

Any other PRS you wanted to display Marian.

E

um So there is the bulk API. Oh sorry, I'm in the wrong sorry, so it's straightforward um I just need to complete it, but uh the idea is to support the definition. Okay, let's go to definition.

E

So, for instance, we have entries, we have objects, each of them has bulk, create and bulk remove, um so objects. Follow the signature of a generic cyborg object to create function. I'll show you example of that and um entries are have a unique signature due to the structure definition. So we want to provide implementation for those in scileip for bmv2, so it results in four new implementations that simply rely on the non-bulk functions, so we have PSI create for objects.

E

So this is the signature. We have switch ID a number of objects. We want to create uh number of attributes, two dimensional list of those attributes, uh bulk operation, error mode. I will talk about that object, a list of object, IDs and list of status.

E

um So in in this function we simply go over all of the object, count and call a singular PSI create API for the same object, type.

E

um And there are two modes of operation: there is um tap on error or, alternatively, to proceed till the end. So there is an aggregate status which is this one and the function signature which will signal status success if all of the calls succeeded or status failure, if only one succeeded. Sorry if at least one failed and um in case of uh stop on error, we will stop calling Psy uh for the next object as soon as we get the first failure.

E

um So this is um based on the previous support and this will be used in the tests.

G

Where is the rollback part in the case.

E

There is no roll back. Rollback is not part of Psy implementation. You just return the list of statuses, its responsibility of um the.

G

E

Yeah of the caller to go over the statuses and figure out what they want to do with that.

G

Okay, so basically you you spend a a real statuses and then, but you feel sorry, you stop. On the first period.

E

um If this is the mode, so there is a mode that tells you to okay, you can proceed even even if one object failed, or um there is a mode that tells you to stop. If the mode chosen by the caller is to stop, will stop we'll just return.

G

So in that case, when you stop uh on first failure, what is the status of the remaining first? Not.

E

G

E

Undefined we didn't even try, so they shouldn't even look at it same as we didn't fill anything in the object. Id list, the values that were passed to us beyond that object, ID that failed will not be filled to anything.

G

And so it's it's a college responsibility to initialize it to undefined.

E

And then it goes.

G

Back yeah, okay,.

E

Okay, all of the information uh needed for the caller will be there. If uh he chose stop an error, he will have to only process those up until the error in the object, statuses list.

E

Not sure which one Sonic is using, but we use support both.

C

Well, um one thing that didn't occur to me: did you consciously avoid using let's say the equivalent in people runtime of bulk apis, just to keep things simple, I'm calling.

E

Yeah yeah I. Don't think we really want to uh um do something that is uh optimized for performance if we'll need to I'll uh I'll rewrite that. uh But for now it's just relying on what we have probably.

C

Just good for people to know that you know the Assumption here we're just calling the single object. Accessors over people runtime because for being B2 performance is not going to be an issue of the control plane.

C

um But if you were doing this like for production, well, probably wouldn't do this anyway. You'd want to bulk up the the low level API.

C

So if the dpu vendor is looking at this and use it as a model to implement their Implement, their own PSI back, end, they'd probably want to not call single accessors right and bulk them up themselves for their API.

H

Call me if I'm wrong, but this API is still on the pair object type. It's not a real bulk right, like a call, is only addressing like. Maybe you can configure like different Enis at once, but you cannot do one call and configure enr and some other stuff right.

E

Yeah and it's not expected by the site, API.

H

E

H

Actually, bulk yeah.

E

H

E

Right so this one will be added only to the API struct of the corresponding object type and that's how it's supposed to be used.

G

So but then why? What is the meaning of object count if it is only on single objects.

E

Now single object, type.

C

G

C

Could add 10 000 Apple rules in one call right.

C

Saves a lot of round trip time.

H

So so uh and that's fine so in the future there will be no ever any kind of requirements to support across types yeah.

E

I think that, like, if you look at the notes as a whole, be it Sonic or any uh other one uh trying to even combine all of those will require to uh maybe do some abstraction in the nose layer as well and take care of the dependencies, because um there will be some. If you want to bulk anything, you can't really bulk anything. You'll need to order them having it uh on one object, type makes things easier.

H

Okay, yeah fair enough thanks.

A

So we are running at five minutes till the end of the call. Anyone else have something they wanted to bring up this week.

H

I have a tidbit on.

A

H

um Looking at this eye apis, um the IP addresses they don't look like prefixes, but they should be right.

E

Could be a bug.

H

G

H

Let me just open an issue, so it's tracked and you can just say it's a bug or not, but I would have expected like a prefix in a in an SEO right.

A

Okay, yeah yeah. Thank you.

C

The prefix is in the P4 code, but not in the side generated header. Is that what you're saying.

H

uh I haven't reached the P4. Let me let me do all that check and uh I'll open an issue if I find something, definitely the other side level on the attribute itself. It's an address, not a prefix but I'll triple. Take all that. Okay,.

A

A

Anyone else have a burning issue before we end.

A

No okay, I'm gonna, stop the recording and.