DASH Community Weekly, 1 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SONiC DASH Workgroup Community Meeting Feb 1 2023

Description

Hanif: PINS project (SAI.p4) to leverage to reduce amount of work - is there code we can borrow? This has routing and ACL mirroring. Can discuss offline or in bmv2 call.
A: Can be done as part of PR236

SONiC Q: sync_d integration status? May 2023 delivery of SONiC stack? Sync_d does not know about SAI attributes (yet). May 2023 item might not include everything to build a workable DPU image.
Guohan: WIP to use bmv2 to call DASH APIs (in approximately 2 months).

Timeline for Community image for SONiC-DASH?
TBD

A

Wednesday Dash Community call for February 1st. It looks like this call is our 53rd meeting together. So that's awesome.

B

A

Time I sent out the notes last week. Last time we talked about these PRS here.

A

um A couple of them were merged and I had to fix a spell check on mine, which I finally figured out how to do with the help of mercha, and so thank you mercha, and we also went over again the the um metering, Pipeline and more information where we were making edits last week, and we thought maybe we would talk about moving into what we talked about changing bucket to metering class ID, and maybe this time we would talk about libside aside orc agent, blah blah blah. But that's not going to happen this week.

A

So I thought maybe this week we could go into remind me later so just for to let John know this is the dash GitHub repo here and so normally we come take a look at the different PRS that are in the queue and see if there's anything we'd like to cover today or discussion in Q a so so today, um so guys on the call. Is there a PR or things we'd like to cover today.

A

C

I I guess I have a a catch-up question from sure neglective attention on my part for months uh in this group. Sorry for catching up, but so, for example, this discussion. Recent discussion on metering. This is at the it seems to be at the stage of documented and describing the desired Behavior. But, for example, the existing P4 reference code is yet to catch up with some of those discussions. I imagine yeah.

A

The P4 step that we have you know is here, I mean this is what we have so far, and um so.

C

It must be on the order of if there's been any changes in the last six months or so they're. Clearly not there right.

A

Right and princess: that's the case, isn't it Prince we'll catch up the P4 as soon as we nail down the metering.

D

A

D

Think, that's that's what it is. Yeah I think. First, we we still have not nailed down, as we were mentioning still under discussion. So there are a lot of feedback coming in and then once we have really firm up the you know the design- and you know all the the feedback has been incorporated. Then can we only go ahead and start to incorporate it with the P4.

A

C

Do we believe most of the results of the discussion have been checked into other documents elsewhere.

A

There's a yeah there's a document here General and it's the Sonic, hld and markdown and so metering requirements here, and so you know we kind of start here, and this is where we start. We actually started in a different document and morphed over to this. If this is helpful at all, so we start here in the Sonic, hld and then down below is where the um this kind of stuff is where we put it inside of the the content here.

A

C

Yeah I, so I just wanted I just wanted to get the general impression that there's the discussion that turns in the documentation. That's the documentation is intended to be the most up-to-date thing in this repo now yeah other code, parts of things are lagging behind. As the discussions settle, then we'll move this okay make sense. Yeah.

A

That's what we try to do so that we can keep it up. Yep.

C

A

Yep so okay and uh James Lowe I saw an email from you uh did you want to have something you wanted to talk about today.

E

Oh, yes, that was longer than that. Maybe I look at the P4 language. That's uh you know the the behavior model that people call and maybe with the merge all of those into our existing, the you know the the BMV to the this directory.

A

E

A

Me to present your email, or do you want to present your.

E

A

Sure no problem which one do you want, do you want to.

E

A

Okay, all right I'll, try and grab it and give me one sec here, guys.

A

From James.

A

Was it this one James? Yes,.

E

Yeah I I was looking at the the pr the issues to 36 and 292.

A

E

Simply related to the underlay, the support for the dash bmv2, so I go to the call and find out, maybe in the in the P4 model. You know the people called the people link with their quite a few. You know the the data print status. Maybe we could merge all those into our right now. The bmw2 card I, don't know right.

C

As in is your question emerging all yeah under underlay feed data, plane features yeah.

E

That's my question: not all of them. Maybe we should just see another cherry, picker, I I'm, not sure you normally, but pretty much. We need and I'm sure we need some of that right. I.

A

Mean we have 10 P4 files. These are ours that we.

E

Have that's always right.

C

So I would defer to looks like Marian and others, but I thought there.

A

Was a discussion.

C

I thought there was recent discussion that maybe they wanted to keep the P4 code, AS Dash specific as possible and for underlay do minimal things like maybe just unicasts forwarding out of a determined port or something like that. Simple.

E

Well, I was thinking that since it's it's been there and then in the future, we are talking about this Appliance or maybe we we may need more I, don't know I'm, not sure yeah I know Mary and he wants to keep it as simple as possible. You know.

D

E

Think we can, we can look.

D

