Rare project developers

[mc36 <>]

if you have spare 10 minutes, what if i show you in a vc that how these tests 
executed?
https://letsmeet.hu/alex


On 2/25/22 11:12, Alexander Gall wrote:
> Hi
>
> On Fri, 25 Feb 2022 10:31:00 +0100, mc36 <> said:
>
> > still interesting questions....
> > so let's assume for now if we drop the portid thingy completely from the 
> > export-port stanzas....
> > for this to happen, we have to use the sdn--portname mapping from the 
> > dataplanes...
> > then p4lang server loses the possibility to validate the config before the 
> > dataplane connects in....
>
> Not sure what you mean. The ID is still there, either the way it is
> now (physical port ID determined by the user) or replaced by a more
> user-friendly identifier (e.g. "1/0" for the Tofino DP) which is
> translated to the physical ID automatically. What kind of validation
> is no longer possible?
>
> > right now i see it making life harder to test the dataplanes indepently.. 
> > right now i have several
> > dataplane vms that use portid0..3 and the tests written for them using the 
> > portid mapping...
> > if we drop the portid stuff, it'll make testing almost impossible because
> > tofino reports X/0, bmv2 reports bmv2-portX, xdp reports xdp-portX,
> > p4pcap reports enoX, and p4dpdk reports 0000:0X.0...
> > so one cannot write a common test case for all the dataplanes....
>
> You really lost me here since I'm not familiar with how your test
> cases work. Can you please elaborate?  I don't see how what I'm
> proposing has any effect on this in case of the Tofino DP. The only
> things that would change are
>
>     * The user can use meaningful names in "export-port" for physical
>       ports, e.g. "1/0"
>
>     * The user doesn't have to create "export-port" stanzas for
>       sub-interfaces explicitely
>
> How would this change the output of your test cases?
>
> > the same issue will appear if you swap the p4pcap and p4dpdk dataplanes
> > on a physical box... (they are normally fully interchangeable!)
>
> I agree that would be bad but I don't unserstand why this would
> happen.
>
> > regarding subinterfaces and the dynamic port range, it's not impossible to 
> > achieve,
> > the only missing part here is the dataplanes need to report the available 
> > subinterface
> > id range they can accommodate without confusing them to physical port ids...
>
> Correct, but that would actually be a good thing, IMHO. For example,
> the counters for VLANs are currently arranged in an array indexed by
> the number space shared by the pseudo-port and physical-port IDs but
> only the indexes corresponding to pseudo-ports will ever be used. I.e
> we're wasting hundreds of counters. What we should do is to define how
> many VLANs we're supporting in the HW, which would determine how large
> that array is and how many pseudo-ports freerouter can use to assign
> to sub-interfaces for the Tofino DP.