[PATCH v6 0/2] Add l2reflect measurement application

Henning Schild henning.schild at siemens.com
Wed Sep 21 13:27:13 CEST 2022


Am Wed, 21 Sep 2022 11:43:13 +0200
schrieb Morten Brørup <mb at smartsharesystems.com>:

> > From: Felix Moessbauer [mailto:felix.moessbauer at siemens.com]
> > Sent: Friday, 2 September 2022 10.46
> > 
> > Dear DPDK community,
> > 
> > this patch provides the l2reflect measurement tool
> > which will be discussed in our 2022 DPDK Userspace Summit talk:
> > "Using DPDK OVS for deterministic low latency communication"
> > 
> > While the code still might need some polish, we believe it is
> > a good starting point for discussions about low latency networking
> > in DPDK.
> > 
> > The tool can also be used in a CI environment to contineously
> > measure latencies across the evolution of DPDK and Linux.
> > 
> > Best regards,
> > Felix Moessbauer
> > Siemens AG  
> 
> Dear Felix and Henning,
> 
> Great to meet you at the 2022 DPDK Userspace conference.
> 
> Have you considered using the Configuration Testing Protocol (CTP),
> described in chapter 8 of the Ethernet specification from 1984 [1],
> instead of your own packet format and the Local Experimental
> Ethertype?

No we have not, first time i hear about that. First type we used must
have been 0xaffe or 0xdead, would have to dig through version control.

> [1]: http://decnet.ipv7.net/docs/dundas/aa-k759b-tk.pdf
> 
> The CTP an obsolete protocol, and not part of the IEEE standards for
> Ethernet, but I think Wireshark is able to parse such packets.

Yes ... does not seem to be a train one wants to hop on.

Maybe you can explain how one would use CTP to measure roundtrip times,
and go into detail on how that would add value.

I had a quick look at the spec and did not clearly see whether the
protocol could be used at all ... maybe "abused". And being a CTP
server one would need to implement more than just "reply". And i do not
see any value, except maybe "wireshark support" ... but i am not sure
how that would add value. The packets we send are trivial, headers are
ethernet and the content does not matter ... so wireshark support is
there for all relevant fields.

regards,
Henning

> There might also be long term perspectives in building on top of a
> published (although obsolete) standard - e.g. the protocol could be
> revived and become part of the DPDK protocol library, along with LACP.
>
> On the other hand, it might limit your ability to expand the protocol.
> 
> 
> Med venlig hilsen / Kind regards,
> -Morten Brørup
> 
> 
> 



More information about the dev mailing list