At it, we can look at it in a different way: I yeah. That would be just my one of my suggestions is basically um you know. We have identified the the PSI apis that are applicable towards you know achieving certain aspect you know of this underlay there are um that are related to the dpu.

D

um So if we want that kind of a approach then- and we can see that okay based on those apis- what is some of the things that we really need out of bmv2? But if, if there is already available in the BMV too I, don't know what we are bringing in from the P4 language.

D

The one thing that I can basically see today is that if we want to really go ahead and create a certain uh P4 model to to mimic that functionality that is required to support those PSI apis, then we can go ahead and do that because today, as we know right uh to in order to test our this, this this test harness, we are really, you know, generating those uh implementation of the PSI API, especially on the overlay side um and then calling through the people runtime. So we can, we can take this same approach.

D

uh We can get it up before runtime uh implementation of those underlay apis and then see which which support we need and then come up with this P4 model. For that um that would be my suggestion for them.

C

In in the in in your question uh out uh sorry, if it's Alan I think you mentioned a particular version of P4 source code for switch.p4, that's been published, I will warn against using that unless somebody says they have implemented PSI on top of it and is willing to publish that, because that published code that you link to is 2016 era and nobody's touched it in six seven years.

F

Right so James size I'm, so sorry that I didn't look at your email earlier uh in the morning. um So um as everyone here is saying right that um there are certain features that we have already identified in dash. But I think your point is very good that we should go through some of this song A little bit more see if something else is applicable. Is that the question.

E

F

Okay, okay uh yeah: some of these conversations have uh also happened earlier, but I can um go through in detail one more time uh with you um see if there's anything else that is applicable, uh for example, uh lag acmp uh basic tackle, for example, yeah mirroring um so yeah I think we can also go through this in some more detail and discuss it in the next meeting or after Prince. Maybe we can send you some um summary. We can send it to everyone here too. What we.

G

Yeah Chris hi Alan, it's good that you sort of I mean sorry I, know James I'm glad you came in and just sort of took an independent look at this. You know it's sort of a reality check right, I. Think, though, Andy's point is probably a really good one two points he made one. The code base itself was kind of I'll call it uh unmaintained for a while. The other is the control plane.

G

Work to tie it in is, is non-trivial, and so there's this big body of work to bring to make a a full Dash underlay for a Model A lot of work, and meanwhile, there's still outstanding work on the items we agree should be in the dash behavior model, like the things we're talking about still like uh metering billing accounting.

G

That kind of thing and other features that are Dash specific, that's still a non-trivial body of work to be done, and so at some point we have to make you know decisions who, what are the resources that can work on all these tasks and which ones are the ones that are really urgent and and decide because at some point a dash dpu will sort of be buried inside of a Smart Switch, and a lot of these features are going to be handled by the fabricates that cannot the dpu.

G

The DP will just be a bump in The Wire, you know sort of a um hairpin mode, middleware box inside the Smart Switch, and all these routing and switching features will become kind of irrelevant in that case. So how much does the community want to invest in a standalone dpu that looks like a full Sonic box versus focusing on things we have to do so. I just want to throw that out as a balancing opinion right um in an Ideal World.

G

We do all these things, but you probably have to pick and choose where we, where we focus our attention on I. Don't know if anyone else wants to comment on that.

F

Right, I completely agree with Chris.

F

Yeah um we can have a small conversation offline James, but we can also bring this up in BMV too meeting if needed, for further discussion.

A

Those are these accurate enough um notes for this um email thread, just things to think about.

G

I guess the other. The other small comment would be. uh You know, prioritizing the work towards things that need to be done for for Dash versus. Would nice would be nice to be done for a Dash? You know what I mean.

H

Yeah, probably I wanted, like a public cross check, that my understanding on the dash API says because on the Alibaba side we are kind of also debating to see how we were leveraging this effort. So right now we understanding is the behavior model is mainly for the control plan to generate those Dash API to generate things. So we it's not it's more like a defined The Logical behavior for the data plumper that we don't expect in this is the P4 will be used as a daily plan.

H

For saying that means that you say, for example like um we were just to say, hey, this is kind of like say Behavior, so which we want to like the GPU to be achieved, and these like apis, uh the control plan will come in, but from the real implementation point of view, or like say, this is more like I, say the checkpointing.

H

So, but when once we go real deployment, uh we could add something extra on top of it or like say, we may not necessary to using the dash API to coordinate it's available like right now. Those Dash API will be stored as a radius. In the behavior we internal, we have the concern on that. So we're kind of thinking so I would just want to see that would that be kind of the the way most consider the Dash as a reference or.

D

I think in my my understanding is this is your reference. It's a reference implementation and then this is there to test to ensure that okay, at least your you know, PSI API behavior is can be tested, and then this is the extent of that one. It is, but if you can take this one as a reference to implement your Hardware, um you know to mimic something like this. Then then, of course you know uh it it should. It should be the starting point right, but.

