DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Aman Singh <aman.deep.singh@intel.com>,
	Jiawen Wu <jiawenwu@trustnetic.com>,
	Jian Wang <jianwang@trustnetic.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Sachin Saxena <sachin.saxena@nxp.com>,
	Nithin Dabilpuram <ndabilpuram@marvell.com>,
	Kiran Kumar K <kirankumark@marvell.com>,
	Sunil Kumar Kori <skori@marvell.com>,
	Satha Rao <skoteshwar@marvell.com>,
	Harman Kalra <hkalra@marvell.com>,
	Huisong Li <lihuisong@huawei.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	david.marchand@redhat.com,
	Olivier MATZ <olivier.matz@dev.6wind.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: [PATCH] drivers: remove compile-time option for IEEE 1588
Date: Thu, 3 Oct 2024 23:36:40 +0100	[thread overview]
Message-ID: <300aef18-316a-420d-9b3e-a06a05d3bab2@amd.com> (raw)
In-Reply-To: <20241003121236.5c56171d@hermes.local>

On 10/3/2024 8:12 PM, Stephen Hemminger wrote:
> On Wed, 17 Apr 2024 14:24:00 +0100
> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> 
>>> :) remove compile flag in 24.11 LTS.
>>>
>>> But we may end up in same situation in 24.11, some drivers not being
>>> ready, so we should merge this patch very early in the 24.11 to give
>>> time to drivers to fix if they were not ready at that time.
>>>
>>> Other option is merge this patch in 24.07, so that vendors which were
>>> not ready can plan a fix for 24.11? Although enforcing an update by
>>> breaking the driver is not best planning, it may be an efficient one.
>>>  
>>
>> Hi Thomas and et al. ,
>>
>> Is is good time to merge this patch, there is enough time to fix
>> potential issues in this release, what do you think?
> 
> Patch needs rebase if going into 24.11
>

Indeed we talked about this in the release status meeting this morning,
as we discussed similar issue with Huisong [1].

If we will continue with the patch it should be merged before -rc1, so
that drivers can fix any impact from it.

Some options I can think of:

1. Move `RTE_LIBRTE_IEEE1588` macro to `config/rte_config.h`, so make it
a little more configurable and keep macro (easiest, but not preferable).

2. Add a new meson config option to 'config/rte_config.h' to set/unset
this macro, keep macro as it is.

3. Remove the macro, replace it with device argument per driver. So make
it dynamically configured instead of build time.

4. Remove the macro, introduce a new offload flag (Huisong has similar
patch [2]) for user to explicitly request this feature.

5. Remove the macro, implicitly enable it in the driver when vector path
is not enabled. So feature will be always on for scalar path, always off
for the vector path. User can disable vector path
(RTE_VECT_SIMD_DISABLED) to enable PTP.


Question is, will drivers have enough time form -rc1 to end of the
release to fix drivers?

Drivers in questions are:
txgbe
ngbe
ixgbe
i40e
igb
fm10k
bnxt
dpaa2
cnxk

Can maintainers of the above drivers please comment?


[1]
https://inbox.dpdk.org/dev/1240fd64-ba5d-4dcc-b825-851da25b8efb@amd.com/

[2]
https://patches.dpdk.org/project/dpdk/patch/20240130035820.29713-1-lihuisong@huawei.com/

      reply	other threads:[~2024-10-03 22:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 13:28 Thomas Monjalon
2023-06-23 14:00 ` Ferruh Yigit
2023-06-25 15:45   ` Thomas Monjalon
2023-11-02 21:13     ` Ferruh Yigit
2023-11-02 21:21       ` Ajit Khaparde
2023-11-02 22:17         ` Thomas Monjalon
2023-11-03  0:08           ` Ferruh Yigit
2024-04-17 13:24             ` Ferruh Yigit
2024-10-03 19:12               ` Stephen Hemminger
2024-10-03 22:36                 ` Ferruh Yigit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=300aef18-316a-420d-9b3e-a06a05d3bab2@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=aman.deep.singh@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=hkalra@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=jianwang@trustnetic.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=kirankumark@marvell.com \
    --cc=lihuisong@huawei.com \
    --cc=ndabilpuram@marvell.com \
    --cc=olivier.matz@dev.6wind.com \
    --cc=sachin.saxena@nxp.com \
    --cc=skori@marvell.com \
    --cc=skoteshwar@marvell.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).