In this case I would like to propose isa-l extension for zlib plugin - https://github.com/ceph/ceph/compare/master...Ved-vampir:zlib_isal_extension?expand=1 I think, it would be better to choose plugin type based on processor type, this variant is used in branch. To add tuned option on the step of plugin loading is possible too, but here we can get an assert in case, if processor type is not compatible. Or it will be better nevertheless to keep this option and leave error treatment for plugin user? About isa-l lib files. The only change, that I made to them, is renaming asm files to asm.s, but I suspect this restriction can be bypassed by some options in make/cmake files? In this way I think it would be better to create submodule repo for isa-l lib, because I'm still thinking, that just making a copy is not a very good way. ------------------------------- Best regards, Alyona Kiseleva On Fri, Jun 17, 2016 at 7:47 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Sat, 18 Jun 2016, Haomai Wang wrote: >> Cool, I guess it should be behavior better than others in intel platform. >> >> On Fri, Jun 17, 2016 at 11:51 PM, Alyona Kiselyova >> <akiselyova@xxxxxxxxxxxx> wrote: >> > Hi, >> > I would like to propose a new compression plugin, which is based on >> > Isa-l open source library >> > (https://github.com/01org/isa-l/tree/master/igzip). I already have a >> > code - https://github.com/Ved-vampir/ceph/tree/wip_isal_plugin/src/compressor/isal. >> > I see, that there are erasure-code plugin, based on isa-l too. As I >> > see, library code is not loaded as submodule repo, like some others. > > In this case, I assume the inflate/deflate encoding is compatible with > zlib. If that's the case, I think we don't want to treat this as a > different compression type, but rather as an optimized > implementation of the same type. > > Not sure the best way to do that, though. The simplest would probably be > to make the ZlibCompressor either use zlib or isal based on an option > and/or processor type. > >> > But if I'm right, I think, it's not the best way to use external code. >> >> Sorry, why it's not a best way? >> >> > The question is, what is the right way to use external library in my case? >> >> I think maybe we could make the whole >> repo(https://github.com/01org/isa-l) as submodule and make each dir >> used by different compoent? > > In the crc case we just copied the relevant asm files into the ceph repo. > That's probably not the best path, though. I think we had to make some > minor changes to make them build, too. :/ > > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