C

A reference for not just the control, plane, API, but also the packet processing, Behavior I thought was the intent well.

D

I guess when we say control plane, you know generally people basically think this one is that can I really take this one and uh you know generate uh so P for runtime, and then you use this one in my control plane, the the all along, if you, if you're just talking about from the Sonic Dash perspective, Sonic Dash, is, is not actually trying it like this right. Sonic Dash has a has a separate schema for the control plane. That has basically been at least as a reference has been. You know published by Microsoft.

D

So you would you? Would you basically be using that you know to talk to your Sonic Dash dpu, which eventually gets translated into you? Know some radius uh schema and then it just drives this High API to program your uh dpu. So so clearly, that's that's the the entire workflow um so, but for your reference implementation.

D

If you want to really take this one as your behavior model and then generate the the P4 runtime and then use this one in your control plane for testing it out, yes, I mean that that can that can be achieved right for from the reference perspective, but definitely not as I understood from alibaba's question. Is that from Eddie's question? Sorry, is that um this is, you know they're specifically asking for the for the Sonic implementation.

H

Yeah, basically, we are trying to see uh we don't want to, like I say uh like going too far away from the community like agree approach, but if we see some kind of a inefficiency we want to like, if they also try to avoiding it. So that's why we are looking under it. That's why we're kind of debating on that say today we kind of like say all data plan.

H

We also take a pretty much take care of for the fully programmability point of view, so this one for the I agree like the for the reference model. It's awesome, so it's kind of like say I can give you like. I said this is the hour like the business approach. So then we can do it, but we don't expect things the the people will be real or like if they depend handling piece. It's more like I, say, I, logical description, piece.

C

That there's no requirement on any vendor that they use this P4 code in their product at all. Local.

F

Yeah the vendor can Implement can.

C

Implement that can Implement their product any way they want. The P4 code is intended to be. It should work like this I.

F

Think the question: how are you doing is something like if we are utilizing this BMV to P4 to generate the dash apis, then? Is it a complete standard or it's a reference, because if we look at B and B2 as reference before, then we derive the dash apis from that BMV to P4, then, will it be complete or not? Is probably the question.

G

Yeah, is it a correct, subset.

F

Yeah right, that's right, so uh Prince, if you can please uh uh you know, add more to this. The dash apis um are not just uh you know, um as is derived from the current BMB to P4, but we have also updated it on top with other uh details that is needed like, for example, like, for example, metering, Etc.

D

Yeah I think we we.

F

D

To really go back to our first principle that we basically said hey, you know we are going to have these P4 uh model that we are creating the the behavior model for for Dash as a single source of Truth to generate the dash apis and in the when we say Dash AP, as we essentially are saying: Dash PSI apis right. So so, if we say that this is a single source of Truth and then we also said that even for a chain metering we have to come up with.

D

You know some means of defining it in in P4, so that we know that okay, we are not deviating from it because otherwise you know we are really it it it will. It will not remain kosher, so to speak right, we we will start to introduce something on top of it and we will not know whether it's this really came from you know.

D

um Today we have a different model for the underlay apis in the PSI Community um which, where they I believe what they do, is they create this Vizio model to define a logical Pipeline and that becomes a source of Truth for them to really generate the underlay apis, and then they make sure that they keep it updated. And then this is everybody. You know um agrees to that. Similarly, you know here if, from the from the day one, we agreed that we are going to have a single source of truth.

D

Instead of Visio document to define a logical pipeline, we are going to use P4 to define a logical pipeline for each and everything and if where there are deviations where it's absolutely not possible, we we said we, we will not leave any uh stone unturned to do this thing. So let's make sure that we we do that, and uh so we remain on the right path, as opposed to really introducing something where we can't go back and validate how we really came to it right. Yeah.

G

You can't execute the Visio diagram, you can execute the P4 and that's the big difference and you know I'm still in favor of it until we prove that it can't work. I I just want to mention I pasted a link in the chat it sort of goes back to the minimum underlying features in order to do at least our unit testing.

G

Our cicd testing and um Anton had compiled a list of the apis which would allow us to complete our unit tests and take some of the tests that are currently only running, for example, on a Intel dpu. You know that we're in the PTF test that could, if they, if we completed this list, we'd, be able to run them on the dash behavioral model as well. So, if going back to prioritizing our efforts, we could look at that list of switch P4 as kind of the the perfect complete soft switch model.

G

But in reality what we need is is this to do cicd testing um as a minimum, so we could test the dash overlay features and the necessary underlay setup and have some kind of a harmony with you know. Actual physical device testing so to restate that we have tests in the PTF test cases for dash that can't be run in the behavioral model, but with a little bit of effort could be I shouldn't, say little with a certain amount of defined effort.

G

This effort here, if we did this, we could then run those tests on on the software model, so that I would take that as a reference for, what's what's important, to fulfill this mission of a reference model versus what would be nice to have in a full-blown implementation.

