From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: David Miller <davem@davemloft.net>
Cc: paul.moore@hp.com, tgraf@suug.ch, netdev@vger.kernel.org
Subject: Re: [RFC] Wild and crazy ideas involving struct sk_buff
Date: Wed, 22 Aug 2007 19:06:10 -0300 [thread overview]
Message-ID: <20070822220610.GD23220@ghostprotocols.net> (raw)
In-Reply-To: <20070822.143627.62367286.davem@davemloft.net>
Em Wed, Aug 22, 2007 at 02:36:27PM -0700, David Miller escreveu:
> From: Paul Moore <paul.moore@hp.com>
> Date: Wed, 22 Aug 2007 17:26:36 -0400
>
> > Was it just a thought, or was there some actual design/code/patchset
> > to go along with it that described the idea?
>
> It was a thought mentioned at the first two netconfs, but it
> went nowhere because the more we discussed the implementation
> the more horrific it began to sound :-)
Which makes it more interesting to make it work :-)
Anyway, there is space there to be used, in 32 and 64 bits we have two
bytes after queue_mapping (this kernel doesn't have CONFIG_NET_SCHED nor
CONFIG_NET_CLS_ACT enabled, if the first was we wouldn't have the hole,
but if both, as its common in distro kernels, were we would have the 2
bytes hole, as we can see on the pahole output for the 64bits kernel,
that uses the kernel config used in the Red Hat kernels.
Bonus points would go to continue the skb offset fight and reduce the
size of mac_header to two bytes, and then moving it to just after
queue_mapping. Do that and you'll get some credits :-P
- Arnaldo
[acme@mica net-2.6.24]$ pahole -C sk_buff ../32bits/net/core/skbuff.o
struct sk_buff {
struct sk_buff * next; /* 0 4 */
struct sk_buff * prev; /* 4 4 */
struct sock * sk; /* 8 4 */
ktime_t tstamp; /* 12 8 */
struct net_device * dev; /* 20 4 */
struct dst_entry * dst; /* 24 4 */
struct sec_path * sp; /* 28 4 */
char cb[48]; /* 32 48 */
/* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
unsigned int len; /* 80 4 */
unsigned int data_len; /* 84 4 */
__u16 mac_len; /* 88 2 */
__u16 hdr_len; /* 90 2 */
union {
__wsum csum; /* 4 */
struct {
__u16 csum_start; /* 92 2 */
__u16 csum_offset; /* 94 2 */
} /* 4 */
}; /* 92 4 */
__u32 priority; /* 96 4 */
__u8 local_df:1; /* 100 1 */
__u8 cloned:1; /* 100 1 */
__u8 ip_summed:2; /* 100 1 */
__u8 nohdr:1; /* 100 1 */
__u8 nfctinfo:3; /* 100 1 */
__u8 pkt_type:3; /* 101 1 */
__u8 fclone:2; /* 101 1 */
__u8 ipvs_property:1; /* 101 1 */
__u8 nf_trace:1; /* 101 1 */
/* XXX 1 bit hole, try to pack */
__be16 protocol; /* 102 2 */
void (*destructor)(struct sk_buff *); /* 104 4 */
int iif; /* 108 4 */
__u16 queue_mapping; /* 112 2 */
/* XXX 2 bytes hole, try to pack */
__u32 mark; /* 116 4 */
sk_buff_data_t transport_header; /* 120 4 */
sk_buff_data_t network_header; /* 124 4 */
/* --- cacheline 2 boundary (128 bytes) --- */
sk_buff_data_t mac_header; /* 128 4 */
sk_buff_data_t tail; /* 132 4 */
sk_buff_data_t end; /* 136 4 */
unsigned char * head; /* 140 4 */
unsigned char * data; /* 144 4 */
unsigned int truesize; /* 148 4 */
atomic_t users; /* 152 4 */
/* size: 156, cachelines: 3 */
/* sum members: 154, holes: 1, sum holes: 2 */
/* bit holes: 1, sum bit holes: 1 bits */
/* last cacheline: 28 bytes */
};
[acme@mica net-2.6.24]$ pahole -C sk_buff ../64bits/net/core/skbuff.o
struct sk_buff {
struct sk_buff * next; /* 0 8 */
struct sk_buff * prev; /* 8 8 */
struct sock * sk; /* 16 8 */
ktime_t tstamp; /* 24 8 */
struct net_device * dev; /* 32 8 */
struct dst_entry * dst; /* 40 8 */
struct sec_path * sp; /* 48 8 */
char cb[48]; /* 56 48 */
/* --- cacheline 1 boundary (64 bytes) was 40 bytes ago --- */
unsigned int len; /* 104 4 */
unsigned int data_len; /* 108 4 */
__u16 mac_len; /* 112 2 */
__u16 hdr_len; /* 114 2 */
union {
__wsum csum; /* 4 */
struct {
__u16 csum_start; /* 116 2 */
__u16 csum_offset; /* 118 2 */
} /* 4 */
}; /* 116 4 */
__u32 priority; /* 120 4 */
__u8 local_df:1; /* 124 1 */
__u8 cloned:1; /* 124 1 */
__u8 ip_summed:2; /* 124 1 */
__u8 nohdr:1; /* 124 1 */
__u8 nfctinfo:3; /* 124 1 */
__u8 pkt_type:3; /* 125 1 */
__u8 fclone:2; /* 125 1 */
__u8 ipvs_property:1; /* 125 1 */
__u8 nf_trace:1; /* 125 1 */
/* XXX 1 bit hole, try to pack */
__be16 protocol; /* 126 2 */
/* --- cacheline 2 boundary (128 bytes) --- */
void (*destructor)(struct sk_buff *); /* 128 8 */
struct nf_conntrack * nfct; /* 136 8 */
struct sk_buff * nfct_reasm; /* 144 8 */
struct nf_bridge_info * nf_bridge; /* 152 8 */
int iif; /* 160 4 */
__u16 queue_mapping; /* 164 2 */
__u16 tc_index; /* 166 2 */
__u16 tc_verd; /* 168 2 */
/* XXX 2 bytes hole, try to pack */
dma_cookie_t dma_cookie; /* 172 4 */
__u32 secmark; /* 176 4 */
__u32 mark; /* 180 4 */
sk_buff_data_t transport_header; /* 184 4 */
sk_buff_data_t network_header; /* 188 4 */
/* --- cacheline 3 boundary (192 bytes) --- */
sk_buff_data_t mac_header; /* 192 4 */
sk_buff_data_t tail; /* 196 4 */
sk_buff_data_t end; /* 200 4 */
/* XXX 4 bytes hole, try to pack */
unsigned char * head; /* 208 8 */
unsigned char * data; /* 216 8 */
unsigned int truesize; /* 224 4 */
atomic_t users; /* 228 4 */
/* size: 232, cachelines: 4 */
/* sum members: 226, holes: 2, sum holes: 6 */
/* bit holes: 1, sum bit holes: 1 bits */
/* last cacheline: 40 bytes */
};
next prev parent reply other threads:[~2007-08-22 22:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-22 20:31 [RFC] Wild and crazy ideas involving struct sk_buff Paul Moore
2007-08-22 21:08 ` David Miller
2007-08-22 21:23 ` Paul Moore
2007-08-22 21:20 ` Thomas Graf
2007-08-22 21:26 ` Paul Moore
2007-08-22 21:36 ` David Miller
2007-08-22 22:06 ` Arnaldo Carvalho de Melo [this message]
2007-08-22 22:09 ` James Morris
2007-08-22 22:20 ` Paul Moore
2007-08-22 22:31 ` James Morris
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=20070822220610.GD23220@ghostprotocols.net \
--to=acme@ghostprotocols.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=paul.moore@hp.com \
--cc=tgraf@suug.ch \
/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;
as well as URLs for NNTP newsgroup(s).