From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DBF7CA0540; Thu, 7 Jul 2022 04:05:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4BDAC410D1; Thu, 7 Jul 2022 04:05:15 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id E432D406B4; Thu, 7 Jul 2022 04:05:13 +0200 (CEST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4LdfpR0KXTzkXCg; Thu, 7 Jul 2022 10:03:43 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 7 Jul 2022 10:05:11 +0800 Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 7 Jul 2022 10:05:07 +0800 Message-ID: Date: Thu, 7 Jul 2022 10:05:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v2 3/3] ethdev: add the check for the valitity of timestamp offload To: Andrew Rybchenko , Dongdong Liu , , , CC: References: <20220628133959.21381-1-liudongdong3@huawei.com> <20220702081730.1168-1-liudongdong3@huawei.com> <20220702081730.1168-4-liudongdong3@huawei.com> From: "lihuisong (C)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 在 2022/7/6 22:57, Andrew Rybchenko 写道: > On 7/2/22 11:17, Dongdong Liu wrote: >> From: Huisong Li >> >> This patch adds the check for the valitity of timestamp offload. >> >> Signed-off-by: Huisong Li >> Signed-off-by: Dongdong Liu >> --- >>   lib/ethdev/rte_ethdev.c | 65 ++++++++++++++++++++++++++++++++++++++++- >>   1 file changed, 64 insertions(+), 1 deletion(-) >> >> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c >> index 1979dc0850..9b8ba3a348 100644 >> --- a/lib/ethdev/rte_ethdev.c >> +++ b/lib/ethdev/rte_ethdev.c >> @@ -5167,15 +5167,48 @@ rte_eth_dev_set_mc_addr_list(uint16_t port_id, >>                           mc_addr_set, nb_mc_addr)); >>   } >>   +static int >> +rte_eth_timestamp_offload_valid(struct rte_eth_dev *dev) >> +{ >> +    struct rte_eth_dev_info dev_info; >> +    struct rte_eth_rxmode *rxmode; >> +    int ret; >> + >> +    ret = rte_eth_dev_info_get(dev->data->port_id, &dev_info); >> +    if (ret != 0) { >> +        RTE_ETHDEV_LOG(ERR, "Cannot get port (%u) device >> information.\n", >> +                   dev->data->port_id); >> +        return ret; >> +    } >> + >> +    if ((dev_info.rx_offload_capa & RTE_ETH_RX_OFFLOAD_TIMESTAMP) == >> 0) { > > As I understand strictly speaking the Rx offload is not the same as PTP > support. May be it is a corner case, but I can imagine case when HW > cannot provide timestamp for each packet (lack of space in extra > information associated with a packet), but can return timestamps > out-of-band using timestamp get API. > Generally speaking, Rx offload is a data plane thing and done in hardware. If hardware cannot provide timestamp for each packet, and can implement PTP only by using timestamp APIs. Can this corner case still be classified as Rx offload? If so, It is more of a control plane thing, like MTU. On the other hand, this offload is a capability obtained from driver. If driver doesn't support PTP, the ethdev layer should block them in timestamp APIs. > I have no strong opinion. May be we are not interested in the corner > case, but I think it requires acks from maintainers of all drivers > which support PTP. > >> +        RTE_ETHDEV_LOG(ERR, "Driver does not support PTP.\n"); >> +        return -ENOTSUP; >> +    } >> + >> +    rxmode = &dev->data->dev_conf.rxmode; >> +    if ((rxmode->offloads & RTE_ETH_RX_OFFLOAD_TIMESTAMP) == 0) { >> +        RTE_ETHDEV_LOG(ERR, "Please enable >> 'RTE_ETH_RX_OFFLOAD_TIMESTAMP' offload.\n"); >> +        return -EINVAL; >> +    } >> + >> +    return 0; >> +} >> + >>   int >>   rte_eth_timesync_enable(uint16_t port_id) >>   { >>       struct rte_eth_dev *dev; >> +    int ret; >>         RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); >>       dev = &rte_eth_devices[port_id]; >> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_enable, -ENOTSUP); >> +    ret = rte_eth_timestamp_offload_valid(dev); >> +    if (ret != 0) >> +        return ret; >> + > > Typically ops pointer check is done just before usage. So, it is > better to avoid adding code between check and usage. > Same in all cases below. > if there is a good reason to do so, please, explain it. A coin has two sides. Both styles exist in the ethdev layer API. There is no need to check input configuration if driver doesn't support the API. I am ok for them. > >>       return eth_err(port_id, (*dev->dev_ops->timesync_enable)(dev)); >>   } > > [snip] > .