DASH Community Weekly, 3 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Workgroup Community Meeting Aug 3 2022

Description

Counters presentation
Intel SAI PTF test demo

A

Third session of dash community call, so today we are going to talk about um we're going to have some preliminary counters that we were wanting to present, and I will share my screen here and we also had reshma who wanted to respond her team who wanted to give a talk about my ptf.

A

So that's what we planned to do today and I can present the counter screen if you like that work for you.

B

A

Okay, great I'll, share a different screen here.

A

So guys um in the normal um general folder design, the packet transform document, there's a section that's been empty, except for a brief description called counters over the last nine months, and I put some information in here last night- uh the counters that we've been going over internally and wanted to share, and so this is what we've come up with and it's published and shy. um I don't know if we want, we probably don't want to go through every single one, but I have jay on the call here to talk a little bit about him.

B

Hi, um this is jay from microsoft, um yeah. We have come up with some counters uh for the dash community and uh we I would like to go over these counters with you guys to see um what do you guys think of it. This is very first draft of this counter, so feel free to uh comment on anything.

B

uh Some of that I may not be able to answer, but I will be happy to bring it back and then I'll get back with you, uh of course, for the answers um so basically um yeah we can. I think we can go over some colors and then see what it feels like.

B

um So, let's go starting from the beginning. I think we have the total packets. uh This is just the total pack in front of vm uh exposed to customer uh this. We have in uh inbound and outbound uh packet counters. uh Similarly, we have total bytes how many bytes are sent from the vm. uh Also it's both the customer and then we have total unicast packet or multicast packets for ipv6, um tcp connection.

B

uh Reset uh heft ttl.

B

uh Yeah tcp connection they had uh uh reset and ttl cut down to five seconds. We have offline cars for that um and then non-seen stateful, which is nonsense. Tcp packets, uh that are not dropped on.

B

We also have counters for this and uh feel free to comment uh if these are going to be useful or not, or if you want to add more colors. uh In addition to what I have it.

A

Looks like looks like marion has his hand up already um yeah go.

B

C

A

C

Yeah hi uh jay, what multicast packets are we talking about.

B

um So vm is uh able to send some multi multicast packets uh out right. We are just calculating with multicast packets.

C

So destination ip will be multicast.

B

Yeah multicast, I think, has the messages of uh the most multicast packages. I think you'll want to do something like that.

D

Sorry, what are we talking about in multicast? We don't say multicast for what.

B

D

I couldn't really hear you, so what are we talking about multicast? For what service are we using multicast.

B

um So in the past uh I think we have some customers who wants to issue some multicast packets out of the vm.

D

They wouldn't be respected by the network. We don't support.

D

I I would check that out. Our network doesn't support multicast and so sending a multicast pack. It out anywhere.

B

When you say our network, uh it's part of the network.

D

No, no, no, no switch in our network supports multicast.

A

These are the dpu counters.

D

Yeah, I don't know we, don't we don't have a multicast service. So let's look that up.

A

Take a note separately.

D

Because I think it you know there was a time in our network where we supported certain things like that when we had a different. There are two networks followed by you know a layer, three networks, but we don't. We don't build those anymore and.

A

D

Don't support multitask at all, so we'll take a note and check on that. One.

E

Yeah, that's good, but but this is a this is a virtual network, commodity construction, it's not the physical, narrow, mod cost.

D

We don't have a multicast server in any of our services.

D

So we can take it offline. I don't believe there's any such thing as multi-caps in virtual or physical.

E

Stat doesn't do any harm, so if somebody wants to count them sure.

A

Yeah we have a lot to get through. We have all these counters plus restaurants, presentations. So I'll take a note. Maybe we can keep going.

B

B

A number of flows we simulated, um so this is when um some configuration change. This is triggering uh resimulating of the flows. uh We should be counting how many flows have been resimulated to because of this configuration change.

B

um Redirect rules resimulated you have uh this is, I think, similar um uf means unified flow here, but I think the more correct term is a connection we will be changing to from uf, uh which you have stands for unified flow here, but we should be changing this connection.

