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

 



On Fri, 2005-05-20 at 13:18 +0100, Dan Searle wrote:
> Hi,
> 
> Please see my comments below...
> 
> Friday, May 20, 2005, 12:55:20 PM, you wrote:
> 
> >> 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.
> 
> That's correct, if I try to dispatch a buffer to the IXP crypto engine
> it may return an error saying the queue is full. To which I should
> react by dropping the skb, and return an error condition.

The problem is that error can occure after dispatching from network
stack - 
for example you have a descriptor, you successfully set all registers
up, 
but while processing the data adapter was broken, suspended, anything - 
we can not propagate such errors to the caller.

> I've been looking, and would it be a good idea to return: NET_XMIT_CN
> from esp_output() and/or esp_input() if I have to drop the frame
> because the HW crypto engine's queue is full?
> 
> It looks that way, but I have no idea if the caller to esp_output()
> and/or esp_input() know how to react to NET_XMIT_CN.

With UDP NET_XMIT_CN will be transformed into -ENOBUFS.
As far as i know only qdisc can return it now.

> Regards, Dan...
> 
> > Cheers,
> > Davidm
> 
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachment: signature.asc
Description: This is a digitally signed message part


[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