Wireless network card capabilities
Hi, Can Wireless network cards receive and transmit on two channels at once? I am thinking of implementing a way for a wireless VoIP phone on Linux being able to hand off from one AP to another without dropping the call. For this to work, the wireless card must be able to chat on two channels during the handover, so as to not loose any voice packets. James - 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
Re: Wireless network card capabilities
On 07-02-04 10:42 James Courtier-Dutton wrote: Hi, Can Wireless network cards receive and transmit on two channels at once? I am thinking of implementing a way for a wireless VoIP phone on Linux being able to hand off from one AP to another without dropping the call. For this to work, the wireless card must be able to chat on two channels during the handover, so as to not loose any voice packets. James The easiest way to achieve this is to use two wireless adapters. I'm not sure, whether there are adapters, which support parallel reception on two channels and manage two independent associations at the same time. -- Uli Kunitz - 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
Re: Wireless network card capabilities
James, Can Wireless network cards receive and transmit on two channels at once? No cards that I know of contain two PHYs which would (afaict) be required for this. johannes signature.asc Description: This is a digitally signed message part
[PATCH] ipv4: remove a call to skb_queue_len() in inet_diag.c
remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen) and
replace a sizeof() by a Netlink Macro
Signed-off-by: Thomas Hisch [EMAIL PROTECTED]
---
sorry, my previous version of this patch didn't conform to the Codingstyle
document.
now everything should be fine.
net/ipv4/inet_diag.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index 77761ac..9cf27c7 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -846,7 +846,7 @@ static inline void inet_diag_rcv_skb(struct sk_buff *skb)
int err;
struct nlmsghdr *nlh = (struct nlmsghdr *)skb-data;
- if (nlh-nlmsg_len sizeof(*nlh) ||
+ if (nlh-nlmsg_len NLMSG_HDRLEN ||
skb-len nlh-nlmsg_len)
return;
err = inet_diag_rcv_msg(skb, nlh);
@@ -858,9 +858,8 @@ static inline void inet_diag_rcv_skb(struct sk_buff *skb)
static void inet_diag_rcv(struct sock *sk, int len)
{
struct sk_buff *skb;
- unsigned int qlen = skb_queue_len(sk-sk_receive_queue);
- while (qlen-- (skb = skb_dequeue(sk-sk_receive_queue))) {
+ while ((skb = skb_dequeue(sk-sk_receive_queue)) != NULL) {
inet_diag_rcv_skb(skb);
kfree_skb(skb);
}
--
1.5.0.rc3.22.g5057
-
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
Re: [PATCH] ipv4: remove a call to skb_queue_len() in inet_diag.c
On 2/4/07, David Miller [EMAIL PROTECTED] wrote: From: Thomas Hisch [EMAIL PROTECTED] Date: Sun, 4 Feb 2007 15:29:21 +0100 remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen) and replace a sizeof() by a Netlink Macro Signed-off-by: Thomas Hisch [EMAIL PROTECTED] You don't understand the code you are editing :-) We want to process the number of packets present when we start the function, other threads can add more packets to the queue meanwhile and we don't want to keep dequeueing in that case or else we can theoretically run forever with a fast enough producer. Also, please post all networking patches to netdev@vger.kernel.org, the majority of the networking developers do not read linux-kernel. Thank you. thanks for the advice. next time i should look more closely at the code ;) i thought that this was a candidate for a cleanup as no other netlink protocol used such a while loop condition. Thomas. - 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
Re: [PATCH] ipv4: remove a call to skb_queue_len() in inet_diag.c
From: Thomas Hisch [EMAIL PROTECTED] Date: Sun, 4 Feb 2007 15:29:21 +0100 remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen) and replace a sizeof() by a Netlink Macro Signed-off-by: Thomas Hisch [EMAIL PROTECTED] You don't understand the code you are editing :-) We want to process the number of packets present when we start the function, other threads can add more packets to the queue meanwhile and we don't want to keep dequeueing in that case or else we can theoretically run forever with a fast enough producer. Also, please post all networking patches to netdev@vger.kernel.org, the majority of the networking developers do not read linux-kernel. Thank you. - 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
Re: Unexpected Acknowledgement / Stalled Connections
On 2/4/07, Parag Warudkar [EMAIL PROTECTED] wrote: I am running 2.6.20 and have trouble with stalled connections. For instance, if I try to download a debian ISO image using wget, the connection runs fine for few seconds and then stalls for ever. In my router logs I see a ton of messages like the below - [INFO] Sun Feb 04 17:22:03 2007 Blocked incoming TCP packet from 192.168.0.174:34090 to 130.239.18.138:80 with unexpected acknowledgement 3269301836 (expected 3269343453 to 3269408989) Where 192.168.0.174 is my laptop running FC6 and kernel 2.6.20 and 130.239.18.138 is whatever cdimage.debian.org resolves to atm. What's going on here? Any TCP/IP tunable that I can set/turn on/off to prevent this from happening? Turning tcp_sack off seems to cure it. Turning it on again makes the connections stall. Seems like the D-Link router doesn't like the SACKs linux sends? Parag - 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
Re: [Cbe-oss-dev] spidernet: dynamic phy setup code
On Thu, 2007-02-01 at 12:04 +0100, Jens Osterkamp wrote: Ishizaki-san, This patch partially works on celleb but remains following several problems. 1. It doesn't recover once an ethernet cable which is connected to a spider_net card is unpluged. My understanding is that you are using the LINK interrupt to detect this. For the blade this is not connected but reenabling it wont hurt, I hope. I would suggest just polling from a delayed work or a timer like sungem does. I still dont see why you need different settings for different speed switches. This is getting to a point where access to some hardware would be handy. What exact phy are using anyway ? Yeah, same question... Furthermore, we have a problem that poll_link() may succeed even when the auto-neg initial setting is for different network switch type, and the network card does not work on this case. We retry auto-neg with the another initial setting on this case. See above, could you give some more details why this is the case. Or maybe Ben knows more about this ? No, I'm surprised too. Ben. - 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
Re: spidernet: dynamic phy setup code
We use bcm5461. There is a possibility that we don't know the appropriate setting which is applicable for both type of switches. Have you tested the existing 54xx code in sungem_phy.c ? We use that with 5462 at least in K2 and all sorts of 54xx chips and it works fine... Just setup the right advertisement bits and call setup_aneg in the PHY ops. You don't even need to implement the forced fallback code that is in sungem. It's not necessary with most broadcom PHYs as they do that themselves, just setup aneg and poll the link from a timer, that's it. Once you get a link, then setup your GMACMODE based on the link speed. I don't have the datasheet of the 5461 at hand but I doubt it's any different... Like other Broadcom 54xx PHYs, it might need some special initialization code to work around firmware bugs though... We didn't investigate for the detail, but we met the following phenomena. 1. When auto-neg starts with Gbps setting and ethernet card is connected to a 100Mbps switch, LINK is not detected. 2. When auto-neg starts with 100/10Mbps setting and ethernet card is connected to Gbps switch, LINK is detected (poll_link() succeeds), but the network is not available. That is very strange... I would need to review your code in more details or eventually have HW access to run my own experiments, but none of this should happen if things are setup properly. Also avoid relying on the link interrupt, it's a known cause of trouble. Just poll. Ben. - 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
Re: [RFC][PATCH][XFRM][0/5] extension for XFRM databases
Shinta-san, let me know when an updated version of your patches are available, I'd like to include them in 2.6.21 Thank you. - 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
Re: [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Wed, 31 Jan 2007 14:42:50 +0900 (JST) [IPV6] ROUTE: Do not route packets to link-local address on other device. With help from Wei Dong [EMAIL PROTECTED]. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Applied, thank you. - 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
Re: [RFC][PATCH][XFRM][0/5] extension for XFRM databases
Dear David, Thank you for your consideration. Updated patches will be ready by Feb 7th (Wednesday) 22:00 JST at the latest. Hopefully I can send them earlier, after finishing tests for the kernel with the patch set that incorporates all the comments received. Regards, Shinta On Sun, 04 Feb 2007 16:56:42 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: Shinta-san, let me know when an updated version of your patches are available, I'd like to include them in 2.6.21 Thank you. - 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 - 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
Re: [PATCH 2.6.19 2/2] X.25: Adds /proc/net/x25/forward to view active forwarded calls.
From: ahendry [EMAIL PROTECTED] Date: Thu, 04 Jan 2007 14:37:15 +1100 View the active forwarded call list cat /proc/net/x25/forward Signed-off-by: Andrew Hendry [EMAIL PROTECTED] Applied, thanks a lot. - 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
Re: when having to acquire an SA, ipsec drops the packet
From: James Morris [EMAIL PROTECTED]
Date: Thu, 1 Feb 2007 18:44:48 -0500 (EST)
A quick dirty solution, which is what I think the BSD kernels do, is to
still drop the packet but just not return an error to the app. The app
then just sees a slight delay on the initial connection, as if a DNS
lookup took a bit longer than usual.
I have another idea.
Why don't we just flat-out ignore MSG_DONTWAIT for the socket
visible cases, and handle connect() similarly?
I think this is (just barely) legal, will be simple to implement, and
will leave us with semantics that look like:
1) Sockets never see -EAGAIN due to SA resolution. They'll just
pause until the route is resolved, even with O_NONBLOCK or
MSG_DONTWAIT.
2) Asynchronous contexts such as ICMP replies and firewalling
will still see the -EAGAIN and simply drop packets.
These sleeps are legal because all of the socket paths involved
have to be able to do lock_socket() (at a minimum) anyways.
Something like this (untested) on the ipv4 side, for example:
diff --git a/include/net/route.h b/include/net/route.h
index 486e37a..a8af632 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
static inline int ip_route_connect(struct rtable **rp, __be32 dst,
__be32 src, u32 tos, int oif, u8 protocol,
- __be16 sport, __be16 dport, struct sock *sk)
+ __be16 sport, __be16 dport, struct sock *sk,
+ int flags)
{
struct flowi fl = { .oif = oif,
.nl_u = { .ip4_u = { .daddr = dst,
@@ -168,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
__be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, fl);
- return ip_route_output_flow(rp, fl, sk, 0);
+ return ip_route_output_flow(rp, fl, sk, 1);
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 90c74b4..fa2c982 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -72,7 +72,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
int addr_len)
tmp = ip_route_connect(rt, nexthop, inet-saddr,
RT_CONN_FLAGS(sk), sk-sk_bound_dev_if,
IPPROTO_DCCP,
- inet-sport, usin-sin_port, sk);
+ inet-sport, usin-sin_port, sk, 1);
if (tmp 0)
return tmp;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 8640096..5750a2b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1007,7 +1007,7 @@ static int inet_sk_reselect_saddr(struct sock *sk)
RT_CONN_FLAGS(sk),
sk-sk_bound_dev_if,
sk-sk_protocol,
- inet-sport, inet-dport, sk);
+ inet-sport, inet-dport, sk, 0);
if (err)
return err;
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 7b068a8..0072d79 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -49,7 +49,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
err = ip_route_connect(rt, usin-sin_addr.s_addr, saddr,
RT_CONN_FLAGS(sk), oif,
sk-sk_protocol,
- inet-sport, usin-sin_port, sk);
+ inet-sport, usin-sin_port, sk, 1);
if (err)
return err;
if ((rt-rt_flags RTCF_BROADCAST) !sock_flag(sk, SOCK_BROADCAST)) {
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index a6c63bb..fed6a1e 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -489,7 +489,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
}
security_sk_classify_flow(sk, fl);
- err = ip_route_output_flow(rt, fl, sk,
!(msg-msg_flagsMSG_DONTWAIT));
+ err = ip_route_output_flow(rt, fl, sk, 1);
}
if (err)
goto done;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f061ec5..383e4b5 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -191,7 +191,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
int addr_len)
tmp = ip_route_connect(rt, nexthop, inet-saddr,
RT_CONN_FLAGS(sk), sk-sk_bound_dev_if,
IPPROTO_TCP,
- inet-sport, usin-sin_port, sk);
+ inet-sport, usin-sin_port, sk, 1);
if (tmp 0)
return tmp;
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index cfff930..8b54c68 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -629,7 +629,7 @@
forcedeth problems on 2.6.20-rc6-mm3
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64. Any suggestions on how to debug/what to try reverting to see what's causing this? -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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
Re: forcedeth problems on 2.6.20-rc6-mm3
On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock [EMAIL PROTECTED] wrote: Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64. Any suggestions on how to debug/what to try reverting to see what's causing this? There are many forcedeth changes in git-netdev-all.patch. Can you try reverting drivers/net/forcedeth.c back to the unpatched version from 2.6.20-rc6? Thanks. - 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
Re: Unexpected Acknowledgement / Stalled Connections
* Parag Warudkar [EMAIL PROTECTED] [070205 00:57]: On 2/4/07, Parag Warudkar [EMAIL PROTECTED] wrote: I am running 2.6.20 and have trouble with stalled connections. For instance, if I try to download a debian ISO image using wget, the connection runs fine for few seconds and then stalls for ever. In my router logs I see a ton of messages like the below - [INFO] Sun Feb 04 17:22:03 2007 Blocked incoming TCP packet from 192.168.0.174:34090 to 130.239.18.138:80 with unexpected acknowledgement 3269301836 (expected 3269343453 to 3269408989) Where 192.168.0.174 is my laptop running FC6 and kernel 2.6.20 and 130.239.18.138 is whatever cdimage.debian.org resolves to atm. What's going on here? Any TCP/IP tunable that I can set/turn on/off to prevent this from happening? Turning tcp_sack off seems to cure it. Turning it on again makes the connections stall. Seems like the D-Link router doesn't like the SACKs linux sends? You can also try to disable tcp_window_scaling. Can you provide a tcpdump trace of the connection? Traces with and without SACK would be appreciated, also a trace with SACK but without window scaling would be useful. I only need the headers of the packet so -s 60 (the default) will be fine. There was a change in 2.6.20 that I put but it should only have affected the sender side and even then only the way it interpreted the data and not things it sent on the wire. Trying the dl with previous kernels can also help, if only to try and pinpoint where things went bad, assuming it is in the kernel. This sounds like a bad implementation of ACK window checks that ICSA requires for firewall product certification. Baruch - 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
Re: forcedeth problems on 2.6.20-rc6-mm3
Andrew Morton wrote: On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock [EMAIL PROTECTED] wrote: Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64. Any suggestions on how to debug/what to try reverting to see what's causing this? There are many forcedeth changes in git-netdev-all.patch. Can you try reverting drivers/net/forcedeth.c back to the unpatched version from 2.6.20-rc6? Thanks. That's essentially what I did, it didn't appear to help. I assume the problem must lie elsewhere.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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
Re: forcedeth problems on 2.6.20-rc6-mm3
On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock [EMAIL PROTECTED] wrote: Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64. Any suggestions on how to debug/what to try reverting to see what's causing this? There are many forcedeth changes in git-netdev-all.patch. Can you try reverting drivers/net/forcedeth.c back to the unpatched version from 2.6.20-rc6? Thanks. That's essentially what I did, it didn't appear to help. I assume the problem must lie elsewhere.. doh, I missed that. It's presumably not the driver and nobody else seems to be hitting this, so it must be something peculiar to your setup. But I don't know what it might be, sorry. - 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
Re: forcedeth problems on 2.6.20-rc6-mm3
On Sun, 4 Feb 2007, Robert Hancock wrote: Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect. -Daniel *This .sig left intentionally blank* - 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
Re: [PATCH 1/3] Advance fast path pointer for first block only
From: Baruch Even [EMAIL PROTECTED] Date: Fri, 02 Feb 2007 16:41:16 +0200 Only advance the SACK fast-path pointer for the first block, the fast-path assumes that only the first block advances next time so we should not move the cached skb for the next sack blocks. Signed-Off-By: Baruch Even [EMAIL PROTECTED] Looks great, patch applied, thanks! - 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
Re: [PATCH 2/3] Seperate DSACK from SACK fast path
From: Baruch Even [EMAIL PROTECTED] Date: Fri, 02 Feb 2007 16:41:21 +0200 Move DSACK code outside the SACK fast-path checking code. If the DSACK determined that the information was too old we stayed with a partial cache copied. Most likely this matters very little since the next packet will not be DSACK and we will find it in the cache. but it's still not good form and there is little reason to couple the two checks. Since the SACK receive cache doesn't need the data to be in host order we also remove the ntohl in the checking loop. Signed-Off-By: Baruch Even [EMAIL PROTECTED] Thanks for fixing up the endianness annotations, applied. - 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
Re: [PATCH 3/3] Check num sacks in SACK fast path
From: Baruch Even [EMAIL PROTECTED] Date: Fri, 02 Feb 2007 16:41:27 +0200 We clear the unused parts of the SACK cache, This prevents us from mistakenly taking the cache data if the old data in the SACK cache is the same as the data in the SACK block. This assumes that we never receive an empty SACK block with start and end both at zero. Signed-Off-By: Baruch Even [EMAIL PROTECTED] I've applied this one too, thanks a lot. - 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
