Jivin Evgeniy Polyakov lays it down ... ... > > ACRYPTO_TYPE_AES_??? depending on ctx->current_key_len. Good. > > - You need a software queue in case your HW queue is full and you receive > > a requests which you may not drop. Currently you don't consider > > CRYPTO_TFM_REQ_MAY_BACKLOG (it is fine if you can process all requests > > no mater what). > > That is what I do not like, but will implement. I have to agree, you cannot queue crypto forever (no drops), it's too slow. There is a similar queue in OCF and unless you put a limit on it's size you can easily run you system out of memory. The Q needs a configurable limit of some kind. Flood ping an ipsec tunnel and the crypto is where all the data will bank up. If I understand what you are asking Evgeniy to do, you will be putting the logic for managing the Q into every driver. Sounds like something that needs to move up a level ? Cheers, Davidm -- David McCullough, david_mccullough@xxxxxxxxxxxxxxxxxxx, Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
