Re: "ip_dynaddr" broken in 2.4.0-test10

> "Steffen" == Steffen Moser <[EMAIL PROTECTED]> writes: >> Does this fix it? >> >> echo "1" >/proc/sys/net/ipv4/ip_nonlocal_bind Steffen> I tried this - but no success. The problem persists... I just wrote a tool that does re-sending and address-rewriting of the first pack

Re: af_packet: recvfrom causing high processor load in system

> "Alexander" == Alexander Riesen <[EMAIL PROTECTED]> writes: Alexander> Hi, dear community, The problem: under heavy network Alexander> load (2000 frame/sec and more, traffic produced with Alexander> Fluke) reading from the packet socket (SOCK_PACKET) Are you using ETH_P_ALL? H

Re: Protocol 0008 is buggy

Hi, > "Ivan" == Ivan Passos <[EMAIL PROTECTED]> writes: Ivan> Hello, Ivan> I have a customer who's getting tons of this msg in his Ivan> LOGs: Ivan> kernel: protocol 0008 is buggy, dev hdlc0 Ivan> The msg comes from net/core/dev.c, and this device is using Ivan> t

Re: [PATCH/RFC] (long) network interface changes

> "jamal" == jamal <[EMAIL PROTECTED]> writes: >> Nice. I think such a kind of fair input queueing would be an >> important features because that allows to offer a highly >> reliable netif() to slow links which are slow, but inefficient >> to handle congestion (like X.25 LAPB

Re: Q: sock output serialization

> "jamal" == jamal <[EMAIL PROTECTED]> writes: jamal> Packets in flight? >> In the extreme case, there could still arrive up to the window >> size frames. jamal> Assuming this depends on path latency and not some bad jamal> programming Yes. Although the latter could al

Re: [PATCH/RFC] (long) network interface changes

> "jamal" == jamal <[EMAIL PROTECTED]> writes: [...] Nice introduction! jamal> The driver uses the feedback information to intelligently jamal> adjust its sending rate. (i.e reduce or increase calls to jamal> netif_rx() or send a congestion-experienced frame to its jamal>

Re: Q: sock output serialization

> "jamal" == jamal <[EMAIL PROTECTED]> writes: jamal> Hmm.. More complexity ;-> Does X.25 mandate you accept all jamal> the window? No. Just, if you do not accept a frame, you must not acknowledge it. Once it has been acknowledged, you must not discard it. jamal> Can you stop m

Re: Q: sock output serialization

Hi, > "jamal" == jamal <[EMAIL PROTECTED]> writes: >> With the current scheme, lapb first acknowleges reception of >> the frame and after that, netif_rx() might still discard it -- >> which is evil. >> jamal> This might screw things a bit. Can you defer to say first

Re: Q: sock output serialization

> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes: Andi> It would just be racy. You test, get a not drop and then Andi> another different interrupt would deliver another packet Andi> before you can and fill the queue. Jamal's extended Andi> netif_rx probably makes more sense,

Re: Q: sock output serialization

Hi, > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: >> However, for drivers which support intelligent controllers >> (with lapb in firmware) this is not an option and the problem >> will persist. Alan> 'Smart hardware is broken' repeat .. ;) - but yes its an Alan> issu

Re: Q: sock output serialization

Hi, > "kuznet" == kuznet <[EMAIL PROTECTED]> writes: kuznet> Hello! >> scheduler may re-order frames kuznet> It cannot, provided sender holds order until kuznet> dev_queue_xmit(). But if I set different skb->priority? ;) Well that would be my fault than .. >> or dro

Re: Q: sock output serialization

Hi, > "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: Alan> LAPB does not expect ever to see re-ordering. Its a point to Alan> point wire level MAC protocol. Yes, it was never designed for handling re-ordering because this cannot happen on a single wire (and for that reason it is no

Re: Q: sock output serialization

Hi, > "David" == David S Miller <[EMAIL PROTECTED]> writes: David>It smells rotten to the core, can someone tell me David> exactly why reordering is strictly disallowed? I do not David> even know how other OSes can handle this properly since David> most, if not all, use

Re: Q: sock output serialization

Hi, > "kuznet" == kuznet <[EMAIL PROTECTED]> writes: >> when sk->lock.users!=0. Is there a particular reason why such >> task queue does not exist? kuznet> Because it appeared to be useless overhead. I also kuznet> believed that it will be required in tcp, but one day I

Re: Q: sock output serialization

Hi, > "kuznet" == kuznet <[EMAIL PROTECTED]> writes: >> Anyway, it seems that I can already make use the lock_sock() >> infrastructure for fixing the output serialization, even >> without making the whole protocol stack SMP-aware at once. kuznet> Actually, the last task is

Re: Q: sock output serialization

Hi, > "kuznet" == kuznet <[EMAIL PROTECTED]> writes: kuznet> Hello! kuznet> In input path you have a packet. Add it to backlog and kuznet> processing will be resumed after lock is released. Compare kuznet> with tcp. >> serializing the kick. Well, maybe my solution cou

Re: Q: sock output serialization

Hi, > "kuznet" == kuznet <[EMAIL PROTECTED]> writes: kuznet> Hello! >> atomic_inc(&sk->protinfo.x25->kick_it); >> if((atomic_read(&sk->protinfo.x25->kick_it)) != 1) return; >> >> do { __x25_kick(sk); } while >> (!atomic_dec_and_test(&sk->protinfo.x25->kic

Q: sock output serialization

Hi, Is the following fix clean or are there better solutions? There is a race condition in the Linux X.25 protocol stack. The stack has an x25_kick() function which dequeues as many skb´s from sk->write_queue as the send windows allows and sends them downwards. This kick function is called fro