E

Jay, what does re-simulated mean so.

B

When, when there's a flow, uh when there's a tcp connection, um there's a flow that has been set up of, it's like on action match right from uh if the vm is sending a packet to another vm there's a um the the dpu will have an action match like this.

B

This address to this destination address will need to be um maybe encaps to some other addresses, and then this connection is set up with the flow and if there's some kind of configuration change like mapping, change or some other changes, then they will re-simulate.

B

uh The gpu will resimulate the flow, so it doesn't have to go through all the matching action again, but then it will just take a flow.

D

Actually, I think we've talked about this before so this. This is a complicated thing. I think I don't know if I've submitted the document but free simulation. When you do any change, it doesn't matter what the changes.

D

No matter what the change is you don't you have a connection table. Everybody knows what the connection table is. That's holding all our flows that were dynamically created.

D

If you make a policy change, you don't know how many flows in that table need to be modified. You have no idea, so you actually uh need to re-simulate the entire connection table. You have to go through it, one by one. You have to see. uh You basically have to re-simulate the flow path, to be honest, to figure out whether that connection should exist and if anything else has changed about that connection like the forwarding or the transformations they need to be fixed, and so that's why you don't really want to.

D

You know: do one policy change and re-simulate the whole table immediately? It should be done and after receiving you know so many policies over a period of time. um Don't know what that should be, but it shouldn't be. Every time you get a policy change because the you have to go through a table which is 64 million deep, but you don't.

F

Know where the.

D

F

Gerald, do you have to go through that table one by one like a in a process like that or or can when the next packet arrives, for a given flow? You rerun the policy on it like.

D

F

That would mean.

D

That everything is b that would be terrible. That means, if you had 16 million connections, you'd, be running 16 million new policies and real time policy evaluations in real time. You'd be a dog like you. Your throughput would dive so you're doing the background. So.

E

So so so jared, so this flows through simulation. We didn't really talk about right in the community as a part of the requirement is that right.

D

I passed the paper to one or two, but we can reissue the paper and talk about it. It's something that vfp does today and it's something you have to do. It's not optional and okay.

E

Then we need to talk about this feature first right, so they introduced the concept to the community, because I'm not sure you know the community fully aware of it, and you know- let's not discuss this briefly right. So you know if we want to set this as a you know, mass must require features and we need to have a session dedication to discuss is what is the scenario you know why we need it right. So those kind of things before we discuss the counter for this one. Oh.

D

Also, it has to be part of being at tavina. It's it's a basic function of being at the v-net, so yeah.

E

Yeah sure sure sure, then we need to you know I'm suggesting right. So let's have a separate session to discuss that right. So.

D

We should do that next week because it's super important and it does take a lot of bandwidth from the dps themselves to do it any way you do it. It takes a lot of bandwidth, so we can. We can talk about it next week. I'll have something ready in writing.

E

B

um And then we have a bunch of dropped counters like drop packets uh and I think, just in general number of job packets that we have on both drop rate packets by dropped by some uh guard in um in the in the policy and then um can have some invalid packets, uh spoofing, packets and.

B

This is explicitly blocked by uh the policy also.

C

Does the drop spoofing packet mean that we have a mess on the pa, validation.

B

Sorry, can you say: yo mutton.

C

So drop spoofing packet. Does that mean that we don't have a pa validation program for that source ip and it is an unknown source public address? Yes,.

B

C

We are dropping.

E

Yes, it's like an rpf check.

B

So if the source is unknown, I think we are thinking this packet is spoofed and we are dropping this packet unless there's a uh explicit policy to allow this voting package.

E

I guess the question is which source customer space of provider space.

B

Oh, this is the customer space our source.

A

G

So jay, uh you know.

F

Maybe more specifically from a dash pipeline perspective at what point should this counter.

E

Be incremented.

D

I don't think by the way, there's any thing in our pipeline that allows you to do that. Exactly you look at the. If you look at the rules, rules are an ended list of many destinations and sources. You don't know which one it only takes one to make the rule positive in each of the buckets and so in the end. Rules cannot tell you that you know if it passes or fails, they fund long lists and end functions right and after that you do forwarding and transformations.

