Jivin Dan Searle lays it down ... > Hi, > > Please see my comments below... > > Friday, May 20, 2005, 12:31:56 PM, you wrote: > > > Jivin Dan Searle lays it down ... > >> Hi, > >> > >> Thanks, the async esp patch looks like exactly what I want! However, > >> I can see a potential problem still. > >> > >> Lets assume I have this async esp output function implemented, making > >> calls directly to the IXP400 access libs crypto dispatch function. > >> Packets start coming in and we call the crypto dispatch function which > >> queues the requests inside the IXP400 libs and the hardware somewhere. > >> Now, lets say the crypto engine can crypt at 50Mbit/sec, this means we > >> are being called back with crypted packets at a rate of 50Mbit/sec, > >> which is great. However, lets say the packets are coming in at a > >> higher rate, say 60Mbit/sec. After a short while the IXP400 queue will > >> fill up and our calls to the crypto dispatch function will cause an > >> error, and we will have to either a) drop the frame, or b) busy wait > >> until the IXP400 queue is no longer full and we can dispatch again. > >> > >> Dropping frames is not a very good solution, busy waiting isn't either > >> as this is exactly what I'm trying to avoid. So, what I need is to > >> tell the Kernel NET stack to stop sending packets to the esp input/output > >> functions via some kind of flow-control "XOFF" call. > > > If the frames are coming in at 60Mbit/s or higher and you busy wait you are > > probably going to drop the packets anyway, just somewhere else in the > > process :-) > > So you really think that dropping the frames is a good solution? I Not if you have a choice :-) > realise that if further up the stack the frames are to do with a > TCP/IP connection, dropping frames will equate to dropping IP packets, > and hence, the TCP stack windowing will take care of flow control > eventually. However, what about higher level protocols which have no > flow control, like UDP? Is it really a good idea to drop frames if > they are coming in too fast? > > I suppose even if there were a flow control mechanism in the Kernel > NET stack like I describe, eventually, some process is going to have > to drop the frames, so yeh, I can sort of see what you're getting at. On transmit there are most certainly a lot more options, but once you decouple from the "sender" it's hard to tell them you failed to deliver. > So, say esp_output is called, I try to dispatch the skb to the crypto > engine, which returns an error because it's queue is full. I then want > to drop the frame (drop the skb) from within esp_output(). What is the > correct way of doing this? Do I just free the skb and never call > dst_output() with it? Are there some frame counter statistics which > need updating to register the fact we have dropped the frame? I can't tell you specifically as I haven't been looking at that code. But the "out of resources" problem will most likely happen synchronously, at least whenever I have hit resource limits on the ixp access lib, the initial call into it fails rather than having to wait for a callback to find out. Providing that is the case you would handle it just as esp_output currently handles "out of resource" problems. Cheers, Davidm -- David McCullough, davidm@xxxxxxxxxxxx Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
