+ ceph-devel > Recently I tried vpp instead of current dpdk implementation, the performance > improved little not as much as expected. I have some questions about > seastar you are working now. > > > > 1. Why we need merge new seastar, Haomai has merged old seastar > version, what is the reason we update it? Or the new seastar will give i think Haomai reused part of it for implementing the DPDK backend of async messenger. our long term plan is to rewrite the *whole* OSD stack for better performance. > better performance? > > 2. Do you have any test result that seastar will help in performance > for ceph? i don't have the profiling statistics justifying the planned change. but i think the share-nothing architecture of seastar aligns with our general goal: 1) lock-less, 2) kernel bypass, 3) no mem copy, i.e. DMA whenever possible. 4) and better readablity =) > > 3. This time seastar will work as a library or like Haomai did we copy > all the code ceph need? If seastar provide interface for application call > it? we plan to integrate seastar as a git submodule, as it's a programming framework. > > 4. Can you tell me the current status of your work, I am wondering if > we can help in merging seastar? sure. see http://pad.ceph.com/p/updates-on-seastar. the git branch is at https://github.com/tchaikov/ceph/tree/wip-seastar. the seastar changes are still pending on review. and they need more work before getting accepted by upstream. there's lots of work to do. we can continue the discussion here, or on CDM. the next thing we need to address would be a lockless logging system and the config subsystem. ideally, they should be compatible with the existing ones. so we can have minimal changes to other parts of Ceph. -- Regards Kefu Chai -- 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