D

There's no notion of I know which source addresses are part of my veena, and I check that to see if it's valid like there's. No, there is no check like that.

C

Now gerald uh I disagree with that. We explicitly put that kind of table for checking pa.

D

Where are you getting the information from.

C

From the c8.

D

Okay, let's check it. I could be wrong. I'm not aware of that, um but we'd have to make sure that's plumb, because the only way you could have got that information. If somebody built the table because it can't be learned.

H

It is from the controller, I thought the cipm mapping table.

D

Okay, let's check that make sure that it exists if it exists at that point, um but that's also another lookup that needs to be added into the pipeline.

H

Right and what about the eni lookup, if it fails, will it uh become part of this counter? If there's a if we are just um forwarding the packet when there is no match with the eni.

B

H

Or is it related.

B

H

B

Yeah, if you scroll down to the end, I think we have no emi match.

B

But yeah, I think we maybe uh it might make more sense to at the drop prepend uh in the low enough match also because they will be dropped. Also,.

D

Yeah, that would be a good one to have for debunking for sure.

I

I just wanted to make kind of a meta comment here. um I think it would be a good idea that we someone tried to put these counters in the p4 model code to find out if there's a major uh discovery, surprise or mismatch, um because sometimes these look good on paper, but then trying to get to the pipeline. You realize there's a technical problem or an inconsistency or impossibility.

I

So just as a reality check, we ought to set a goal to do that at some point in the not too distant future. That's that's kind of part of the review.

A

You took a note.

E

B

Okay on and then we have some other job packets, uh tcp connection by reset uh tcp connection reset by injected reset. I think this is.

B

Take the pm injecting the reset packet for tcp connection, but actually I'm not 100 sure on this one uh I'll I'll actually get back on better description. With this uh we have more drop packets here. Redirect packets uh pa discover packets.

D

Remember we're we're not the end points so counting the resets for uh that are received on it me and I for its connections. It's pretty useful, because if somebody's, if somebody's phoning in and saying hey, you know I lost connections or whatever at least we know that recently a panic thing right. So I I think that one is very useful, but always remember we're the in between guys, we're like in the middle. We're not points so we're just monitoring things that one sounds super useful for debugging.

B

A

Did you repeat that gerald I was trying to take a note and I messed up.

D

And saying that remember, we are a bump in the wire. We are not the tcp endpoints. So what we do is we monitor things and we keep connections, no open so that they can go through and then we close them, but we're not the end point. But what is super useful is if a customer is having issues where they say: hey, you're, losing connections, and I don't know why. At least, if you have a reset counter um that tells you that hey you know.

D

um We know that we, we were receiving a lot of resets at that point. That would come from the end points, but it's useful information. At least we know that there was a bunch of connection resets done, and so that's why it's useful, because we can okay then go look at the end points and we can see.

D

You know why that's happening, but at least you know that connections were failing at that time frame and they're failing properly, because the end points did a reset.

A

Got it thank you, and I know we can't go through every single counter here. I think we'll have russia pick up at 9 30, but keep going jay pick out any. You specifically want to look at.

B

Okay and then we have this.

C

Can I yeah, can I ask one question because we briefly went over those? uh I don't think there is any definition in dash community of pa discovery. So I don't know what pa discover. Dropd discovery packets mean and the same goes for redirect.

E

D

Redirects happening um in the ilb: that's how ilp works. You basically go through an srv and then the sob sends a redirect in both directions for iob and.

C

D

In general was not.

C

Yet uh ilb in general was not yet uh I I suspect.

D

That it will come yeah, that's where it's gonna come, I'm just saying: that's where that counter. So when you're doing dna, you're not going to see that, but as soon as you do iob, which is part of being it, but it's like a future uh workplace, then you will see that you will see for sure.

H

Also drop the drag packet right. We thought that fragmentation wasn't uh going to be um applicable.

D

It's a future consideration, we're not doing it right now, correct.