D

G

D

This is, this is a great idea. I think what happens is that if we have a minimal thing support, then clearly from end to end, you know, testing can be met and I would I would recommend that you know there is a um you know, pins project in in Sonic which actually defined a PSI dot B4 for for underlay and and that that we could, basically, you know, leverage that um we may not be able to just get everything right from there from the get-go.

D

But at least you know as a reference and we leverage that and then that can actually reduce the amount of work that we need to do to to bring. In a you know the P4 behavior model for underlay, just minimum set, as you suggested, Chris. uh Okay, we can probably do that yeah.

G

I'm glad you brought that up because I I think I mentioned that sign up P4 many many months ago, when I was when I learned about it. Maybe I've heard about it at a conference or something, but um it's worth considering.

G

There might be some code. We can just borrow exactly yeah I, don't know if there's a PSI interface written for it, though it's a P4, runtime interface. You know yeah.

D

G

Instrumenting the control plane manually, as opposed to Auto generated, is, is not trivial right. Yeah.

D

So it's URI, actually I mean the entire objective, or at least you know. In the beginning, the objective of this project was to generate the P4 runtime, so it can be utilized in the controller side and then write a P4 runtime. You know a server for Sonic so that you know it can communicate to some Sonic switches through through controllers right. So um but even then afterwards it was everything was driven through. How are the circuitry is in the Sonic right.

D

You know where things go into the previous database and then eventually turn out into the thing D and then eventually the PSI API, but the PSI apis were were whatever the high apis were before they were not Auto generated. So we do need to. Of course you know plug this entire thing into R.

D

um I guess you know the tooling that we have to generate the the PSI implementation and so forth as we bring in and leverage the side of P4 from Sonic for the underlay, and then you know introducing to our code base.

I

Did we touch base a little bit on the status of development of the Sonic stack for dash.

I

We talked about all the API if that, if whatever you're talking about is you're done with that.

A

Sure we have um some of the Sonic team members on the call.

I

All I want to know is we talked about Sonic apis here, which is basically a set of attributes so that you can configure specific. uh You know your Enis and all that stuff right. We integrated so far. uh The size server that we have version is the size three. If there's also- and on top of that, we basically replace the Sonic stack with side changer. You all know that now the thing the integration is what we cannot need um and that's what the radius database kind of where we tie things together there.

I

So in the roadmap that may was the delivery of the Sonic Dash. So I guess. My question is: what is the the status of that? Are we still on target for for May, and the second thing is: what did they use as far as attribute sets to populate the database for dash because we talked about and there are missing attributes right? We talk about missing stuff that needs to be provided here.

G

One of those attributes already defined in the Sonic Dash hld aren't already listed.

I

uh You haven't, we checked that I, don't know if they cover um all.

D

Of them yeah, that's the outcome of you know the defining the side. Dash apis and those attributes are essentially the you know the outcome of the side, Dash apis, but one of the things you know uh when sent. You know that, besides the main thing.

A

That we need, should they.

I

D

Yeah, these are the ones sorry.

I

D

Say no I was saying: Vincent is that you know besides Cindy, as you mentioned right, I think the major work that's going to need to come in is in the orc agent supporting the occasion of Sonic.

I

So I guess, if a vendor is to enter into Cindy, is the assumption that anything on top of the radius server is Microsoft provided for dash. It wouldn't make sense right.

G

That's my understanding.

A

Oh sorry, go ahead. Vendors.

G

Need to implement through lib PSI for their Dash that can end and get it integrated into sync d as a platform build option which probably needs another discussion. How that's going to work in practice right because there's the Sonic build image infrastructure and we haven't really to date. I, don't know of any discussions in this forum about how that should proceed.

G

But you know when you build a Sonic, build image. Vendors, add their platform as a build option, and it just becomes part of the Bonafide Sonic build image workflow, which is all Debian based.

J

What is the question you know? uh Top of the stack above the side, Dash API yeah,.

I

Michael, my original question is: when are we going to be able to um get? What is the status of the main delivery of the Sonic Dash stack.

J

Oh I think the HUD right, so um you know there I think uh a large portion of this uh uh of the uh control plan or management stack. You you call it whatever you call about it. I think has been, has been implemented and some of them actually being uh I. Think it's been open source in the you know, swss repo, there's a you know, Dash org and uh you know a PR um but I think the.

J

um Currently. You cannot really build the image because uh you know the the sign implementation currently is still not available right, so publicly uh not available. So in order to build the image you need to, you know work with those banners and they provide you the binaries. Oh sorry, not binary I mean provide you, the uh the the side, libraries. Then you can. You can build the build image on that and you know doing tests well.

I

