On Fri, 2005-05-20 at 12:47 +0100, Dan Searle wrote:
> Hi,
>
> Please see comments below...
>
> Friday, May 20, 2005, 12:48:15 PM, you wrote:
>
> > 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...
> > We may try to set some flag in crypto engine [at least acrypto has it]
> > 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.
>
> Please refer to my previous reply to Davidm RE: dropping frames within
> esp_output if the crypto buffers are full.
>
> If I return a negative value from esp_output(), doesn't this cause the
> entire Security Association to become invalid? What I'm asking is,
> what is the exact meaning of returning -1 from esp_output()???
You can return error code there.
I do not see how SA will become invalid if it returns an error.
> >> Cheers,
> >> Davidm
> >>
>
>
> --
>
> Dan Searle
> Adelix Ltd
> dan.searle@xxxxxxxxxx web: www.adelix.com
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
Attachment:
signature.asc
Description: This is a digitally signed message part