A

Which one rashford.

D

Fragmentation, sorry.

H

Yeah, okay, that one the dropped, drag packet; okay, yeah.

A

A

Just making you know that it's future okay, so did that answer marion's question then about the pa discovery? Is that a good enough answer marion or do we need to go back and.

C

Research, we talked about redirect discovery.

A

Yeah, the other one: okay,.

D

Yeah, I don't even know what that is, so somebody else will have to answer that question.

B

Yeah, we'll just get back to uh get back with some answers about pa discovery. I also don't have a clear idea on what the spectre does.

B

uh Anybody else have a question on the counters that is being shown on the screen right now. I.

F

I I have a question um like so these are like a set of defined counters that are per eni, but um there are other counters for eni right like for you know like the route entry can index a counter, maybe maybe even the acl um acls can index counters.

F

Am I correct on that and um like it would be useful um to understand like what the scale of those would be, um so that we understand like how many total counters we need per per eni.

D

E

Yeah is there a public pool that you can use or a pool that is resource car to at least attach them to a route entry or an acl entry or a bucket yeah? Definitely useful.

E

Also one other question I have is: do we want any sense of direction on any of these counters in and out or rxdx or are they all global count.

A

I think I wrote that up here.

D

The ingress, which can be different than the rules on the egress and and the transformations are different. The forwarding is different, so yeah.

A

Inbound and outbound inbound and outbound through the pacific flow the counters, increment and track separately for the inbound and outbound. So that's here does that help.

D

Yeah, I think that's clear. I think that I don't know who mentioned it, but I do think that we should be counting how many you know how many times a role was hit.

D

Maybe forwarding I don't know, but um we should christina have another meeting on like the pipeline itself. What counters do we need from the pipeline directly.

D

And we should come back with that.

F

Right, like I thought that there were counters like associated with billing right, like these counters, seem to be associated with just um you know, debug and overall status, but like I thought that there was a whole another set of counters like associated with billing, depending on like where the traffic is being routed. There are different counters that have to be incremented.

F

D

F

If you're staying.

D

Within the region, this one right right, if you're leaving the region another place if you're using a special server like this, for example, is another price but um yeah. So you you're right, so we we should, if it's not included in these counters, we should review one of the feelings.

A

And so the billing work is happening right now, john um james grantham's team is working to try and define that.

D

A

So we're on it.

F

Yeah: okay, okay,.

A

Yeah, this is just the first swing of what we have right now, um I'm wondering. If maybe could we could we go back with our questions um and maybe let reshma do her presentation now and wrap this up, and maybe, if there's more questions you know, give me some issues or pr's against it or email me and I'll. Do it something like that or do we want to talk about this for a couple more minutes.

D

I think we can do restaurants but make sure that if you guys um just send out the questions christina and let people respond hey, I mentioned this. One just make sure we collect all of.

A

Yeah yeah, I'm definitely taking notes, and I know you guys have been asking so this might not be perfect, but it's it's out here, so um we'll keep working on it.

A

And if you have any um advice, please give it to me or give it to us me and jay.

A

Okay, um I'm gonna stop presenting and freshman. Do you want to go ahead? Yeah sure, thank you christina. Okay and.

H

A

B

H

You uh voldemort nick would like to present.

H

Hi everyone, I think we have discussed it a few times earlier, but uh you know uh just a quick recap is that uh intel has developed a python test framework uh test harness uh and has upgrade upstreamed it to cpc. um It's an auto uh python based uh data plane, testing framework.

H

um It creates the python wrappers around the site, functions uh automatically, so that the test case can be written with much more ease and hides the rpc etc, which will go into a little bit at the beginning uh for dash.

H

We um have been adapting this framework to work with dash devices with fewer ports and um a lot of test cases that we have also have been adapted to uh the dash uh use case as well, and the dash device, mainly um in today's demo, we'll be showing this test harness working on dash device, uh real hardware, the intel ipu.

H

So yeah. uh Please continue to the next slide. I will do it.

H

Yeah, please continue working yeah.

G

