On Wed, Oct 23, 2019 at 11:53 AM Thomas Monjalon <tho...@monjalon.net> wrote: > > 23/10/2019 04:50, Jerin Jacob: > > In past, there was a concern with this approach about maintaining the > > assembly code in dpdk.org. Is this concern still valid? > [...] > > DPDK does not define any such interface. It was pushed to external library > > for the reason mentioned above. > > Yes it is questionable to host some asm code which is doing a processing > not really specific to DPDK.
Currently, it is doing the DPDK specific processing like kernel code as asm code. > Also, my first thought was that this library could be used by other projects. OK. > Another concern about integrating this crypto lib in DPDK is to know > whether it would have an impact on DPDK packaging and delivering? See below. > I don't remember any answer about legal export of this crypto processing. I don't think, we ran through the legal check on this. But this can be a genuine issue from the above list. Not sure how Linux kernel handles this case. > >
