[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <673b62f785bf3_1d65242948d@willemb.c.googlers.com.notmuch>
Date: Mon, 18 Nov 2024 10:53:27 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: "Olech, Milena" <milena.olech@...el.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>,
"Lobakin, Aleksander" <aleksander.lobakin@...el.com>
Subject: RE: [PATCH iwl-net 09/10] idpf: add support for Rx timestamping
Olech, Milena wrote:
> On 11/14/2024 9:54 PM, Willem de Bruijn wrote:
>
> > Milena Olech wrote:
> > > Add Rx timestamp function when the Rx timestamp value is read directly
> > > from the Rx descriptor. Add supported Rx timestamp modes.
> > >
> > > Reviewed-by: Alexander Lobakin <aleksander.lobakin@...el.com>
> > > Signed-off-by: Milena Olech <milena.olech@...el.com>
> > > ---
> > > drivers/net/ethernet/intel/idpf/idpf_ptp.c | 74
> > > ++++++++++++++++++++- drivers/net/ethernet/intel/idpf/idpf_txrx.c |
> > > 30 +++++++++ drivers/net/ethernet/intel/idpf/idpf_txrx.h | 7 +-
> > > 3 files changed, 109 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> > > b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> > > index f34642d10768..f9f7613f2a6d 100644
> > > --- a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> > > +++ b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> > > @@ -317,12 +317,41 @@ static int idpf_ptp_gettimex64(struct ptp_clock_info *info,
> > > return 0;
> > > }
> > >
> > > +/**
> > > + * idpf_ptp_update_phctime_rxq_grp - Update the cached PHC time for a given Rx
> > > + * queue group.
> >
> > Why does each receive group have a separate cached value?
> > They're all caches of the same device clock.
>
> That's correct - they all caches values of the same PHC, however I would
> like to have an effective method to access this value in hotpath where
> I'm extending the Rx timestamp value to 64 bit.
>
> For the same reason I cached Tx timestamp caps in
> idpf_vport_init_fast_path_txqs.
Oh to avoid reading a cold cacheline in the hot path. Okay, that makes
sense. Please make a note of this in the commit message.
Powered by blists - more mailing lists