Yeah so uh hi everyone so yeah. Today, as much said, we are going to talk about the running pdf test on ipu, so, first of all, the brief for you of the ptf and or size rift server and client, so we already presented what it is and how to generate automatically the size server and the psi client from the your sci library. So here we just you know, put some brief explanation of what is happening here when you use the generation framework and yeah.

G

So for this demo we prepared, like a few scenarios, uh very short scenarios and to run on the ipu. So we are going to show the end cap and uh and decap the scenarios in case of the v-net use case, and also we are going to run everything using the ptf test case framework. Also, we will run everything on the apu and also at the end we will show the some someone simple, stateless acl example at the end, so uh for today's demo we prepared the simplified setup just to show this use case.

G

So we have the host and we have the test controller or, let's say client running on the same host inside the docker container.

G

Also, we have the site street server, which has been generated using the auto generated scripts that we just discussed before and also it is linked with the ipu libside, which uses before usd to control the ipu yeah and the flow uh from the pdf framework, or, let's say from the test case, uh to the ipu and from the ipu is explained here.

G

uh So the first use case, yes, is.

H

You like to show the other diagram how it maps to uh the ptf framework itself. The um the diagram in the document, the pdf server, where the rpc server is in the client is.

G

uh Yeah, maybe I will just show- or so this one right, uh this diagram uh so.

H

No, no, I think, you're showing the wrong one. The document the details.

G

Oh yeah yeah, okay, here this one uh yeah. So this is the official documentation which is already on the sci repository. So there is explanation about the how to generate the site street server and the client library to be able to use for your test cases so on the right side. uh Dude.

G

In our case it's intel ipu card, so we have the ellipse side there and also we have rpc generated server, which is running also on the ipu, and we have auto generated the size, rift client, which is used by the power tests uh to run the test case itself.

G

So this is the official documentation, so everyone can go and you know read in more details how to run it and.

H

Yeah, I just want to show how this maps, with your software components, diagram, yep.

A

G

So uh yeah, so this is absolutely let's say, aligned with what I showed on the official site, ptf documentation. So on the right side, we have the site street server and on the left side we have the client and the ptf framework which have the test cases which uses the site rivet client to execute the exact test case scenarios.

G

Okay. So let's move on so for the invent, let's say traffic flow scenario. So what we will do, we will configure the invention rules on the ipu using the auto generated python, size, strict, client apis. We will send the excellent packet to the network to host direction. With the pin attach heater, we will check that it matched the e9.

G

Otherwise, it's dropped and the check the packet is matched our source, ip address p and otherwise it will be dropped and then we will run ensure that the packet matching in invent and routing is the cupped. And this is the details packet details.

G

What is happening uh during this use case from the right to the to the left, so we assigning the vxlan packets to the to the physical interface and it goes through the ipu through the configured tables, and then it goes as a decappt if it will be matched the ee9 and pi validation tables and let's go to the scenario itself.

G

So on the left right, we we see the si repo with all changes we already did for the ptf. I mean that to be able to run on the devices with the fewer ports and on the right top corner, we we start the si server okay, so it start listing.

G

On the port 9092 on the bottom left, so I start the tcp dump on the one on the port, where we will be sending the traffic and on the right bottom. So we start the tcp dump on port, where we will receive the traffic okay, let's go back to the site, pdf and let's uh run the inband test. So before running the invent test, I will show the test case itself, so uh we I'll be prepared for this demo test case.

G

This is the pdf this case, which uses the new uh class, which is it can be used for the dash okay. So we are using just the two ports so we're defining the direction. Look up in ipa validation source ip.

G

uh Also, we we creating the v-net uh configuration which is described over here so uh like uh deep, so direction. Lookup like create a dna, we're creating the unite to mark mapping, creating in-band routing with a d-copy validate action, and then what we do here.

G

So we we set up everything and we're sending the vxlan packet with the invalid destination mac address with the invalid pe validation, ip and then we're signing with the vxlan and expect that it will be decapped and if you go back to the direct to the console. So let's start at this case, uh so I added the pdb traces just to stop the test case and show what's happening a little bit so on the right top. We saw that that hardware has been programmed with the correct values based on our configuration.

