From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Tomasz Grobelny <tomasz@grobelny.oswiecenia.net>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
dccp@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set
Date: Sun, 20 Apr 2008 13:57:42 -0300 [thread overview]
Message-ID: <20080420165742.GA12221@ghostprotocols.net> (raw)
In-Reply-To: <200804192242.33632.tomasz@grobelny.oswiecenia.net>
Em Sat, Apr 19, 2008 at 10:42:32PM +0200, Tomasz Grobelny escreveu:
> Dnia Friday 18 of April 2008, Gerrit Renker napisał:
> > | > There is a more serious problem here: apparently no one tried to
> > | > compile the `qpolicy' subtree since the changes on Monday. It fails
> > | > with the BUILD_BUG_ON.
> > | >
> > | > I tried yesterday evening and found that there is not even a
> > | > possibility of adding a single field to struct dccp_skb_cb: with the
> > | > addition of the inet{,6}_skb_parm, the struct has reached its maximum
> > | > size of 48 bytes (try printk("%u", sizeof(struct dccp_skb_cb));).
> > | >
> > | > There is a solution to this, will post a revised patch shortly.
> > |
> > | What you proposed in the patch should work ok for qpolicies for now. But
> > | sooner or later the need to add a field to struct dccp_skb_cb will arise.
> > | So maybe we should think about it now...
> > | Other possibility apart from what you proposed in the patch is creating
> > | struct dccp_skb_cb_ext, move to it some fields from struct dccp_skb_cb
> > | and in struct add a pointer to this new struct dccp_skb_cb_ext. Ok, maybe
> > | it is not the prettiest idea but in case somebody needs yet another
> > | additional field in struct dccp_skb_cb_ext it would be nice to have an
> > | idea how to do it.
> >
> > When the patch failed to compile I thought about those alternatives.
> > Trying to extend the dccp_skb_cb over and above what is in there will be
> > messy, since the IPv4/v6 parameters are required by other subsystems.
> >
> If inet{,6}_skb_parm is used only outside DCCP code then why at all should it
> be placed in struct dccp_skb_cb taking up quite a lot of valuable space? Why
> not put it directly in struct sk_buff? Especially that it is present in
> struct udp_skb_cb, struct tcp_skb_cb as well.
Because all this is used in skb->cb[], a scratchpad for protocols to
use, we can go back to what we had before, that is to not reserve use
for inet6?_skb_parm but be sure to zero it before passing it to IP, as
we don't want IP to be confused with things being non zero there. Then
we can use all its space.
- Arnaldo
next prev parent reply other threads:[~2008-04-20 16:57 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-11 10:24 [PATCH 0/5] [DCCP]: Queuing policies Tomasz Grobelny
2008-04-14 6:50 ` Gerrit Renker
2008-04-14 7:39 ` [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set Gerrit Renker
2008-04-14 23:45 ` Tomasz Grobelny
2008-04-15 15:14 ` Gerrit Renker
2008-04-15 15:21 ` Gerrit Renker
2008-04-15 18:01 ` Tomasz Grobelny
2008-04-16 6:20 ` Gerrit Renker
2008-04-16 8:36 ` [DCCP] [RFC] [Patchv3 " Gerrit Renker
2008-04-17 20:03 ` [DCCP] [RFC] [Patchv2 " Tomasz Grobelny
2008-04-18 10:13 ` Gerrit Renker
2008-04-19 20:42 ` Tomasz Grobelny
2008-04-20 16:57 ` Arnaldo Carvalho de Melo [this message]
2008-04-20 20:12 ` Tomasz Grobelny
2008-04-21 11:45 ` Patrick McHardy
2008-04-21 13:12 ` Arnaldo Carvalho de Melo
2008-04-21 16:17 ` Tomasz Grobelny
2008-04-22 4:56 ` Patrick McHardy
2008-04-22 20:45 ` Tomasz Grobelny
2008-04-22 22:06 ` David Miller
2008-04-23 0:03 ` Patrick McHardy
2008-04-22 17:41 ` Gerrit Renker
2008-04-22 22:42 ` David Miller
2008-04-25 19:33 ` Tomasz Grobelny
2008-04-25 20:40 ` Arnaldo Carvalho de Melo
2008-04-25 20:58 ` David Miller
2008-04-28 7:21 ` Gerrit Renker
2008-04-28 7:39 ` David Miller
2008-04-22 17:30 ` Gerrit Renker
2008-04-22 20:30 ` Tomasz Grobelny
[not found] ` <20080424220704.0483DBC12@poczta.oswiecenia.net>
2008-04-24 22:16 ` [PATCH 1/1] [DCCP][QPOLICY]: External interface changes Tomasz Grobelny
2008-04-28 15:08 ` Gerrit Renker
2008-04-28 21:29 ` Tomasz Grobelny
2008-04-28 13:10 ` [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set Gerrit Renker
2008-04-28 15:19 ` [DCCP] [RFC] [Patchv3 " Gerrit Renker
2008-04-28 20:12 ` Tomasz Grobelny
2008-04-28 21:03 ` [DCCP] [RFC] [Patchv2 " Tomasz Grobelny
2008-04-30 7:53 ` Gerrit Renker
2008-05-02 20:39 ` Tomasz Grobelny
2008-05-02 20:56 ` Gerrit Renker
2008-04-15 19:38 ` Tomasz Grobelny
2008-04-15 20:04 ` Arnaldo Carvalho de Melo
2008-04-17 20:20 ` Tomasz Grobelny
2008-04-15 20:14 ` inconsistent lock state with kernel 2.6.24.4 Bernard Pidoux
2008-04-16 7:43 ` [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set Gerrit Renker
2008-04-17 18:03 ` Tomasz Grobelny
2008-04-17 18:29 ` Gerrit Renker
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=20080420165742.GA12221@ghostprotocols.net \
--to=acme@redhat.com \
--cc=dccp@vger.kernel.org \
--cc=gerrit@erg.abdn.ac.uk \
--cc=netdev@vger.kernel.org \
--cc=tomasz@grobelny.oswiecenia.net \
/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).