Hi, Please see my comments below... Friday, May 20, 2005, 12:31:56 PM, you 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 :-) So you really think that dropping the frames is a good solution? I realise that if further up the stack the frames are to do with a TCP/IP connection, dropping frames will equate to dropping IP packets, and hence, the TCP stack windowing will take care of flow control eventually. However, what about higher level protocols which have no flow control, like UDP? Is it really a good idea to drop frames if they are coming in too fast? I suppose even if there were a flow control mechanism in the Kernel NET stack like I describe, eventually, some process is going to have to drop the frames, so yeh, I can sort of see what you're getting at. 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? > Cheers, > Davidm Many thanks again, this discussion has enlightened me greatly! Dan... -- 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
