inbound_routing scale

I have some questions about the inbound_routing table.
This is basically a follow-on to #194

Can we double check that eni_id is a key field to the inbound_routing table?
The documentation below refers only to the VNI and the SIP prefix:
https://github.com/Azure/DASH/blob/main/documentation/general/dash-sonic-hld.md#22-inbound-packet-processing-pipeline

(I believe that multiple ENIs can be in the same VNET, and thus use the same VNI.
If so, then the inbound routing table needs to have a duplicate entry for each such ENI.
In the worst case, all 64 ENIs could be in the same VNET, requiring many duplicated entries.)

I’m trying to understand the sizing requirements for the inbound_routing table.
There are a couple parts here and I’m not sure how they all fit in.

I recall a meeting where it was stated that the pa_validation table has the same scale as the mapping table –
10 million entries. Is the inbound_routing table the same scale?

It was stated in #194 that the SIP key of the inbound_routing table
was definitely ternary, not lpm. Are we required to support millions of TCAM entries for this table?

It was also stated in the doc that the SIP prefix is optional, and is needed to differentiate between vnets
that happen to have the same VNI. How often does this happen? In other words, how many inbound_routing
table entries are expected to specify a SIP prefix? Is it mostly all of the entries, hardly any, not known, etc.

When a SIP prefix is specified for an VNI, is it typically used to distinguish between two vnets?
Or between a small number of vent, or an unlimited number of vnets?

Good question! I was also trying to run VNET Inbound routing test from the PR #231 and noticed the error on inbound routing create:
[bmv2] [E] [thread 15] [P4Runtime] Invalid match type

Plus after a closer look at PR #194 we found another issue:
In the pipeline, inbound_routing is applied right after choosing a direction with direction_lookup. We don’t have any ENI associated with the packet at this stage. And the packet eventually would be dropped, no matter what we configured.

Now we have a test. So we should fix either pipeline or the test scenario.

@prsunny

Hi @prsunny and @marian-pritsak this is a blocker to develop tests for vnet_in. For some initial tests, the scale issues which @budgrise raised are less important than the functional issues @anton7811 raised in #233 (comment). Any help would be welcome.

@marian-pritsak

Added to Behavioral Model queue for review- ENI lookup seems to happen out of process? @marian-pritsak to take a look.
@anton7811 - do you have a specific test case to provide to marian?

Confirmed ENI lookup is after inbound-routing. Needs to be fixed in bmv2.

Inbound routing rules can be a maximum of 1k, but, on an average, it would be around ~100.

@marian-pritsak

@marian-pritsak I'll share with you tests how to validate inbound routing create once Chris's PR #281 is merged. Without this PR any PTF test will fail. So please take a look at that PR and comment/approve. Thank you!

@marian-pritsak

@marian-pritsak I've created a branch for testing this issue. Here is the link. It includes all necessary changes from the Chris's branch. Use standard procedure to run the tests. But instead of make run-all-tests do the following:

make run-saithrift-client-bash
cd ptf
./run-saithrift-ptftests.sh saidasheni

So far all tests should pass. By default inbound routing entry is commented out.

Now uncomment line 52 and run specifically create-delete test:

./run-saithrift-ptftests.sh saidasheni.CreateDeleteEniTest

In the switch tab you'll see the error I mentioned:

[04:57:51.621] [bmv2] [E] [thread 17] [P4Runtime] Invalid match type

Additionally you can run one more test to verify the fix - scale test. Uncomment lines 887-890 and run:

./run-saithrift-ptftests.sh saidasheni.EniScaleTest

NOTE: If possible, please take a look at get attributes and delete tests (lines 57-64).

@prsunny

Seems that queries were answered on the thread.
Can we close issue? @prsunny @marian-pritsak @budgrise

Hi, There is still a failure during bmv2 testing. This bug is unresolved. The PTF test is skipped (for example, see

DASH/test/test-cases/functional/ptf/saidasheni.py

Line 56 in aff7eae

if not test_param_get('target') == 'bmv2':

) and we will have to skip it during some SAI-Challenger DASH API tests we're writing for draft PR #301

Incorporated changes from feedback from community

any update on this ? for me is still not working

Adding SAI api tests for CRUD operation (#301)

@anton7811

Let's consider closing based on first and moving second part to its own issue.
@anton7811

Scaling question is resolved.
And a new issue #345 is opened to track the issue with inbound routing entry.

Navigation Menu

Repository navigation

inbound_routing scale #233

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

inbound_routing scale #233

Description

Activity

anton7811 commented on Sep 23, 2022

chrispsommers commented on Sep 23, 2022

KrisNey-MSFT commented on Sep 28, 2022

prsunny commented on Sep 29, 2022

aputriax commented on Nov 14, 2022

aputriax commented on Nov 15, 2022

yusefMS06 commented on Nov 16, 2022

2 remaining items

chrispsommers commented on Jan 13, 2023

mgheorghe commented on Jan 27, 2023

yusefMS06 commented on Feb 15, 2023

aputriax commented on Feb 17, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions