The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"johnstul@us.ibm.com" <johnstul@us.ibm.com>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [RFC PATCH 02/12] net: infrastructure for hardware time stamping
Date: Tue, 16 Dec 2008 08:56:59 +0100	[thread overview]
Message-ID: <1229414219.18038.241.camel@ecld0pohly> (raw)
In-Reply-To: <E1LCLNV-0001EW-CN@gondolin.me.apana.org.au>

On Mon, 2008-12-15 at 21:53 +0000, Herbert Xu wrote:
> Patrick Ohly <patrick.ohly@intel.com> wrote:
> > @@ -305,6 +406,8 @@ struct sk_buff {
> >                                ipvs_property:1,
> >                                peeked:1,
> >                                nf_trace:1;
> > +       /* not all of the bits in optional are used */
> > +       __u8                    optional;
> >        __be16                  protocol;
> 
> You do reliase that this is going to grow the sk_buff by at least
> 4 bytes and not 1?

Yes. I should have been more explicit about that when talking about
"adding one byte". At least it's better than adding 8 bytes of
additional data, as in the previous patch.

I haven't checked it, but was told that sk_buff is already tightly
packed. It didn't look like there was a better place to put the byte
either.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


  reply	other threads:[~2008-12-16  7:57 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 14:54 hardware time stamping with optional structs in data area Patrick Ohly
2008-12-15 14:54 ` [RFC PATCH 01/12] net: new user space API for time stamping of incoming and outgoing packets Patrick Ohly
2008-12-15 14:54   ` [RFC PATCH 02/12] net: infrastructure for hardware time stamping Patrick Ohly
2008-12-15 14:54     ` [RFC PATCH 03/12] net: socket infrastructure for SO_TIMESTAMPING Patrick Ohly
2008-12-15 14:54       ` [RFC PATCH 04/12] sockets: allow allocating skb with optional structures Patrick Ohly
2008-12-15 14:54         ` [RFC PATCH 05/12] ip: support for TX timestamps on UDP and RAW sockets Patrick Ohly
2008-12-15 14:54           ` [RFC PATCH 06/12] debug: NULL pointer check in ip_output Patrick Ohly
2008-12-15 14:54             ` [RFC PATCH 07/12] net: pass new SIOCSHWTSTAMP through to device drivers Patrick Ohly
2008-12-15 14:54               ` [RFC PATCH 08/12] igb: stub support for SIOCSHWTSTAMP Patrick Ohly
2008-12-15 14:54                 ` [RFC PATCH 09/12] clocksource: allow usage independent of timekeeping.c Patrick Ohly
2008-12-15 14:54                   ` [RFC PATCH 10/12] igb: access to NIC time Patrick Ohly
2008-12-15 14:54                     ` [RFC PATCH 11/12] time sync: generic infrastructure to map between time stamps generated by a time counter and system time Patrick Ohly
2008-12-15 14:54                       ` [RFC PATCH 12/12] igb: use clocksync to implement hardware time stamping Patrick Ohly
2008-12-15 16:26                   ` [RFC PATCH 09/12] clocksource: allow usage independent of timekeeping.c John Stultz
2008-12-15 16:45                     ` Patrick Ohly
2009-02-04 14:29                     ` Daniel Walker
2009-02-04 15:00                       ` Patrick Ohly
2008-12-15 21:53     ` [RFC PATCH 02/12] net: infrastructure for hardware time stamping Herbert Xu
2008-12-16  7:56       ` Patrick Ohly [this message]
2009-01-16 10:36 ` hardware time stamping with optional structs in data area Patrick Ohly
2009-01-16 19:00   ` David Miller
2009-01-21 10:07     ` Patrick Ohly
2009-01-21 10:10       ` [PATCH NET-NEXT 01/12] net: new user space API for time stamping of incoming and outgoing packets Patrick Ohly
2009-01-21 10:10         ` [PATCH NET-NEXT 02/12] net: infrastructure for hardware time stamping Patrick Ohly
2009-01-21 10:10           ` [PATCH NET-NEXT 03/12] net: socket infrastructure for SO_TIMESTAMPING Patrick Ohly
2009-01-21 10:10             ` [PATCH NET-NEXT 04/12] sockets: allow allocating skb with optional structures Patrick Ohly
2009-01-21 10:10               ` [PATCH NET-NEXT 05/12] ip: support for TX timestamps on UDP and RAW sockets Patrick Ohly
2009-01-21 10:10                 ` [PATCH NET-NEXT 06/12] debug: NULL pointer check in ip_output Patrick Ohly
2009-01-21 10:10                   ` [PATCH NET-NEXT 07/12] net: pass new SIOCSHWTSTAMP through to device drivers Patrick Ohly
2009-01-21 10:10                     ` [PATCH NET-NEXT 08/12] igb: stub support for SIOCSHWTSTAMP Patrick Ohly
2009-01-21 10:10                       ` [PATCH NET-NEXT 09/12] clocksource: allow usage independent of timekeeping.c Patrick Ohly
2009-01-21 10:10                         ` [PATCH NET-NEXT 10/12] igb: access to NIC time Patrick Ohly
2009-01-21 10:10                           ` [PATCH NET-NEXT 11/12] time sync: generic infrastructure to map between time stamps generated by a time counter and system time Patrick Ohly
2009-01-21 10:10                             ` [PATCH NET-NEXT 12/12] igb: use clocksync to implement hardware time stamping Patrick Ohly
2009-01-21 10:33                             ` [PATCH NET-NEXT 11/12] time sync: generic infrastructure to map between time stamps generated by a time counter and system time Ingo Molnar
2009-01-21 14:42                               ` Patrick Ohly
2009-01-26  5:04       ` hardware time stamping with optional structs in data area David Miller
2009-01-26 20:39         ` Patrick Ohly
2009-01-27  1:22           ` David Miller
2009-01-27 15:23             ` Patrick Ohly
2009-01-28  9:08               ` Herbert Xu
2009-01-28  9:52                 ` Patrick Ohly
2009-01-28  9:54                   ` Herbert Xu
2009-02-01  8:14                 ` David Miller
2009-02-04 13:02                   ` Patrick Ohly

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=1229414219.18038.241.camel@ecld0pohly \
    --to=patrick.ohly@intel.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=johnstul@us.ibm.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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