From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E915C6FA82 for ; Mon, 12 Sep 2022 15:44:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229777AbiILPoF (ORCPT ); Mon, 12 Sep 2022 11:44:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbiILPoD (ORCPT ); Mon, 12 Sep 2022 11:44:03 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4E553122D for ; Mon, 12 Sep 2022 08:44:02 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id b75so3758718pfb.7 for ; Mon, 12 Sep 2022 08:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=6WJMZkqzECuNlXYrbJHIhf2Iso7gO57IGnNjoxfryjs=; b=ZgFjFJEu2lDiUaEupCyLGy9GEEo+awCHkj/NUTwFjNNDf7WvTYERs7Rf+Pao2ZEJzu +VCrWTK2P9FQULhHVUQH7SfRiL97iEhwf5eVnkpJ0LpdPSiuP3rAztdYQEaqJ3KxQtiu tU1bTmRRRp9yF0UsKEzOkEJluYiG9LmIOb/FcexDA3U66NWCFtIwzsXNzPrytGtAKTp5 JnMCPQouDlIap7j/tdbBJGk9aMGI/KO+Rfds5ZCXgNuesQEqe9HZ0SGEGXd1c+k5xWp0 S7WV3MIoavd39iW+zJjr2Gp9/VUPMWjb2WZHZPEBsfQXx/coPKg2f+E452CWgG3RpglI LlAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=6WJMZkqzECuNlXYrbJHIhf2Iso7gO57IGnNjoxfryjs=; b=Krh5eEvlgku8H/fx1kN0miZaqe5WjJhfxqOwEySx+7Um0TLmhFwblPqgLAzLda7zZz OMQJqsZgd29sJx5P9ni++sLaii9xeuauETE9HRSGictJLsqEEth4zj9bGVK5hva8pxBz V6U+rBcuMHnbUoP0sGzvdJ0j0WI2ZG8g3Qy/6nHOi4sU1G1SHQFQvY82aFRSltPcRPm1 Qax+4gyKfzoziY/eLmLUEAN26D23OgETrUvZGf3NLD6KXf4rq/wUbHzbAbKI29YIov6e sStcUpiOmiQ9j1VuwvkFbap6NqbFFBi4Bk/GZI65I/3Pwk3pTMVO4F7BBs0jlZwxq2wm 7MDg== X-Gm-Message-State: ACgBeo0v7gVhLDKJIWesoYMkFAaboyUcRmj0odcZgobfpTOSe9ncViQU NT/fsS2HaSjMYPltNy4H9Gw= X-Google-Smtp-Source: AA6agR58BIZpMZAKNJB61PSPcMHEAUUDWKhD4JbjMpGkhAtk9ZadRNW2Aqy2ne+RYrCWGmSvSzhkiw== X-Received: by 2002:a63:106:0:b0:430:805a:f1ad with SMTP id 6-20020a630106000000b00430805af1admr23674176pgb.284.1662997441983; Mon, 12 Sep 2022 08:44:01 -0700 (PDT) Received: from hoboy.vegasvil.org ([2601:640:8200:33:e2d5:5eff:fea5:802f]) by smtp.gmail.com with ESMTPSA id n18-20020a170903111200b00174d4fabe76sm6165000plh.214.2022.09.12.08.44.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Sep 2022 08:44:01 -0700 (PDT) Date: Mon, 12 Sep 2022 08:43:59 -0700 From: Richard Cochran To: Lasse Johnsen Cc: netdev@vger.kernel.org, Tony Nguyen , Jesse Brandeburg , "Stanton, Kevin B" , Jonathan Lemon Subject: Re: [PATCH net-next 1/1] igc: ptp: Add 1-step functionality to igc driver Message-ID: References: <448285BC-C58E-475C-BAA2-001501503D6C@timebeat.app> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448285BC-C58E-475C-BAA2-001501503D6C@timebeat.app> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, Sep 10, 2022 at 04:07:48PM +0100, Lasse Johnsen wrote: > Would you be amenable to an addition to the API so we can take advantage of > hardware that offers only a subset of the options? I think that is only user friendly option. However, the question is whether this would find broad use, or would it remain an isolated hack for one borken hardware design? > We could for example extend granularity of the HWTSTAMP TX API to make requests > for different features visible to the user space applications directly. So the TX side > would become much more granular as is already the case with the RX side. We could > add HWTSTAMP_TX_ONESTEP_SYNC_L2_V2, HWTSTAMP_TX_ONESTEP_SYNC_L4_V2 etc. > > My worry is that if we do not do this, then the ONESTEP option will continue > to not see much use because so many permutations (L2, UDPv4, UDPv6, V1, V2, VLAN etc.) > currently have to be supported by the hardware. Actually IMO the opposite is true. If the API nickel and dimes every last combination then: - that will only encourage even more broken hardware designs - no user space software will implement the combos Case in point: /* PTP v1, UDP, any kind of event packet */ HWTSTAMP_FILTER_PTP_V1_L4_EVENT, /* PTP v1, UDP, Sync packet */ HWTSTAMP_FILTER_PTP_V1_L4_SYNC, /* PTP v1, UDP, Delay_req packet */ HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ, /* PTP v2, UDP, any kind of event packet */ HWTSTAMP_FILTER_PTP_V2_L4_EVENT, /* PTP v2, UDP, Sync packet */ HWTSTAMP_FILTER_PTP_V2_L4_SYNC, /* PTP v2, UDP, Delay_req packet */ HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ, /* 802.AS1, Ethernet, any kind of event packet */ HWTSTAMP_FILTER_PTP_V2_L2_EVENT, /* 802.AS1, Ethernet, Sync packet */ HWTSTAMP_FILTER_PTP_V2_L2_SYNC, /* 802.AS1, Ethernet, Delay_req packet */ HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ, This monstrosity came about because of ONE early, brain dead HW design. Seriously, who would ever want to have just "PTP v1, UDP, Delay_req packet" and not the other event messages? This horrible API is now written in stone, but never, ever used. If hardware claims to implement PTP one-step, then it really should do so in a way that conforms to the published standards. Thanks, Richard