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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dnia Sunday 20 of April 2008, Arnaldo Carvalho de Melo napisał:
> Em Sat, Apr 19, 2008 at 10:42:32PM +0200, Tomasz Grobelny escreveu:
> > > 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.
>
Several questions regarding this case:
1. What about SCTP? It doesn't have inet6?_skb_parm in it's structure that is 
stored in skb->cb. So does it contain a potential bug (that is to be fixed) 
or is it not needed there or what?
2. If the sole purpose of this change was to keep skb->cb zeroed then it 
doesn't seem to me like the right solution. Wasting about 20 bytes instead of 
zeroing them when needed I would consider at least weird. I understand that 
TCP and UDP may have enough space left but it just turned out that DCCP 
doesn't.
3. If it's IP layer that needs zeroes then why not clear skb->cb in IP layer?
-- 
Regards,
Tomasz Grobelny
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [IETF DCCP]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux