* David S. Miller <[EMAIL PROTECTED]> 2005-07-05 14:35 > From: Thomas Graf <[EMAIL PROTECTED]> > Date: Tue, 5 Jul 2005 23:28:10 +0200 > > > Can we agree on NET_XMIT_CN? The dev_xmit callers handle it the same > > way as NET_XMIT_SUCCESS but we still have a chance to check for this > > behaviour within the parent qdisc. > > It's not congestion, the packet went in fine. > > Call it sch_congestiondrop.c if that's how you want it to behave. I > think if it's a blackhole, it should behave like a true blackhole. > > It might become prudent to make TCP do something in response > to NET_XMIT_CN (sadly, tcp_transmit_skb() currently does nothing) > at some point. > > NET_XMIT_CN means "backoff", or "we're overloaded". Blackhole > should be a silent drop, thus NET_XMIT_SUCCESS.
I derived this hack from noop/noqueue qdisc which drops and returns NET_XMIT_CN. I guess that needs to be changed as well in this case. > If you want notification to be passed around to parent qdiscs, > create some kind of true attribute passing in the queueing framework, > not some hack like this. Ok, I'll just fall back to NET_XMIT_SUCESS for now and will revisit this once we've discussed the preferred communication schema. - 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
