Re: [PATCH 2/3] Seperate DSACK from SACK fast path
From: David Miller <davem@davemloft.net>
Date: 2007-01-28 04:06:11
From: David Miller <davem@davemloft.net>
Date: 2007-01-28 04:06:11
From: Baruch Even <redacted> Date: Sat, 27 Jan 2007 18:49:49 +0200
Since the SACK receive cache doesn't need the data to be in host order we also remove the ntohl in the checking loop.
...
- for (i = 0; i< num_sacks; i++) {
- __u32 start_seq = ntohl(sp[i].start_seq);
- __u32 end_seq = ntohl(sp[i].end_seq);
+ for (i = 0; i < num_sacks; i++) {
+ __u32 start_seq = sp[i].start_seq;
+ __u32 end_seq = sp[i].end_seq;...
} tp->recv_sack_cache[i].start_seq = start_seq; tp->recv_sack_cache[i].end_seq = end_seq;
Ok, and now the sack cache and the real sack blocks are stored in net-endian and this works out because we only make direct equality comparisons with the recv_sack_cache[] entry values?