From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Willem de Bruijn <willemb@google.com>
Cc: Network Development <netdev@vger.kernel.org>,
Richard Cochran <richardcochran@gmail.com>,
David Miller <davem@davemloft.net>,
"dumazet >> Eric Dumazet" <eric.dumazet@gmail.com>
Subject: Re: [PATCH 2/2] net-timestamp: Make the clone operation stand-alone from phy timestamping
Date: Wed, 03 Sep 2014 14:24:00 -0700 [thread overview]
Message-ID: <540786F0.908@intel.com> (raw)
In-Reply-To: <CA+FuTSdsrAAd0iti0oF3MDvXTtQWnBByuo_UMGCW2Dd+WnWeLg@mail.gmail.com>
On 09/03/2014 11:54 AM, Willem de Bruijn wrote:
> On Wed, Sep 3, 2014 at 11:53 AM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
>> The phy timestamping takes a different path than the regular timestamping
>> does in that it will create a clone first so that the packets needing to be
>> timestamped can be placed in a queue, or the context block could be used.
>>
>> In order to support these use cases I am pulling the core of the code out
>> so it can be used in other drivers beyond just phy devices.
>
> Do you already have additional such use cases?
I have a driver that I am working on that I will probably push in a
couple of weeks that will make use of this interface. I basically need
to maintain a list of SKBs as I can multiple timestamps out for
completion at the same time.
>> +struct sk_buff *__skb_clone_tx_timestamp(struct sk_buff *skb)
>> +{
>> + struct sock *sk = skb->sk;
>> + struct sk_buff *clone;
>> +
>> + if (!sk || !atomic_inc_not_zero(&sk->sk_refcnt))
>> + return NULL;
>> +
>> + clone = skb_clone(skb, GFP_ATOMIC);
>> + if (!clone) {
>> + sock_put(sk);
>> + return NULL;
>> + }
>> +
>> + clone->sk = sk;
>> +
>> + return clone;
>> +}
>> +EXPORT_SYMBOL(__skb_clone_tx_timestamp);
>> +
>
> Code looks great. Again, this can be verified to be a functional noop.
> One minor comment is that this really is not a timestamping function,
> but an skb_clone variant. skb_clone_sk?
Let me think about this one. Between the comment Eric had about
skb->destructor and the fact that this is essentially just forking the
skb so we can hold it for the reply I might be able to come up with a
better solution.
I'm thinking it might be worthwhile to create a simple destructor as
then I could probably tear out several spots in the phy timestamping
code where it is having to use skb_complete_tx_timestamp to free the
frames that are allocated using the approach in this function.
Thanks,
Alex
next prev parent reply other threads:[~2014-09-03 21:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 15:53 [PATCH 0/2] Combine standard and phy timestamping logic Alexander Duyck
2014-09-03 15:53 ` [PATCH 1/2] net-timestamp: Merge shared code between phy and regular timestamping Alexander Duyck
2014-09-03 18:50 ` Willem de Bruijn
2014-09-03 15:53 ` [PATCH 2/2] net-timestamp: Make the clone operation stand-alone from phy timestamping Alexander Duyck
2014-09-03 18:54 ` Willem de Bruijn
2014-09-03 21:24 ` Alexander Duyck [this message]
2014-09-03 21:07 ` Eric Dumazet
2014-09-03 22:05 ` Eric Dumazet
2014-09-03 23:02 ` Alexander Duyck
2014-09-04 2:03 ` Eric Dumazet
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=540786F0.908@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=willemb@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.