On Mon, 14 Nov 2005 17:46:24 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] a écrit :
> > Use hits to speed up the SACK processing. Various forms
> > of this have been used by TCP developers (Web100, STCP, BIC)
> > to avoid the 2x linear search of outstanding segments.
> >
> > --- net-2.6.orig/include/linux/tcp.h
> > +++ net-2.6/include/linux/tcp.h
> > @@ -307,6 +307,21 @@ struct tcp_sock {
> > struct tcp_sack_block duplicate_sack[1]; /* D-SACK block */
> > struct tcp_sack_block selective_acks[4]; /* The SACKS themselves*/
> >
> > + struct tcp_sack_block recv_sack_cache[4];
> > +
> > + /* from STCP, retrans queue hinting */
> > + struct sk_buff* lost_skb_hint;
> > +
> > + struct sk_buff *scoreboard_skb_hint;
> > + struct sk_buff *retransmit_skb_hint;
> > + struct sk_buff *forward_skb_hint;
> > + struct sk_buff *fastpath_skb_hint;
> > +
> > + int fastpath_cnt_hint;
> > + int lost_cnt_hint;
> > + int retransmit_cnt_hint;
> > + int forward_cnt_hint;
> > +
> > __u16 advmss; /* Advertised MSS */
> > __u16 prior_ssthresh; /* ssthresh saved at recovery start */
> > __u32 lost_out; /* Lost packets */
>
> Well... what about memory footprint ?
>
> On a 32bits machine :
>
> sizeof(struct tcp_sock) = 960 (4 objects per slab)
>
> After applying this patch we basically break the limit :
>
> sizeof(struct tcp_sock) = 960+32+36=1028 (3 objects per slab)
>
> Eric
It could be made smaller, and there probably are better solutions.
I view this as a first step. so expect refinements with better algorithms
and smaller footprint. There are some things that could be shrunk in
the cb to make space as well.
--
Stephen Hemminger <[EMAIL PROTECTED]>
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