So I, maybe I, give you a a concrete example: I didn't pull the Sonic, build image for that, but I just pulled this um two repos that I needed the SWS command and the side radius, yeah side radius basically include Cindy, yeah, uh I pulled that and I was able, with some changes in the Cindy like Cindy, didn't know anything about uh Dash attributes, obviously so I kind of I managed to have a set of divs to basically have Cindy know about Dash and I made and I was able to then run the side changer on top of thing D with my website, so the Cindy itself the components in this.

I

The main thing we care about. Well, it's kind of the next level up, I suppose for us with lip style and all that yeah besides the whole building a new platform on that jazz right. If you have seen the uh sorry seeing this is the next step, so is that still part of the main delivery or I understand it's not on the branch we have access to I'm, just asking for a timeline here.

J

I mean wouldn't that be make available uh in the public I I don't have that timeline yeah. So for that I think you know, um you know various components contributed by and you know various people. So you know we'll need to check uh what what the exact timeline you know we can make that available. You.

G

Know Vincent, that's interesting that you are able to modify sync D to get it to kind of build. It might be useful to have a PR, not necessarily one that would ever get accepted, but just as a reference to show the diffs or some other output and just a diff diff output and share that with the people with Microsoft, were working on and see if you're, under mutual understandings of what think he needs to do are aligned.

F

Yeah you can do that for the Sonic will damage part I, think it will. It should at some point follow what is being done in the switch side, so individual vendor will have their platform uh available in the Sonic, build image right for the for the uh so.

J

I know I know there is one one. One work in progress is to to actually take the BMV to that. We have in the dash repo and the and be able to integrate with that with the sync d. uh So in this case uh you know the if we call the dash API should be able to um you know, program the bme2 and the make the overlay part working yeah. So that way, I think it's uh it's in progress. I think um you know um two or three months.

J

I think should be a should be make available. Yeah on that, apart.

I

I think the when we talk about platforming something build image, I mean to be honest, that's just it's kind of orthogonal anyway, because all vendors will create their own platform is done for people who use switches and all that stuff. So that's orthogonal. The main thing is, you should be able to pull the goal at the end of the day. Is you should be able to even build a vs Sonic, build image and be able to do launch it in some kind of VM and configure dash dash parameters, Dash objects.

J

No I, actually I, don't fully agree with it. I mean I think the the goal is to having Sonic running on the dash. So, therefore, you know Beauty image is a part of the scope of the work.

I

I'm not saying otherwise, but once the support for das attributes configuration of objects for that, and all that is there. Creating a new platform for a vendor is no different than what it is now without Dash. That's that's what I'm getting at.

F

The current Sonic vs that's there is not really connected with the switch BMV to either today. You know um that is anyway, a method that can be used to start with and then eventually also integrated with the bnb2 or some other soft switch. If we have.

F

Non-Bm V2 version.

F

Another question here was that since we derived the PSI API, sorry the dash apis from the current bmv2 and given that the BMV does not complete, should be look at Dash PSI apis as a reference or as a standard. My thinking that it should be looked at as a standard, because it's not just that apis that have been derived from the P4 from the BMB to P4, but we are also updating it by hand, for example in ha and metering cases.

F

So I would think that the Dashi apis are standard and not really reference. So please correct me if, as needed.

K

Could you clarify on the metering case, do we have manually written apis for metering, did I miss them.

F

Mirroring or metering sorry Marianne, which one did you say.

K

F

Metering, I'm guessing since uh metering um is still under discussion. I would think that the metering apis also should be updated at some point as soon as it is closed, I believe that's still under discussion right uh all I'm trying to say is that uh any feature that we are discussing, um the PSI API the dash apis for that inside will be available sometime right once it is closed, um and at that point it becomes standard. Not really it's not really incomplete. As such I would say it is complete.

A

C

I mean the apis are done when Microsoft says they look feature complete for all features. They want right not before.

A

A

And then they would be standard.

A

C

I'm presuming there'll be a dash version, one put out one with additional apis in the future, after that, at some point right or 1.2 or 2.0, or something just like set versions.

A

Is that right, Prince and Gohan would go version based.

J

The the dash will be part of the is it actually part of the site right, so you know there will be 1.11 1.12, something like that. I think.

F

That's fine! As long as you know the PRS are merged. Do we you know, we would think uh that they are standard at at that point. Right, of course, we'll keep adding new features on top.

D

Yeah to answer you know to answer reshma or answer your question in terms of standard versus the reference. It seems that we are trying to standardize PSI API, yes, but not a standardizing. The models right in.

F

Other words yeah.

D

Exactly the BMV too, so so, since we are, we are only standardizing. The PSI API see the idea here is that you know. If you look at the ways PSI Community has worked, um we always take the those underlay apis like of a better word. You know the pre-pre-dash apis, whatever the PSI apis are basically were, have gone to the psy community and or deliberated upon and eventually ratified and become a standard and become part of the standard header file um that that was a process that was taken up.

D

