No.no.. That is not a flag for particular request... The flag is how total hash will be handled... FINUP flag means that client will call finup(). So it will be update() update() ... update() finup() not update() ... update() final()... In other words... update() means that it will be more data coming (like MSG_MORE) finup() is just final update... Basically driver on update() will not do extra buffering.. Is it clear now? How would you solve such issue? - Dmitry On 27/01/11 01:32, ext Herbert Xu wrote: > On Wed, Jan 26, 2011 at 09:47:27AM +0200, Dmitry Kasatkin wrote: >> I am not talking about user space API at all. >> >> I talk about kernel crypto API and kernel clients. >> >> Please understand the following: when update() is called driver does not >> know if it is last update or not... >> That is essential. >> If client code would always use update/finup then it is fine.. >> But original API and clients uses update/final... >> That is why some way (flag) needed to tell if finup() will be used or not... >> >> It gave up 20% performance improvement in some case because no extra >> memcpy has been done... >> >> If you think about other solution, please share... > If the crypto user can set the FINUP flag then it can just call > finup, simple. > > Cheers, -- 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
