Hi Jamal, dev_close() is doing quite a lot of stuff, so we should do nothing more than flush the qdiscs when the link comes up. But is it really useful? Normally, the queues are short anyway to keep
Indeed it is, infact i have been bitten by buffered packets confusing an upstream switch with buffered VRRP packets when someone stepped on a cable that i later reconnected. Typically about 30 second
Hi Jamal, dev_close() is doing quite a lot of stuff, so we should do nothing more than flush the qdiscs when the link comes up. But is it really useful? Normally, the queues are short anyway to keep
Indeed it is, infact i have been bitten by buffered packets confusing an upstream switch with buffered VRRP packets when someone stepped on a cable that i later reconnected. Typically about 30 second
Hi David, I've updated my RFC2863 operstatus and userspace forwarding patch to 2.5.49. As discussion on netdev seems to be complete, I need some comment from your side. Stefan diff -uprNX dontdiff li
This locking below achieves nothing. + read_lock_irqsave(&dev->operstate_lock, flags); + state = dev->operstate; + read_unlock_irqrestore(&dev->operstate_lock, flags); In fact, the other side, lockin
Hi, Ok, so I was too cautious by locking read access to a one byte structure. I'll change that and read additional documentation on SMP ;-) Right now, I don't see which. There are other spinlocks ava
Stefan, Just thought of something, it may be a little tricky but valuable and i am not quiet sure if it should part of your patch: We probably need to flush the qdiscs software queues; maybe even the