You know the discuss and so forth right, but if we are doing the same thing on the dash apis, which is we call it PSI overlay apis, we are not really, you know at least uh exposing the the models into the community PSI Community. Instead, we are just saying: okay, whatever we have generated out of those models is the one that we are taking and as the models change, the API is going to change and then, of course, the versioning will be required over a period of time, but we this is.

D

This is what I see how we are doing it. um So to me the PSI apis are, we are trying to standardizing it and not the model right.

F

I completely agree with that.

A

K

I'm lacking definition of standardizing the model, but uh I thought the purpose of uh using before was to have a a precise description of the model that will be a standard.

A

K

Yeah that you can verify but uh verify easier than you can verify video, so why we are saying it's not a standard.

K

It may change, of course, but it's a standard anyway sure.

F

I mean as so, we can say that definitely, the bmv2 is closest to the to the to the PSI API in terms of what can be executed. There is no question there. The only thing is that all we have always been referring to BMV to as reference model right which it is. We need not think of Dash apis as reference. We we think of the dash apis are standard.

F

um While we continue to have the bmv2 as a reference model for sure that can be used on the hardware, they should be mostly in line, but is there in dash API and what is there in BMV too, um which is why BMV to also will be standard um write. The reference model will be also. What I'm saying is there could be gaps right, as we know, we have some gaps right now.

F

um We just want to clarify.

F

But discussing from Dash standpoint, the dash apis are viewed more as viewed as standard and dash apis are not really viewed as reference. That's all I'm saying.

K

And but that's a question of scope: if something is at the moment out of scope and bnb2, it doesn't mean that, like being V2 is not a standard like we have the full definition of Vietnam, it doesn't mean that it's not a standard forbidden to unit we. uh We cannot say that okay, some other uh Behavior, some other packet Transformations, will be compatible. I, don't think so.

H

A child would take it like I, say, assign API, or this object is more like standard, because it's the final object level is more easy to understand, but for this Dash API might take it's more like a reference, because if we Define it like the P40 the behavior model, then we use that one to find the the policies. What are the objects? What we need only for that, in particular reference model. So that's why I would say like the hard one doesn't sound like a standard. I was huge fan of reference.

D

Yeah Eddie I think I I get get your point and also reshma's and Marian's point also I think what we, what we should do is we. We can say it in in this way that for generating PSI apis, this BM V2 model is a standard. However, for building your Hardware, this, this P4 model is a reference and also for basically, you know. If you want to do a control plane, then this is also a reference, but but foreign.

K

But that's not the question that uh I'm asking I'm not asking anyone to build uh Hardware exactly as it is described in here exactly exactly.

D

So I think that's what I'm saying I get your point. I get your point right, so I think in in that point Marian. You know why? Don't we do one thing right if we want to say this thing is a single source of Truth, and this is a standard. Then I suggest that we submit the model, along with the PSI apis to the side community, so as to show that okay, this is the one that they need to ratify as well. It should be, it should be.

D

You know, uh the the P4 model should also be uh committed and checked into the side, repo in the OCB Side Community, uh so as to show that okay, this is this is how we are going to generate this thing, and this is what the 1.0 is and then with with something that either people can Auto generate, or we have pre-generated header files right that we are going to be committing uh to that repo I think we should do this thing so as to show that okay, this is a standard.

D

Both of them are going to be standard. The source of Truth through which we are generating out from and then also the dot H5.

K

G

Do we we actually need to check in the model and and the code generator into SCI repo, or can we just refer to it to a commit ref which it's stored in all for all time in GitHub anyway, you know copying files doesn't feel good to me.

K

We can't, of course it will be maintained. We can have a sub module, we can have a point or we can have whatever but yeah yeah the same way like you, you can argue the same thing about Visio for uh for standard size. No one tells you to to build Hardware exactly how this video describes, but.

D

K

uh Back it in and pack it out should be the same as described in the video.

A

So is that an action item we'll we'll take is to submit the model.

K

Do myself, because that was actually a request from style Community to have all the stuff? Besides feathers.

K

It's already a plan.

A

We we only have about 12 minutes, left and I. Don't know that I quite got the answer to this question here, which is: are we saying that, in about two months we'll have what Vincent needs was that what we were saying.

J

I mean I, don't know what exactly Vincent is uh but I think we'll.

I

So I found a date somewhere on some road map on the wiki I, don't recall exactly where it was basically on the release um for the next release. I think.

A

I

A

You need Vincent well.

I

I mean there's a date there. I just want to know. If you know how far are we from that I.

J

Suppose which release? Where did you find it.

I

uh Yeah I need to find that uh I'll find that was.

A

It on the Sonic page.

I

Yeah he was somewhere, it was definitely on the Sonic Wiki, uh maybe some kind of planning, okay off on the page again.

A

Oh okay, all right: well, hopefully we get what you need and then honey um did someone want to follow up on this part, uh the pins project and there's code we can borrow or do we need to do this?

