[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMZ6RqKL62wR5KRRJgy8fiEHSKCQvP7CJFdR1=8MPh4_3pMq_A@mail.gmail.com>
Date: Sun, 10 Jan 2021 21:32:18 +0900
From: Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To: Jeroen Hofstee <jhofstee@...tronenergy.com>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>,
linux-can <linux-can@...r.kernel.org>,
Wolfgang Grandegger <wg@...ndegger.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
"open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] can: dev: add software tx timestamps
Hello Jeroen,
On Sun. 10 Jan 2021 at 20:29, Jeroen Hofstee <jhofstee@...tronenergy.com> wrote:
>
> Hello Vincent,
>
> On 1/10/21 11:35 AM, Vincent Mailhol wrote:
> > Call skb_tx_timestamp() within can_put_echo_skb() so that a software
> > tx timestamp gets attached on the skb.
> >
> [..]
> >
> > diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> > index 3486704c8a95..3904e0874543 100644
> > --- a/drivers/net/can/dev.c
> > +++ b/drivers/net/can/dev.c
> > @@ -484,6 +484,8 @@ int can_put_echo_skb(struct sk_buff *skb, struct net_device *dev,
> >
> > /* save this skb for tx interrupt echo handling */
> > priv->echo_skb[idx] = skb;
> > +
> > + skb_tx_timestamp(skb);
> > } else {
> > /* locking problem with netif_stop_queue() ?? */
> > netdev_err(dev, "%s: BUG! echo_skb %d is occupied!\n", __func__, idx);
>
> Personally, I would put the skb_tx_timestamp, before adding it to the array:
>
> /* make settings for echo to reduce code in irq context */
> skb->pkt_type = PACKET_BROADCAST;
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> skb->dev = dev;
> + skb_tx_timestamp(skb);
>
> /* save this skb for tx interrupt echo handling */
> priv->echo_skb[idx] = skb;
I agree that it is better like that from an aesthetic point of
view. The reason to put it at the very end was to really to
blindly follow the doc and do the timestamp as late as possible.
>
> I don't think it actually matters though.
Indeed, but will still follow your suggestion though. Putting it
before would just delay the timestamp by a few assembly
instructions: it is negligible enough.
Yours sincerely,
Vincent Mailhol
Powered by blists - more mailing lists