Jivin Evgeniy Polyakov lays it down ... > On Fri, 2005-05-20 at 21:31 +1000, David McCullough 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 :-) > > Unfortunately we say to stack that it is ok to send data to us > at such a rate, but drop will happens silently... Absolutely, better to get the packet and at least tell someone you dropped it than spin in a loop. > We may try to set some flag in crypto engine [at least acrypto has it] Yeah, OCF drivers can return that they are out of resources and the OCF layer blocks that driver until it specifically unblocks itself. > that device is broken, and in esp_output() return negative value - > this error code will be propagated to the callers and queues. > From the other point we can simulate dev/ip_queue_xmit behaviour. 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