A

Anyone on the call doesn't have to be honey, I mean yeah.

D

As as I was mentioning before, right, I think we as part of getting this minimal support right. We can just look at which part of which portion of the the side or people that we can leverage so that'll be um that work can be done as part of the pr that was already I. Guess you know um flashed by I, guess you know, or mentioned by by Chris right.

A

um 236 up here.

D

I believe so yeah.

F

At some point, we could have a detailed discussion on what we can do basically side out before is the Upstream P4. That uh goes with the pins project. Right now, it has basically a three routing actual mirroring.

F

um That probably is sufficient uh for the underlay that we are looking for here. If that is the reason why um uh hanif brought it up and we yeah, we can discuss this further I think there is also a extensions, are how we merge, uh basically, the side.p4 with the existing P4 for the overlay part of Dash discussion that we have been having here.

F

um Those we can discuss that in some more detail, probably offline or or here in the upcoming calls.

A

Okay, like tomorrow's behavioral model, call or give it a week.

F

um Yeah uh either way is fine. We can discuss it tomorrow, too. Okay,.

A

Okay, well, we have nine minutes left. um Is there anything else for today.

A

Sounds like a no um John I hope this was informative, since it was your first time in.

A

We also have a high availability work groups for Dash, and we also have a behavioral model. Work group is tomorrow, which is the P4 behavioral model. Where we talk more in depth about that. So um did anyone have other items they want to talk about today, or would you rather have your eight minutes back.

I

I just found the page. Sorry, oh.

A

You did, where is that? Do you want to put it in the chat window.

A

Or give it to me.

I

No, it's a GitHub page, okay,.

A

I

A Sonic 202305 release, okay, and it's got dashing for uh all nine number. 12.

I

That's that's. The only thing I saw about dashing this kid you'll.

A

Yeah, okay Gohan here it is.

J

A infrastructure part.

I

Like I, say, I just don't know and I think vendors in general, we kind of need to figure out. You know we're talking here a lot about leap, science. So that's fine and that's needed. That's all good, but that's only part of the equation. That's.

G

It almost sounds like a little seminar. Workshop needs to be conducted to say, hey, dpu, vendors. This is the process and approach for integrating this into a bona fide Sonic Image right, the all the all the stalwarts, all the incumbent, basic vendors who are part of Sonic, know this.

G

They have teams of people crawling all over the Sonic repo and doing things all the time, but there's probably new players now in dash who haven't gone through the whole Sonic boot camp and maybe just a walk through a summary saying: okay, here's the process to get your sync D into the Bonafide build workflow. Is that a reasonable thing to consider yeah.

I

But Chris the fight is: if, if Sonic doesn't know about Dash, then you can integrate all day long. You won't be able to do anything with it right.

G

Well, no, that's like a separate topic right there right. The top-down infrastructure has to be there to meet at the redis DB, so to speak, and, and there are people working on it, it sounds like we need better visibility into the status of that that's the original question, but it seems like there's also possibly a gap in terms of what's the plan for vendors contributing their part that fits into that.

G

You know beyond Psy.

B

A

That be something we could provide um or talk about in a session um in one of the community meetings, Gohan and Prince.

J

Which part sorry.

A

A process what we just talked about a process for them to integrate into the Sonic Image.

A

J

That is the very vendor specific question. I think you know we need to get the the lender to talk about. You know how they plan to integrate the sign to the Sony imagery, but I. Think on the you know, the platform independent part where committed to to get into the uh get into the Sonic Image.

G

Well, I guess I would ask, what's what constitutes completion for a vendor to say you can go to Sonic, build image and say platform equals XI excite make config right or something like that? What what are all the the prerequisites to make that a complete task, maybe I'm, advocating and don't need to be, but it seems like there's a lot of probably some tribal knowledge that you know at least a bull list of things saying these. All these objectives have to be achieved for it to be, for the vendors have done their job.

G

You know in terms of building a bona fide image, and likewise Microsoft has to build everything down through the orc agent to have done their part, and maybe parts of the sync decode base I'm just thinking. Maybe a review of the the top items would be useful.

J

G

J

Think they see, you know, there's a two part right. So I think you know, um you know be able to run Sonic on some of the you know. Dpu platform I think is certainly available.

J

um You know, if you work with a dpu vendors directly. You'll, probably you know be able to get uh get those codes. You can run Sonic and then the swss all those codes are, you know available right so, but I think that the process of getting all of them to be. You know to be Upstream the open source right, so that testing uh uh you know, might take some time. I. Think the item on this uh may I, don't think you will include all of them right.

J

So it's just mainly on the infrastruct part which unit establishes and those basic scenes and be able to. You know to to to be included uh in the image, but in order to build a workable image uh that work on specific dpu uh I think there's still some work. uh You know you you you, you need to work with the dpu vendors to get get get that part I.

D

