[P4-Apps] 2/23 meeting notes

Skip to first unread message

Lee, Jeongkeun

Feb 24, 2021, 7:38:30 PM2/24/21
to p4-...@lists.p4.org

Attendees: Rajshekhar B. (Arista), Ramesh S. (Cisco), Mickey S. (Intel, Barefoot),  JK L. (Intel, E2E App).

1. update on the opensource hosting

JK updated the group with the plan to host two types of p4 opensource projects: 1) active projects with continuous dev and 2) mature projects that can serve as a reference program, part of p4 library. SwitchML and NDP are two running examples. Guidelines for each type of hosting will be posted to the github.

2. Review Raj's proposal on drop reason structure, derived from SAI.

Proposal: https://docs.google.com/document/d/1u-9ra4fL592MEzxJHD_z9uSLZfoBT5mIaoCy5rWIglg/edit

Mickey pointed out several corner cases such as 1) detailed sub drop reasons (SMAC invalid: mcast or bcast) specific to implementation, and 2) the case where a reason belongs to two categories (unallowed SMAC but in inner: L2 as well as tunnel). We will capture them in the gdoc.

Raj's list has two columns: code point, reason name (string), and comments/meanings.

The group discussed the level of supports required by each implementation. We agreed that the spec

1) would NOT mandate all those drop reasons supported by an implementation

2) but if a device implements a selected subset of the reasons, adhere to the string names and their associated meanings

3) code points (numeric values) are recommended but not mandated, due to some existing implementation(s) has hard coded values. 

We realized that the tight coupling of name-meaning and the loose coupling of codepoint-name are similar to what we want to achieve with INT metadata instructions. We decided to settle down the YANG model change for the metadata handling and apply the same infra to handle drop reasons, using Raj's updated list as a basis.

3. YANG model for flexible metadata instruction and reason code mgmt

Mickey briefed through the current model and discussed the new requirements to address. For the names, we need to introduce enum or string types. And it currently uses OpenConfig style to distinguish config vs state, e.g., some units might be configurable as well as a readable state. We will continue this topic in the next meeting.



Reply all
Reply to author
0 new messages