All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: David Miller <davem@davemloft.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: hardware time stamping with optional structs in data area
Date: Tue, 27 Jan 2009 16:23:57 +0100	[thread overview]
Message-ID: <1233069837.24438.54.camel@pohly-MOBL> (raw)
In-Reply-To: <20090126.172202.261408793.davem@davemloft.net>

On Tue, 2009-01-27 at 03:22 +0200, David Miller wrote:
> From: Patrick Ohly <patrick.ohly@intel.com>
> Date: Mon, 26 Jan 2009 21:39:52 +0100
> 
> > On Mon, 2009-01-26 at 07:04 +0200, David Miller wrote:
> > > Just consolidate the array into a direct conversion table.  You only
> > > have 2 bits defined so you only need an array of 4 entries.  Pass the
> > > optional flag bits directly in as the index of that table.
> > 
> > How can I get some code executed during the initialization of the IP
> > stack which initializes the table, before any sk_buff gets allocated?
> > 
> > The content is constant, but writing it down as static initializers
> > using just preprocessor macros would be difficult and/or ugly - that's
> > why I haven't done it already.
> 
> It's 4 entries... really.

True - at this time. But what if this extension mechanism turns out to
be useful and we end up with more optional structures? I was hoping that
this might be the case and thus tried to make it easy to add more
structures.

> You can initialize them simply, perhaps
> with some fancy macro used by the initializers.

Unfortunately recursion in macros is not possible. One needs duplicated
macro definitions, one for each additional structure. But perhaps my
preprocessor code fu is lacking today and there is a simpler
solution :-/

Anyway, below is example code with three structures which initializes a
size array indexed by a bit mask. I find it truly ugly and hard to
understand - and I wrote it. gcc -S shows that the size arrays contain
the expected values.

Please let me know what approach is preferred and I'll revise the patch
accordingly:
     1. array with four hard-coded values
     2. init code (where?)
     3. macro initialization of array
     4. simpler initialization solution

---------------------------------------------------------------
struct A {
    int a;
};

struct B {
    char b;
};

struct C {
    long long c;
};

enum {
    BIT_A,
    BIT_B,
    BIT_C
};

#define MIN(_a, _b) ((_a) < (_b) ? (_a) : (_b))

/* round up _previous number of bytes so that a struct of_structsize
   bytes is properly aligned at an 8 byte boundary or the structure size,
   whatever is smaller */
#define ALIGN(_previous, _structsize) \
    (((_previous) + MIN(_structsize, 8) - 1) & ~(MIN(_structsize, 8) - 1))

/* number of bytes for struct X alone
 * @_flags: bit mask of BIT_ values
 * @_bitname: name of bit enum for X
 * @_structname: structure name of X, without struct
 */
#define SIZE_X(_flags, _bitname, _structname) \
    (((_flags) & (1<<_bitname)) ? sizeof(struct _structname) : 0)

/* number of bytes needed for B (if present) with or without A in
 * front of it
 * @_flags: bit mask of BIT_A and BIT_B
 */
#define SIZE_B(_flags) \
    (((_flags) & (1<<BIT_B)) ? \
     (ALIGN(SIZE_X(_flags, BIT_A, A), SIZE_X(_flags, BIT_B, B)) + sizeof(struct B)) : \
     SIZE_X(_flags, BIT_A, A))

/* number of bytes needed for C (if present) with combinations of
 * struct A, B in front
 * @_flags: bit mask of BIT_A, BIT_B, BIT_C
 */
#define SIZE_C(_flags) \
    (((_flags) & (1<<BIT_C)) ? \
     (ALIGN(SIZE_B(_flags), SIZE_X(_flags, BIT_C, C)) + sizeof(struct C)) : \
     SIZE_B(_flags))

/* number of bytes needed to store combinations of A, B, C, in this
   order */
int size[] = { 0,

               SIZE_X((1<<BIT_A), BIT_A, A),

               SIZE_B((1<<BIT_B)),
               SIZE_B((1<<BIT_B)|(1<<BIT_A)),

               SIZE_C((1<<BIT_C)),
               SIZE_C((1<<BIT_C)|(1<<BIT_A)),
               SIZE_C((1<<BIT_C)|(1<<BIT_B)),
               SIZE_C((1<<BIT_C)|(1<<BIT_B)|(1<<BIT_A)) };

#define LIST_A(_flags) SIZE_C(_flags), SIZE_C((_flags)|(1<<BIT_A))
#define LIST_B(_flags) LIST_A(_flags), LIST_A((_flags)|(1<<BIT_B))
#define LIST_C(_flags) LIST_B(_flags), LIST_B((_flags)|(1<<BIT_C))

/* same as size */
int size2[] = { LIST_C(0) };
---------------------------------------------------------------

Bye, Patrick


  reply	other threads:[~2009-01-27 15:24 UTC|newest]

Thread overview: 73+ 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 ` 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       ` 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             ` 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                 ` 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                   ` Patrick Ohly
2008-12-15 14:54                   ` [RFC PATCH 10/12] igb: access to NIC time Patrick Ohly
2008-12-15 14:54                     ` 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                       ` 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:26                     ` John Stultz
2008-12-15 16:45                     ` Patrick Ohly
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-15 21:53       ` Herbert Xu
2008-12-15 21:53       ` Herbert Xu
2008-12-16  7:56       ` Patrick Ohly
2008-12-16  7:56         ` Patrick Ohly
2009-01-16 10:36 ` hardware time stamping with optional structs in data area Patrick Ohly
2009-01-16 10:36   ` Patrick Ohly
2009-01-16 19:00   ` David Miller
2009-01-16 19:00     ` David Miller
2009-01-21 10:07     ` Patrick Ohly
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         ` 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               ` 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                 ` 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                   ` 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                     ` Patrick Ohly
2009-01-21 10:10                     ` [PATCH NET-NEXT 08/12] igb: stub support for SIOCSHWTSTAMP Patrick Ohly
2009-01-21 10:10                       ` 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                         ` Patrick Ohly
2009-01-21 10:10                         ` [PATCH NET-NEXT 10/12] igb: access to NIC time Patrick Ohly
2009-01-21 10:10                           ` 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 10:33                               ` 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  1:22             ` David Miller
2009-01-27 15:23             ` Patrick Ohly [this message]
2009-01-28  9:08               ` Herbert Xu
2009-01-28  9:52                 ` Patrick Ohly
2009-01-28  9:52                   ` Patrick Ohly
2009-01-28  9:54                   ` Herbert Xu
2009-01-28  9:54                     ` Herbert Xu
2009-02-01  8:14                 ` David Miller
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=1233069837.24438.54.camel@pohly-MOBL \
    --to=patrick.ohly@intel.com \
    --cc=davem@davemloft.net \
    --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 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.