[PATCH v3 0/2] ethdev: add the check for PTP capability

[lihuisong (C)]

Hi Ferruh,

在 2023/11/23 19:56, lihuisong (C) 写道:
>
> 在 2023/11/2 7:39, Ferruh Yigit 写道:
>> timesync_read_rx_timestamp
>> On 9/21/2023 12:59 PM, lihuisong (C) wrote:
>>> add ice & igc maintainers
>>>
>>> 在 2023/9/21 19:06, Ferruh Yigit 写道:
>>>> On 9/21/2023 11:02 AM, lihuisong (C) wrote:
>>>>> Hi Ferruh,
>>>>>
>>>>> Sorry for my delay reply because of taking a look at all PMDs
>>>>> implementation.
>>>>>
>>>>>
>>>>> 在 2023/9/16 1:46, Ferruh Yigit 写道:
>>>>>> On 8/17/2023 9:42 AM, Huisong Li wrote:
>>>>>>>    From the first version of ptpclient, it seems that this example
>>>>>>> assume that
>>>>>>> the PMDs support the PTP feature and enable PTP by default. 
>>>>>>> Please see
>>>>>>> commit ab129e9065a5 ("examples/ptpclient: add minimal PTP client")
>>>>>>> which are introduced in 2015.
>>>>>>>
>>>>>>> And two years later, Rx HW timestamp offload was introduced to
>>>>>>> enable or
>>>>>>> disable PTP feature in HW via rte_eth_rxmode. Please see
>>>>>>> commit 42ffc45aa340 ("ethdev: add Rx HW timestamp capability").
>>>>>>>
>>>>>> Hi Huisong,
>>>>>>
>>>>>> As far as I know this offload is not for PTP.
>>>>>> PTP and TIMESTAMP are different.
>>>>> If TIMESTAMP offload cannot stand for PTP, we may need to add one new
>>>>> offlaod for PTP.
>>>>>
>>>> Can you please detail what is "PTP offload"?
>>>>
>>> It indicates whether the device supports PTP or enable  PTP feature.
>>>
>> We have 'rte_eth_timesync_enable()' and 'rte_eth_timesync_disable()'
>> APIs to control PTP support.
> No, this is just to control it.
> we still need to like a device capablity to report application if the 
> port support to call this API, right?
>>
>> But when mention from "offload", it is something device itself does.
>>
>> PTP is a protocol (IEEE 1588), and used to synchronize clocks.
>> What I get is protocol can be parsed by networking stack and it can be
>> used by application to synchronize clock.
>>
>> When you are refer to "PTP offload", does it mean device (NIC)
>> understands the protocol and parse it to synchronize device clock with
>> other devices?
> Good point. PTP offload is unreasonable.
> But the capablity is required indeed.
> What do you think of introducing a RTE_ETH_DEV_PTP in 
> dev->data->dev_flags for PTP feature?

Can you take a look at this discussion line again?

Let's introduce a  RTE_ETH_DEV_PTP in dev->data->dev_flags to reveal if 
the device support PTP feature.

