RE: [PATCH 0/1] net/drivers: igc: introduce rt_igc driver

["Chen, Hongzhan" <hongzhan.chen@intel.com>]

>-----Original Message-----
>From: Jan Kiszka <jan.kiszka@web.de> 
>Sent: Saturday, August 27, 2022 12:27 AM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@lists.linux.dev
>Subject: Re: [PATCH 0/1] net/drivers: igc: introduce rt_igc driver
>
>On 22.08.22 03:18, Hongzhan Chen wrote:
>> ported basic network functions not including TSN.
>>
>> 1. passed three network related smokey test: UDP, raw, dgram, But
>>    I do not know if these three test is enough to validate the
>>    driver, please let me know if there is other tests need to
>>    cover.
>
>If those tests exchanged more than a hand-full of packets (to make sure
>we are not leaking buffers, thus will run out of resources after a
>while) and if you checked that the reported latency is comparable to

I setup two environements to do rt_igc validation listed in [1]. I also setup [2] environment
to compare performance with i210. All three smokey tests( UDP, DGRM, RAW)
had passed 72 hours long time test in [1].B. In environment [1].B, the latency 
is about 60us better than 120 us latency got in [2] in UDP smokey test.

[1]:

A: I225<--->switch <--> I210

B: I225<--->I225

[2]:

C: I210<--> I210

>rt_igb e.g., then we have a good indication that the driver works. The
>rest is field-testing.
>
>> 2. In addtion, another thing I want to discuss here is TSN functions of
>>    i225 has the very similiar effect with TDMA not only from clock sync,
>>    master and slave arch, timing mangement but the difference for TSN is
>>    that most of fucntions is implemented by hardware. We are considering
>>    if it is feasible to implement TSN-enabled TDMA-TSN driver to make
>>    use of i225 hardware feature because TDMA itself is really heavy.
>
>Yeah, time-triggered send is basically what RTmac/TDMA introduced via
>software almost two decades ago. I'm not sure, though, if we should map
>the configuration of TSN capabilities of modern hardware on interfaces
>(RTmac & Co.) that were designed that long ago. If it happens to work
>our easily, it's a nice experiment, but we would likely miss other
>things (Qbv transmission windows e.g.). And there is also the question
>how to set up an operate PTP aside RTnet.  

Yes, PTP would be a hard topic.
In addition, the TSN reference application I refer to  would use socket option for example
 SO_TIMSSTAMPING but rtnet  does not support. It also use vlan to differentiate priority 
for different steams but rtnet does not support vlan.
TSN may make use of two more NIC queues to dispatch packets to guarantee deterministic
for higher priority packet but rtnet do not have scheme to do related mapping or scheduler to 
two more queues... 

Regards

Hongzhan Chen
>
>Jan
>
>
>
>
>
>