Message-ID: <4d9aeb50-e8df-369a-7e3d-87ff9ba86079@ti.com>
Date:   Wed, 5 Aug 2020 15:59:46 +0300
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Kurt Kanzenbach <kurt@...utronix.de>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
CC:     Petr Machata <petrm@...lanox.com>,
        Richard Cochran <richardcochran@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>,
        Samuel Zou <zou_wei@...wei.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 1/9] ptp: Add generic ptp v2 header parsing function



On 05/08/2020 12:29, Kurt Kanzenbach wrote:
> On Wed Aug 05 2020, Russell King - ARM Linux admin wrote:
>> On Wed, Aug 05, 2020 at 01:04:31AM +0300, Grygorii Strashko wrote:
>>> On 05/08/2020 00:44, Russell King - ARM Linux admin wrote:
>>>> On Wed, Aug 05, 2020 at 12:34:47AM +0300, Grygorii Strashko wrote:
>>>>> On 05/08/2020 00:07, Russell King - ARM Linux admin wrote:
>>>>>> On Tue, Aug 04, 2020 at 11:56:12PM +0300, Grygorii Strashko wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 31/07/2020 13:06, Kurt Kanzenbach wrote:
>>>>>>>> On Thu Jul 30 2020, Petr Machata wrote:
>>>>>>>>> Kurt Kanzenbach <kurt@...utronix.de> writes:
>>>>>>>>>
>>>>>>>>>> @@ -107,6 +107,37 @@ unsigned int ptp_classify_raw(const struct sk_buff *skb)
>>>>>>>>>>      }
>>>>>>>>>>      EXPORT_SYMBOL_GPL(ptp_classify_raw);
>>>>>>>>>> +struct ptp_header *ptp_parse_header(struct sk_buff *skb, unsigned int type)
>>>>>>>>>> +{
>>>>>>>>>> +	u8 *data = skb_mac_header(skb);
>>>>>>>>>> +	u8 *ptr = data;
>>>>>>>>>
>>>>>>>>> One of the "data" and "ptr" variables is superfluous.
>>>>>>>>
>>>>>>>> Yeah. Can be shortened to u8 *ptr = skb_mac_header(skb);
>>>>>>>
>>>>>>> Actually usage of skb_mac_header(skb) breaks CPTS RX time-stamping on
>>>>>>> am571x platform PATCH 6.
>>>>>>>
>>>>>>> The CPSW RX timestamp requested after full packet put in SKB, but
>>>>>>> before calling eth_type_trans().
>>>>>>>
>>>>>>> So, skb->data pints on Eth header, but skb_mac_header() return garbage.
>>>>>>>
>>>>>>> Below diff fixes it for me.
>>>>>>
>>>>>> However, that's likely to break everyone else.
>>>>>>
>>>>>> For example, anyone calling this from the mii_timestamper rxtstamp()
>>>>>> method, the skb will have been classified with the MAC header pushed
>>>>>> and restored, so skb->data points at the network header.
>>>>>>
>>>>>> Your change means that ptp_parse_header() expects the MAC header to
>>>>>> also be pushed.
>>>>>>
>>>>>> Is it possible to adjust CPTS?
>>>>>>
>>>>>> Looking at:
>>>>>> drivers/net/ethernet/ti/cpsw.c... yes.
>>>>>> drivers/net/ethernet/ti/cpsw_new.c... yes.
>>>>>> drivers/net/ethernet/ti/netcp_core.c... unclear.
>>>>>>
>>>>>> If not, maybe cpts should remain unconverted - I don't see any reason
>>>>>> to provide a generic function for one user.
>>>>>>
>>>>>
>>>>> Could it be an option to pass "u8 *ptr" instead of "const struct sk_buff *skb" as
>>>>> input parameter to ptp_parse_header()?
>>>>
>>>> It needs to read from the buffer, and in order to do that, it needs to
>>>> validate that the buffer contains sufficient data.  So, at minimum it
>>>> needs to be a pointer and size of valid data.
>>>>
>>>> I was thinking about suggesting that as a core function, with a wrapper
>>>> for the existing interface.
>>>>
>>>
>>> Then length can be added.
>>
>> Actually, it needs more than that, because skb->data..skb->len already
>> may contain the eth header or may not.
>>
>>> Otherwise not only CPTS can't benefit from this new API, but also
>>> drivers like oki-semi/pch_gbe/pch_gbe_main.c -> pch_ptp_match()
>>
>> Again, this looks like it can be solved easily by swapping the position
>> of these two calls:
>>
>>                          pch_rx_timestamp(adapter, skb);
>>
>>                          skb->protocol = eth_type_trans(skb, netdev);

Sry, it will not be so "easily", because there is ptp_classify_raw() inside.

So every such case, will require rework and adding magic like this

	__skb_push(skb, ETH_HLEN);

	type = ptp_classify_raw(skb);

	__skb_pull(skb, ETH_HLEN);

in Hot path.

>>
>>> or have to two have two APIs (name?).
>>>
>>> ptp_parse_header1(struct sk_buff *skb, unsigned int type)
>>> {
>>> 	u8 *data = skb_mac_header(skb);
>>>
>>> ptp_parse_header2(struct sk_buff *skb, unsigned int type)
>>> {
>>> 	u8 *data = skb->data;
>>>
>>> everything else is the same.
>>
>> Actually, I really don't think we want 99% of users doing:
>>
>> 	hdr = ptp_parse_header(skb_mac_header(skb), skb->data, skb->len, type)
>>
>> or
>>
>> 	hdr = ptp_parse_header(skb_mac_header(skb), skb->data + skb->len, type);
>>
>> because that is what it will take, and this is starting to look
>> really very horrid.
> 
> True.
> 
>>
>> So, I repeat my question again: can netcp_core.c be adjusted to
>> ensure that the skb mac header field is correctly set by calling
>> eth_type_trans() prior to calling the rx hooks?  The other two
>> cpts cases look easy to change, and the oki-semi also looks the
>> same.
> 
> I think it's possible to adjust the netcp core. So, the time stamping is
> done via
> 
>   gbe_rxhook() -> gbe_rxtstamp() -> cpts_rx_timestamp()
> 
> The hooks are called in netcp_process_one_rx_packet(). So, moving
> eth_type_trans() before executing the hooks should work. Only one hook
> is registered.
> 
> What do you think about it?

I really do not want touch netcp, sry.
There are other internal code based on this even if there is only one hooks in LKML now.
+ my comment above.

I'll try use skb_reset_mac_header(skb);
As spectrum does:
  	skb_reset_mac_header(skb);
	mlxsw_sp1_ptp_got_packet(mlxsw_sp, skb, local_port, true);

if doesn't help PATCH 6 is to drop.

-- 
Best regards,
grygorii

Powered by blists - more mailing lists