G

Then we sending the packet that, with the invalid destination mark.

A

G

The left yeah mac address on the left, so the packet has been set, but nothing has been received on the right. Then we set send the packet with the invalid pa configured. It also has been sent as you can see, on the left, but nothing has been received on the right.

G

Then we send the packet correct one and we expect that's. The packet has been the captain based on our configurations and then hey yep. Excuse me.

A

I just said that was cool. Okay,.

G

Okay, so let's go back to the next scenario, so it's related to the outbound traffic scenario. So we do. We configure the outbound rules, we use different setup. We send the packet, the cupped packet to the net, to the uh unique itself and then with the v-net one in our case, and then we check that the packet is kind of encapsulated based on cap mapping configured in the test case and again, this is the packet details.

G

What is happening with the packet from the left to the right, so we send the ip package without the encapsulation, then we it goes through the ipu. We have the cp mapping table here explained over here and then it goes with the vlan tag, which is also presented on the right and yeah and let's go to the live.

E

G

So I will just scroll out a little bit uh and then test case, so once we start, the configuration will be applied and on the right bottom, we observe that we programmed the device through the libside and sidestreet server and if we go to the outband test case, so we decided to use absolutely separate test case um for the inventory.

G

So again we configure like direction lookups here and let me go on next yeah, so we're creating the underlay routing for us just to populate the mac addresses correctly and uh configuring the neighbors, and we also configuring the direction lookups and e9, creating the nightmare mapping. Outland e99 and I've been routing and cp entry. What we are testing today with this ap address, so if we back to the console, so configuration has been applied so right now we are going to send the traffic and we expect that it will be encapsulated based on our tables.

G

So let's continue and as we observe so from the right to the left, because we send traffic now in the opposite direction for the previous use case, so we send the ip package and on the left, we observed that the packet has been encapsulated with the route well with the correct values like and the mac address, of, the rotor interface within neighbors and station mcadris, with the v9 number two, as explained on the on the slide, and it was for the outland.

G

So we have some another the test case. uh So it's just a regular, a stateless ico. You know, so we can just demonstrate that we can, you know, just deny over me the packet, so we implemented just simple dmoc matching here. So what this test case is doing, and so uh for now we send the the packet before anything is configured on the device.

G

So nothing is received and then we will send the correct packet with the right destination mark address entry like here and as you can see from the left to the right, we send the packet and received on the right and if we right now we are sending the packet after the entry has been removed from the device and the the packet has been sent, but nothing have been received on the right uh yeah and the test case has been passed. So everything is okay here. So I'm done.

G

If you have any questions, so please go ahead.

I

Well, that's great. I have a. I have a few questions if I can ask yeah yeah chris. um First of all, it's awesome to see it running on a real piece of hardware. Well done. Yeah uh yeah does so does the psi api that you generated correspond match pretty well to the bmv2 p4 model in the dash repo there's the same tables, the same elements.

H

It's the same tables that we have described in the hld, so definitely it will be matching with the bmv 2 as well. For the most part.

I

I guess more concretely: could these test cases be leveraged in the bmb2 model on dash exactly.

G

Right so we generated the the rpc and based on the external api that we have in in the community today, so it's absolutely aligned with the dmv too. So here you can take it and run it.

I

Do you think we can try to get these running in the bmv2 model? uh Some of these, the ones that uh you know the b and b can support.

G

It it depends what bmv to support it, but we cannot, of course,.

H

Yeah we can use yeah.

I

I think it would be a good litmus test as to how ready the behavior model is right. You have a real piece of hardware: does the model live up to at least a subset of it? So I think this is really good to have a proof point like this. I mean very good.

G

Yeah yeah, so this is doing not a lot of, let's say the validation stuff in contact with the v-net at this moment. So we can use a starting point and then update it. You know, but for the beginning we can use it for sure with.

I

These cases be submitted to the side, dash branch or are these kind of offline right now.

G

