Messages in this thread | | | Subject | Re: [patch 4/10] s390: network driver. | From | jamal <> | Date | 06 Dec 2004 06:27:59 -0500 |
| |
On Sun, 2004-12-05 at 01:25, Paul Jakma wrote: [..] > Anyway, we do, I think, need some way to deal with the > sending-stale-packet-on-link-back problem. Either a way to flush this > driver queue or else a guarantee that writes to sockets whose > protocol makes no reliability guarantee will either return ENOBUFS or > drop the packet. > > Otherwise we will start getting reports of "Quagga on Linux sent an > ancient {RIP,IRDP,RA} packet when we fixed a switch problem, and it > caused an outage for a section of our network due to bad routes", I > think. > > Some comment or advice would be useful. (Am I kill-filed by all of > netdev? feels like it).
Dont post networking related patches on other lists. I havent seen said patch, but it seems someone is complaining about some behavior changing?
In regards to link down and packets being queued. Agreed this is a little problematic for some apps/transports. TCP is definetely not one of them. TCP in Linux actually is told if the drop is local. This way it can make better judgement (and not unnecesarily adjust windows for example). SCTP AFAIK is the only transport that provides its apps opportunity to obsolete messages already sent. I am not sure how well implemented or whtether it is implemented at all. Someone working on SCTP could comment.
In the case the netdevice is administratively downed both the qdisc and DMA ring packets are flushed. Newer packets will never be queued and you should quickly be able to find from your app that the device is down. In the case of netdevice being operationally down - I am hoping this is what the discussion is, having jumped on it - both queues stay intact. What you can do is certainly from user space admin down/up the device when you receive a netlink carrier off notification. I am struggling to see whether dropping the packet inside the tx path once it is operationaly down is so blasphemous ... need to get caffeine first.
cheers, jamal
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |