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

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

>-----Original Message-----
>From: Jan Kiszka <jan.kiszka@siemens.com>
>Sent: Monday, September 5, 2022 8:00 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; Jan Kiszka
><jan.kiszka@web.de>; xenomai@lists.linux.dev
>Subject: Re: [PATCH 0/1] net/drivers: igc: introduce rt_igc driver
>
>On 31.08.22 10:24, Chen, Hongzhan wrote:
>>
>>
>>> -----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
>>
>
>OK, looks good.
>
>One follow-up question: I've just spotted those hw semaphore functions.
>None of them is every called from RT task or even RT interrupt context,
>did you check that carefully?

In IGC, the hw semaphore is just to protect accessing PHY or NVM related registers,  will be encapsulated
in phy or nvm related operations but not directly called or used by RT task or RT interrupt context.

Regards

Hongzhan Chen
>
>>> 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...
>
>Yeah, there is quite a bit of fundamental work ahead if we want to
>enable that. Right now, RTnet is "all or nothing" of the card. Do we
>have SR-IOV here, and could that help? I'm thinking of handing out only
>a VF to an RTnet driver and configure everything that is needed to run
>that VF with deterministic traffic on the PF during setup.
>
>Jan
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux