Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp198258lfo; Tue, 17 May 2022 22:10:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxV5gSDbIwoPkv9sk05Ik7rYcPlNTHdv2QPZTUPA92B/bWjrUHKuEWQMUkasLD95eZrgD1A X-Received: by 2002:a17:90b:4a08:b0:1dc:6cc1:3d24 with SMTP id kk8-20020a17090b4a0800b001dc6cc13d24mr28811352pjb.131.1652850646829; Tue, 17 May 2022 22:10:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652850646; cv=none; d=google.com; s=arc-20160816; b=08U87S4Em+6ClACzPjlmzI3TMH6qk/yWsaXE+cRDnupRKjux3Ii3kzbpl9KgwENNT3 Ad5alXYd7fT1JIfoCUwdNGSrf5IAM0I/+CtY3+lBo7q9POV+oNPEA4oR98p8uAyBlQJl +ZEdliwMcbdDQVzWdansHHRMXdfLvSvyInAdCgt+sXsEjzk1jeg2JeCcWO2A2sc97qB9 g+ogNrf5OiVV6Kfp/VMWqrXgSb2Byl4f4AyqqJsLwNjsTx48G9W/MZuH5OhcTp7ZIQH0 5VxgwvPNz8Pft2OD9DXeLnuxxbecxfs2amLp1o8tqOVYG1HGjU0zfJbnmhhR0IvWd3GD WSfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=76dv2VpjMRgZPVQFYZ0FWzLo+rlCzcsp4h55jthexNg=; b=yaQS/xDrtEIpilxo2SvXZTaoefZU7iNEMbQ48/0Rg0ZS6lipdsHZcJgnSsd+xDl4HF xj6bznLzTgL6+IRtGsyxW5mYzUHY7xRrlLRsVb21gxLUlWnIObx7C85ppirjR40rQHfG 5f2s/bCFt9ZOUYax62prk2gL2aMg5c571Kh0na4smL13Q0sz59MGbujvjTeYkyvTWADF 8q1TJY00tUeEsXSzpD/nxzuXTvs1E5OmLGb8HI079cg1q/EIYnv/B93zykMGOmoQWkxD 12nP80254AedJbdJ2MZ611lLjodddXeofjqhyTstkZe8uNFh3LI9OjyLyw9hiDx9Swa7 yXaw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xilinx.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q11-20020a635c0b000000b003c6b30be1d1si1139808pgb.574.2022.05.17.22.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 22:10:46 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xilinx.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E9F322EA21; Tue, 17 May 2022 21:23:54 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229794AbiEREXp (ORCPT + 99 others); Wed, 18 May 2022 00:23:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229677AbiEREXn (ORCPT ); Wed, 18 May 2022 00:23:43 -0400 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD68E2E9E0; Tue, 17 May 2022 21:23:42 -0700 (PDT) Received: by mail-wm1-f48.google.com with SMTP id l38-20020a05600c1d2600b00395b809dfbaso360582wms.2; Tue, 17 May 2022 21:23:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=76dv2VpjMRgZPVQFYZ0FWzLo+rlCzcsp4h55jthexNg=; b=MZ+xMMXjoDM9tgU9uaFNDeT8Uulqcj7rQAZoQZrtUemDhZQtPB+O5NzuoQ5Ok1VxqV T0nQHqAT+Vt3JWpFgGND3UjcIF4TOu7znNHIUxjPBxypjC78KTqL7YsxpRqWpWQd6rIJ 34W9ljB67V+l7Xj99pwnIh2UVO0aXwKPl3cTjV5bNYsg8xHBZMrmpR9BNIa0O6BNQoJ6 TTqiKUN4NUchdF0OJmvmSANMhbKOYzlrBkB3eAcqmzGa3bp9Kl3ERkO4+C0nE2aHJ4SQ /A4HPqxIVeMrN9DR+t1pSduRI7WjPo0bMuBMPvlmwR/3Cin+OMMx4BC1vLCYr6IYX7h2 LIQQ== X-Gm-Message-State: AOAM530UwSGlk0CCJaoaSmyYXybai9kR9XtnPTiVikLUxTlLRRHQnVe/ 0J/j0QIjkpQbtpJ99xKPcrpu7oNEYZusuUgeRDk= X-Received: by 2002:a05:600c:1c84:b0:394:5de0:245e with SMTP id k4-20020a05600c1c8400b003945de0245emr35217055wms.32.1652847821016; Tue, 17 May 2022 21:23:41 -0700 (PDT) MIME-Version: 1.0 References: <20220517073259.23476-1-harini.katakam@xilinx.com> <20220517073259.23476-2-harini.katakam@xilinx.com> <20220517194254.015e87f3@kernel.org> In-Reply-To: <20220517194254.015e87f3@kernel.org> From: Harini Katakam Date: Wed, 18 May 2022 09:53:29 +0530 Message-ID: Subject: Re: [PATCH 1/3] net: macb: Fix PTP one step sync support To: Jakub Kicinski Cc: Harini Katakam , Nicolas Ferre , David Miller , Richard Cochran , Claudiu Beznea , Paolo Abeni , netdev , Linux Kernel Mailing List , Michal Simek , Radhey Shyam Pandey Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jakub, On Wed, May 18, 2022 at 8:12 AM Jakub Kicinski wrote: > > On Tue, 17 May 2022 13:02:57 +0530 Harini Katakam wrote: > > PTP one step sync packets cannot have CSUM padding and insertion in > > SW since time stamp is inserted on the fly by HW. > > In addition, ptp4l version 3.0 and above report an error when skb > > timestamps are reported for packets that not processed for TX TS > > after transmission. > > Add a helper to identify PTP one step sync and fix the above two > > errors. > > Also reset ptp OSS bit when one step is not selected. > > > > Fixes: ab91f0a9b5f4 ("net: macb: Add hardware PTP support") > > Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation") > > Please make sure to CC authors of the patches under fixes. > ./scripts/get_maintainer should point them out. Thanks for the review. Rafal Ozieblo is the author of the first Fixes patch but that address hasn't worked in the last ~4 yrs. I have cced Claudiu and everyone else from the maintainers (Eric Dumazet also doesn't work) > > +/* IEEE1588 PTP flag field values */ > > +#define PTP_FLAG_TWOSTEP 0x2 > > Shouldn't this go into the PTP header? Let me add it to ptp_classify where the relevant helpers are present. > > +static inline bool ptp_oss(struct sk_buff *skb) > > Please spell out then name more oss == open source software. Will change to ptp_one_step_sync > > No inline here, please, let the compiler decide if the function is > small enough. One step timestamp may be a rare use case so inlining > this twice is not necessarily the right choice. One step is a rare case but the check happens on every PTP packet in the transmit data path and hence I wanted to explicitly inline it. > > @@ -1158,13 +1192,14 @@ static int macb_tx_complete(struct macb_queue *queue, int budget) > > > > /* First, update TX stats if needed */ > > if (skb) { > > - if (unlikely(skb_shinfo(skb)->tx_flags & > > - SKBTX_HW_TSTAMP) && > > - gem_ptp_do_txstamp(queue, skb, desc) == 0) { > > - /* skb now belongs to timestamp buffer > > - * and will be removed later > > - */ > > - tx_skb->skb = NULL; > > + if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) && > > ptp_oss already checks if HW_TSTAMP is set. The check for SKBTX_HW_TSTAMP is required here universally and not just inside ptp_oss. I will remove the redundant check in ptp_oss instead. Please see the reply below. > > > + !ptp_oss(skb)) { > > + if (gem_ptp_do_txstamp(queue, skb, desc) == 0) { > > Why convert the gem_ptp_do_txstamp check from a && in the condition to > a separate if? The intention is that ptp_oss should only be evaluated when SKBTX_HW_TSTAMP is set and gem_ptp_do_txstamp should only be called if ptp_oss is false. Since compiler follows the order of evaluation, I'll simplify this to: if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) && !ptp_oss(skb) && gem_ptp_do_txstamp(queue, skb, desc) == 0) { ... } Regards, Harini