Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

From: Arnaldo Carvalho de Melo <[email-masked]>
Date: Fri, 25 Apr 2008 17:40:24 -0300

Em Fri, Apr 25, 2008 at 09:33:11PM +0200, Tomasz Grobelny escreveu:
> Dnia Wednesday 23 of April 2008, David Miller napisał:
> > From: Gerrit Renker <[email-masked]>
> > Date: Tue, 22 Apr 2008 18:41:52 +0100
> >
> > > | If we iron this out we could finally return to the main subject of this
> > > | thread. That is Patch v2 by me and Gerrit...
> > > | --
> > >
> > > Fully agree - we just need to decide whether or not to use skb->priority.
> > >
> > > Below is as far as I got in integrating your patch last week, it shows
> > > only the major changes. The following bits have been updated:
> > >
> > >  * skb->priority now cleared before passing the skb onto layer 3;
> > >  * order of statements in prio_push() reversed (first dropping worst
> > >    skb and then pushing the new skb - this is better when e.g.
> > >    tx_qlen=1);
> > >  * added general parsing routine for cmsg(3) socket control messages
> > >    and defined one for the SOL_DCCP socket level; thanks to advice
> > >    by Dave Miller
> >
> > If this usage of skb->priority is going to override the
> > IP_TOS socket option setting, I don't think it's a good
> > idea.
> >
> > Right now every packet output goes through ip_output.c
> > which sets skb->priority to sk->sk_priority, which is set
> > by the user via the IP_TOS socket option in ip_sockglue.c
> > 
> But I guess this assignment happens a bit later (that is after outgoing packet 
> leaves DCCP code). Consequently using skb->priority should not harm as it 
> will be overwritten. Or did I miss something?

I haven't read all the patches, but I guess Tomasz is on the safe side
as the intended skb->priority usage is limited to DCCP, when IP is
handed the skb it can do as it pleases with skb->priority.

- Arnaldo