>>
>>
>> We have 'rte_eth_timesync_*()' APIs, my understanding is application
>> parses the PTP protocol, and it may use this information to configure
>> NIC to synchronize its clock, but it may also use PTP provided
>> information to sync any other clock. Is this understanding correct?
>>
>>
>>> If TIMESTAMP offload is not for PTP, I don't know what the point of 
>>> this
>>> offload independent existence is.
>>>
>> TIMESTAMP offload request device to add timestamp to mbuf in ingress,
>> and use mbuf timestamp to schedule packet for egress.
> Agree.
>>
>> Technically this time-stamping can be done by driver, but if offload
>> set, HW timestamp is used for it.
>>
>> Rx timestamp can be used for various reasons, like debugging and
>> performance/latency analyses, etc..
>>
>>
>>>>>> PTP is a protocol for time sync.
>>>>>> Rx TIMESTAMP offload is to ask HW to add timestamp to mbuf.
>>>>> Yes.
>>>>> But a lot of PMDs actually depand on HW to report Rx timestamp 
>>>>> releated
>>>>> information
>>>>> because of reading Rx timestamp of PTP SYNC packet in 
>>>>> read_rx_timestamp
>>>>> API.
>>>>>
>>>> HW support may be required for PTP but this doesn't mean timestamp
>>>> offload is used.
>>> understand.
>>>>>>> And then about four years later, ptpclient enable Rx timestamp 
>>>>>>> offload
>>>>>>> because some PMDs require this offload to enable. Please see
>>>>>>> commit 7a04a4f67dca ("examples/ptpclient: enable Rx timestamp
>>>>>>> offload").
>>>>>>>
>>>>>> dpaa2 seems using TIMESTAMP offload and PTP together, hence they
>>>>>> updated
>>>>>> ptpclient sample to set TIMESTAMP offload.
>>>>> There are many PMDs doing like this, such as ice, igc, cnxk, 
>>>>> dpaa2, hns3
>>>>> and so on.
>>>>>
>>>> Can you please point the ice & igc code, cc'ing their maintainers, we
>>>> can look together?
>>> *-->igc code:*
>>>
>>> Having following codes in igc_recv_scattered_pkts():
>>>
>>>          if (rxq->offloads & RTE_ETH_RX_OFFLOAD_TIMESTAMP) {
>>>              uint32_t *ts = rte_pktmbuf_mtod_offset(first_seg,
>>>                      uint32_t *, -IGC_TS_HDR_LEN);
>>>              rxq->rx_timestamp = (uint64_t)ts[3] * NSEC_PER_SEC +
>>>                      ts[2];
>>>              rxm->timesync = rxq->queue_id;
>>>          }
>>> Note：this rxm->timesync will be used in timesync_read_rx_timestamp()
>>>
>> Above code requires TIMESTAMP offload to set timesync, but this
>> shouldn't be a requirement. Usage seems mixed.
>>
>>> *-->ice code:*
>>>
>>> #ifndef RTE_LIBRTE_ICE_16BYTE_RX_DESC
>>>          if (ice_timestamp_dynflag > 0 &&
>>>              (rxq->offloads & RTE_ETH_RX_OFFLOAD_TIMESTAMP)) {
>>>              rxq->time_high =
>>>                 rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high);
>>>              if (unlikely(is_tsinit)) {
>>>                  ts_ns = ice_tstamp_convert_32b_64b(hw, ad, 1,
>>> rxq->time_high);
>>>                  rxq->hw_time_low = (uint32_t)ts_ns;
>>>                  rxq->hw_time_high = (uint32_t)(ts_ns >> 32);
>>>                  is_tsinit = false;
>>>              } else {
>>>                  if (rxq->time_high < rxq->hw_time_low)
>>>                      rxq->hw_time_high += 1;
>>>                  ts_ns = (uint64_t)rxq->hw_time_high << 32 | 
>>> rxq->time_high;
>>>                  rxq->hw_time_low = rxq->time_high;
>>>              }
>>>              rxq->hw_time_update = rte_get_timer_cycles() /
>>>                           (rte_get_timer_hz() / 1000);
>>>              *RTE_MBUF_DYNFIELD(rxm,
>>>                         (ice_timestamp_dynfield_offset),
>>>                         rte_mbuf_timestamp_t *) = ts_ns;
>>>              pkt_flags |= ice_timestamp_dynflag;
>>>          }
>>>
>>>          if (ad->ptp_ena && ((rxm->packet_type & RTE_PTYPE_L2_MASK) ==
>>>              RTE_PTYPE_L2_ETHER_TIMESYNC)) {
>>>              rxq->time_high =
>>>                 rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high);
>>>              rxm->timesync = rxq->queue_id;
>>>              pkt_flags |= RTE_MBUF_F_RX_IEEE1588_PTP;
>>>          }
>>> #endif
>>>
>>> Note: rxm->timesync and rxq->time_high will be used in
>>> timesync_read_rx_timestamp()
>>>
>> This usage looks good, if TIMESTAMP offload enabled mbuf dynamic field
>> and flag set accordingly.
> hns3 also implemented PTP as ice did.
>>
>> And if PTP enabled, and PTP packet type detected relevant flag set in
>> mbuf, and timesyc value set to use later for 
>> 'timesync_read_rx_timestamp()'.
> Yes.
>>
>>
>> Although above usage looks correct, I can see in 'ice_timesync_enable()'
>> TIMESTAMP offload is used requirement to enable timesync.
>> TIMESTAMP offload seems used as way to enable HW timestamp, as Hemant
>> mentioned what is done is dpaa2.
>>
>>
>>>>
>>>>>> We need to clarify dpaa2 usage.
>>>>>>
>>>>>>> By all the records, this is more like a process of perfecting PTP
>>>>>>> feature.
>>>>>>> Not all network adaptors support PTP feature. So adding the 
>>>>>>> check for
>>>>>>> PTP
>>>>>>> capability in ethdev layer is necessary.
>>>>>>>
>>>>>> Nope, as PTP (IEEE1588/802.1AS) implemented as dev_ops, and ops 
>>>>>> already
>>>>>> checked, so no additional check is needed.
>>>>> But only having dev_ops about PTP doesn't satisfy the use of this
>>>>> feature.
>>>>> For example,
>>>>> there are serveal network ports belonged to a driver on one OS, 
>>>>> and only
>>>>> one port support PTP function.
>>>>> So driver needs one *PTP* offload.
>>>>>> We just need to clarify TIMESTAMP offload and PTP usage and find out
>>>>>> what is causing confusion.
>>>>> Yes it is a little bit confusion.
>>>>> There are two kinds of implementation:
>>>>> A： ixgbe and txgbe (it seems that their HW is similar) don't need
>>>>> TIMESTAMP offload，and only use dev_ops to finish PTP feature.
>>>>> B:  saving "Rx timestamp related information" from Rx description 
>>>>> when
>>>>> receive PTP SYNC packet and
>>>>>       report it in read_rx_timestamp API.
>>>>> For case B, most of driver use TIMESTAMP offload to decide if driver
>>>>> save "Rx timestamp related information.
>>>>> What do you think about this, Ferruh?
>>>>>> I would be great if you can help on clarification, and update
>>>>>> documentation or API comments, or what ever required, for this.
>>>>> ok
>>>>>>> ---
>>>>>>> v3:
>>>>>>>     - patch [2/3] for hns3 has been applied and so remove it.
>>>>>>>     - ops pointer check is closer to usage.
>>>>>>>
>>>>>>> Huisong Li (2):
>>>>>>>      examples/ptpclient: add the check for PTP capability
>>>>>>>      ethdev: add the check for the valitity of timestamp offload
>>>>>>>
>>>>>>>     examples/ptpclient/ptpclient.c |  5 +++
>>>>>>>     lib/ethdev/rte_ethdev.c        | 57
>>>>>>> +++++++++++++++++++++++++++++++++-
>>>>>>>     2 files changed, 61 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>> .
>>>> .
>> .
>
> .