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 :-) 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