No it's offline right now, so we are planning to upstream it.

H

The test case right yeah, the test case is uh very new and we have just tested it and uh we plan to upstream it for sure. uh We can actually um add it to our dash branch, where the rest of the ptf framework is already upstream to the dash branch. We can just upstream it there and have you take a look at it and everyone and we can enhance it together as well in the community.

I

Yeah, I think we're at a really good point here, where last night that I wanted to mention to the group we we merged my pull request for the scythrift framework for dash, and that means we're ready to we're ready to now get your dash branch of psy kind of harmonized with that. And then then we can have the best of both worlds right. We could actually pull in your psy branch into dash and use these tests, because they're already going to be part of you that repo right.

I

So we can hash out the details offline from this working group, but I think we're ready to try that next that'll be great.

A

Amazing, you guys awesome.

A

E

Yeah, I I this is prince it's it's really great, uh so yeah richmond! I have one question. So these test files right the threats test files- uh maybe I missed where you're planning to upstream, is it uh to the.

H

Side or so so yeah the final destination will be psi uh at this time. What we have is uh a separate uh uh you know, branch under dash, where we have the all the changes that we have done for the dash related changes that we have done for the auto generated uh test framework, it's already there under dash, so we can all collaborate and work on it together and you know um especially for chris's work, etc, and anyone in the community would like to use.

H

But uh as we complete that- and you know, um whenever you know, um we think that enough number of test cases are also upstream there. We can actually um bring it all into actual um into ocp sign all.

E

I

Yeah and prints to that point, um the way that the sci thrift framework is for dash right now it actually pulls in um a branch of the sci repo. It could be a fork like intel's fork, or it could be the official upstream one. It doesn't matter at any point in time. We can be using development branches like this and all that all the test cases are sucked right into the dash repo, so they can be used.

I

So um it's already kind of set up to be convenient, there's no copying or adapting it's. It's linked right in as a sub module.

H

Yeah, it's only a module.

E

So for the psy api, are we bringing in all those uh um you know the header files from the experimental directory for for this purpose.

H

I

Thanks, you showed some underlay kinds of setups like underlay routing which isn't part of the dash behavior model. So there's some there's some differences that we'll have to sort out right.

H

um uh In the sense uh behavioral model, uh but yeah for the v-net use case as well, there is some amount of routing that is needed. uh That's the part we were setting up uh in our test case that met nick has shown, um as the underlay part.

I

Yeah, probably in the behavioral model meeting we'll have to hash this out a little bit and decide how how to bridge the gap between the dash behavior model, and you know a full-blown implementation like the one you just showed.

I

So we can still run test cases. Even if we don't have say all the underlay tables.

H

Yeah sure we can discuss one sounds good.

E

So once we have verified this one on bmv2, could we make it part of the cicd process as well.

H

Yeah that was our next thing that we were going to also discuss. We have this uh discussion with chris and keysight, and uh you know the ci cd. um Maybe um if you want to show the diagram uh mithnik, it's uh it may um it may be more. You know easier to visually see how everything fits together, but definitely we have plans to uh integrate with the ci cd.

G

H

G

H

So, as you can see here, yeah.

G

So we have like the ptf or unit test framework running. This is what we should show today on the left, which is using the ptf trafficgen, but it also has the some example that chris is using, for example, pi test using the snappy. So this is what we have today, so everything and both of them can be used on the ci right chris.

G

Yes, so we can run it.

I

Yeah so we'll you could actually run snappy in the ptf test, which you know I demonstrated that over a year ago, um and so we could do flow based testing where it's more interesting to have. You know large numbers of packets, with patterns in the header, fields, etc, and then also the single packet at a time type test that ptf is excellent at and have both.

I

So I think it'll be it'll, be fun to combine these two techniques.

G

Yeah yeah, thank you.

E

A

Any other questions for today or gerald. What do you think.

E

A

I think we can give nine minutes back. That's fantastic work, freshman team! Thank you so much. Thank you. Yeah amazing.

A

Then I'll go ahead and stop the recording I'll post it.