Mean you know, I think Gohan. If you are a dpu vendor who has who you know, why would you work with another DP vendor, and why would the DP window work with you when they are competing with you, so I think. The idea here is a new DP vendor comes in and says that okay, I want to really I. Have a dpu and I have a lips eye yeah based on you know your PSI apis.

D

You know, what's the next step in terms of really uh integrating and testing it to ensure that I'm qualified for Sonic Dash right so I think what is the minimum set of things that is basically is it? Is it that okay, you just uh go ahead and and and create a lipsa and then integrate with just a Sonic uh uh or sorry the thing D up till the Cindy in a very you know, stripped down version of Sonic and then be able to test it at that level and not have end-to-end testing?

D

What is what is the minimal thing? Maybe that's that's something that you know I'm just again advocating on the behalf of you know the vendors.

J

That part I, think you know um there's two two aspect of the this question. So why is that? Yes, you know in terms of the the the the the the control of the deep Hue. uh Yes, you need to provide the side you need to, you know, do the integration and we have set of tests you can you can you can use it to run right? So you know really. We have the side test. We have something management tests. We have Geeks attached to to run right.

J

So then there is another part of the uh work. Is that since this is uh um you know, this is basically a platform OS image right, so you have to do other things, which is not really different from Asic uh basic box. You know the switch box. You have to integrate your platform, you have to get those temperatures, um you know in case you have fans, then you need to you know, do those simple integration which is already in Sonic right.

J

So then you know, depending on your boot loaders, uh you know your your CPU type, your arm core, you, you have to build the you, have a build image on that right. So you know currently the Sonic that allows you to build the Builder Army image, but you know maybe different uh deep view. Vendors have a different image format, so you know on that front. You have to integrate with the image build process with uh in the build image. So those part I, think it's it's a you know. Every switches vendors have been um worked.

J

You know how to integrate those parts into Sonic, so they they have a you know. They know how to do it. Then they only see new here. Is uh these are side part right so but I'm just I'm I'm saying that not just the side part, but other parts is also needed in order to build a whole image that you can put on a dpu on the right right. So.

L

Just for curiosity, when do we think we'll have a community image for Sonic Dash rough estimate. It's like this year next year,.

J

I think that would be you know. This is a good crashing. You know, uh you know, uh you know when we are talking about Community, you need to. You know, have all these. You know all those things to be uploaded right to the Side Library. You know this all those things to be uploaded. uh Unfortunately, I do not have answer, but I think we're committed to get. You know the the the the um you know, the more platforming independent commode component, ready right so at least on the May.

J

We'll have all this infrastructure to be ready. So you know the you know um yeah so and then, and then you know, but I, don't think we'll have all the feature to be complete, because uh you know there are still some spec been discussed right. So then.

L

These are the components that needs to be done, but, for example, what will make you happy? Let's say hello.

J

Make me happy, you know I um well, so um I I see will need to have all these things to be uploaded to really you know anybody can take. uh You know the building me just like the switch uh to to be able to You Know download and try to dash right so I I think that that is a goal that I want to achieve. I believe you know we will definitely get there. You know just like uh with the switch boxes right. So it's just uh um you know.

J

Maybe you know the you know I think there may be some. You know thoughts, okay, I! You know deeply when I say I, don't have everything complete right, so you know, maybe it's not the right time to update you know to upload um so that you once I upload I have to give support right. So you know those kind of concerns, maybe those things um that they are waiting for all the features to be completed, to get uh to get things into the public right.

J

So I, don't know I'm just uh speculating right so but I think you know that's a process that will work with the community to walk through. uh On that, at least the Microsoft part right so we'll we know we'll do those uh you know um uploading or trying to you know um bring bmv2 into the picture so that even without the dpu people can still do some testing on dash yeah.

L

And the other one is: is there any desire to have a community image for the dpu itself, where that will be skipped, and it will be only for smart switches.

J

um uh No, no I I think the thing about on the GPU I think about it. When you talk about Smart Switch, you mean the Asic plus okay, we're running a time, but I think the answer is yes right, so think about the Smart Switch. The Deep view is also running Sonic, so there will be an image for that.

J

I have to I, have to drop, but I think yeah sure is.

B

Gohan a question for you: when you're clarifying the DPI components, are you expecting all the Microsoft side of the PA components to be there by May? Is that is that the date.

J

I heard no, not all the parts right, because I think you know we have still have features here. You know developing progress like I said right. So, but I think you know the the basic part you know, for example, win at winner. Those things actually could be there. Okay, thanks yeah.

A

J

All right thanks, yeah yeah.

A

Thanks Gohan thanks, everyone, I I, think guys I'll probably have to call it for the day. It's 1004.

A

I'll. Let you go back to your other meetings. um We can. We can pick it up next week. Thank everyone for coming and I'll post. The notes like I normally do and I hope you have a good day.

D

A

You guys have a good one. Bye-Bye.