Re[2]: Re-writing the 2.6.11.8 Kernel IPsec stack for hardware crypto offload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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()???

>> Cheers,
>> Davidm
>> 


--

Dan Searle
Adelix Ltd
dan.searle@xxxxxxxxxx web: www.adelix.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: The Old Post Office, Bristol Rd, Hambrook, Bristol BS16 1RY. UK.

Any views expressed in this email communication are those
of the individual sender, except where the sender specifically states
them to be the views of a member of Adelix Ltd.  Adelix Ltd. does not
represent, warrant or guarantee that the integrity of this communication
has been maintained nor that the communication is free of errors or
interference.

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

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux