Introduce the request handling for dm-crypt

When we use dm-crypt to decrypt block data, it will decrypt the block data in endio() when one IO is completed. In this situation we don't want the cloned bios is freed before calling the endio().

Thus introduce 'BIO_ENDIO_FREE' flag to support the request handling for dm-crypt, this flag will ensure that blk layer does not complete the cloned bios before completing the request. When the crypt endio is called, post-processsing is done and then the dm layer will complete the bios (clones) and free them.

include/linux/device-mapper.h +0 -0

index 76d23fa..f636c50 100644
@@ -407,6 +407,11 @@ union map_info *dm_get_rq_mapinfo(struct request *rq);
 

Quoted 4 lines · Baolin Wang

When we use dm-crypt to decrypt block data, it will decrypt the block data in endio() when one IO is completed. In this situation we don't want the cloned bios is freed before calling the endio().

Quoted 4 lines

Thus introduce 'BIO_ENDIO_FREE' flag to support the request handling for dm-crypt, this flag will ensure that blk layer does not complete the cloned bios before completing the request. When the crypt endio is called, post-processsing is done and then the dm layer will complete the bios (clones) and free them.

Not following why request-based DM's partial completion handling (drivers/md/dm.c:end_clone_bio) isn't a sufficient hook -- no need to add block complexity.

But that aside, I'm not liking the idea of a request-based dm-crypt.

Quoted 8 lines

include/linux/device-mapper.h +0 -0

index 76d23fa..f636c50 100644
@@ -407,6 +407,11 @@ union map_info *dm_get_rq_mapinfo(struct request *rq);
 
 struct queue_limits *dm_get_queue_limits(struct mapped_device *md);
 

include/linux/device-mapper.h union map_info *dm_get_rq_mapinfo(struct request *rq); · line 417

Quoted 8 lines

include/linux/device-mapper.h +5 -0

+void dm_end_request(struct request *clone, int error);
+void dm_kill_unmapped_request(struct request *rq, int error);
+void dm_dispatch_clone_request(struct request *clone, struct request *rq);
+struct request *dm_get_orig_rq(struct request *clone);
+
 /*
  * Geometry functions.
  */

I have no interest in seeing any request-based DM interfaces exported.

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 16 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

Quoted 6 lines

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

Because as Mike had said there are downsides to having request based dm-crypt as well. E.g. if you want to have encrypted raid5 volume then you'd rather want to put encryption on top of raid5 (easier management, larger sequential blocks to encrypt, ...) but you cannot do that when dm-crypt would be request based. So modifying bio-based dm-crypt to form larger chunks for encryption HW would be superior in this regard.

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR

Quoted 24 lines · Jan Kara

Quoted 22 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 3 lines

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

It depends on the hardware design. My beaglebone black board's AES engine can handle 1M at one time which is not big. As I know some other AES engine can handle 16M data at one time or more.

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

Quoted 25 lines · Baolin Wang

Quoted 24 lines · Jan Kara

Quoted 22 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 7 lines

Quoted 3 lines

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

It depends on the hardware design. My beaglebone black board's AES engine can handle 1M at one time which is not big. As I know some other AES engine can handle 16M data at one time or more.

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Quoted 6 lines

Quoted 5 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Quoted 3 lines

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR

Quoted 34 lines · Jan Kara

Quoted 25 lines · Baolin Wang

Quoted 24 lines · Jan Kara

Quoted 22 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 7 lines

Quoted 3 lines

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

It depends on the hardware design. My beaglebone black board's AES engine can handle 1M at one time which is not big. As I know some other AES engine can handle 16M data at one time or more.

Quoted 6 lines

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Quoted 6 lines

Quoted 3 lines

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

I'm sorry I didn't check it. What's the limitation of one bio on 4.3?

Quoted 42 lines · Baolin Wang

Quoted 34 lines · Jan Kara

Quoted 25 lines · Baolin Wang

Quoted 24 lines · Jan Kara

Quoted 22 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 7 lines

Quoted 3 lines

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

It depends on the hardware design. My beaglebone black board's AES engine can handle 1M at one time which is not big. As I know some other AES engine can handle 16M data at one time or more.

Quoted 6 lines

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Quoted 7 lines

Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage.

No, I meant something different. I meant that if HW can encrypt 1M in say 1.05 ms and it can encrypt 16M in 16.05 ms, then although using 16 M blocks gives you some advantage it becomes diminishingly small.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

Quoted 4 lines

Quoted 2 lines

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

I'm sorry I didn't check it. What's the limitation of one bio on 4.3?

On 4.3 it is 1 MB (which should be enough because requests are limited to 512 KB by default anyway). Previously the maximum bio size depended on the queue parameters such as max number of segments etc.

Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR

Quoted 17 lines · Jan Kara

Quoted 15 lines · Baolin Wang

Quoted 6 lines · Jan Kara

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage.

Quoted 4 lines

No, I meant something different. I meant that if HW can encrypt 1M in say 1.05 ms and it can encrypt 16M in 16.05 ms, then although using 16 M blocks gives you some advantage it becomes diminishingly small.

But if it encrypts 16M with 1M one by one, it will be much more than 16.05ms (should be consider the SW submits bio one by one).

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

Quoted 5 lines

Quoted 1 line

I'm sorry I didn't check it. What's the limitation of one bio on 4.3?

On 4.3 it is 1 MB (which should be enough because requests are limited to 512 KB by default anyway). Previously the maximum bio size depended on the queue parameters such as max number of segments etc.

But it maybe not enough for HW engine which can handle maybe 10M/20M at one time.

Quoted 2 lines · On Thursday 12 November 2015 20:51:10 Baolin Wang wrote:

But it maybe not enough for HW engine which can handle maybe 10M/20M at one time.

Given that you have already done measurements, can you find out how much you lose in overall performance with your existing patch if you artificially limit the maximum size to sizes like 256kb, 1MB, 4MB, ...?

Quoted 8 lines · Arnd Bergmann

Quoted 2 lines · On Thursday 12 November 2015 20:51:10 Baolin Wang wrote:

But it maybe not enough for HW engine which can handle maybe 10M/20M at one time.

Given that you have already done measurements, can you find out how much you lose in overall performance with your existing patch if you artificially limit the maximum size to sizes like 256kb, 1MB, 4MB, ...?

It's probably also worth looking at the impact on CPU utilisation as well as throughput in your benchmarking since the system will often not be idle when it's doing a lot of I/O - I know you've done some measurements in that area before, including them when looking at block sizes might be interesting.

Quoted 23 lines · On Thursday 12 November 2015 20:51:10 Baolin Wang wrote:

Quoted 21 lines · Jan Kara

Quoted 8 lines · Baolin Wang

Quoted 6 lines · Jan Kara

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Quoted 7 lines

Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage.

No, I meant something different. I meant that if HW can encrypt 1M in say 1.05 ms and it can encrypt 16M in 16.05 ms, then although using 16 M blocks gives you some advantage it becomes diminishingly small.

Quoted 2 lines

But if it encrypts 16M with 1M one by one, it will be much more than 16.05ms (should be consider the SW submits bio one by one).

The example that Jan gave was meant to illustrate the case where it's not much more than 16.05ms, just slightly more.

The point is that we need real numbers to show at what size we stop getting significant returns from increased block sizes.

Quoted 18 lines

Quoted 17 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

I'm sorry I didn't check it. What's the limitation of one bio on 4.3?

On 4.3 it is 1 MB (which should be enough because requests are limited to 512 KB by default anyway). Previously the maximum bio size depended on the queue parameters such as max number of segments etc.

Quoted 2 lines

But it maybe not enough for HW engine which can handle maybe 10M/20M at one time.

Given that you have already done measurements, can you find out how much you lose in overall performance with your existing patch if you artificially limit the maximum size to sizes like 256kb, 1MB, 4MB, ...?

Arnd

Quoted 51 lines · Jan Kara

Quoted 49 lines · Baolin Wang

Quoted 34 lines · Jan Kara

Quoted 25 lines · Baolin Wang

Quoted 24 lines · Jan Kara

Quoted 22 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 7 lines

Quoted 3 lines

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

It depends on the hardware design. My beaglebone black board's AES engine can handle 1M at one time which is not big. As I know some other AES engine can handle 16M data at one time or more.

Quoted 6 lines

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage.

Quoted 4 lines

No, I meant something different. I meant that if HW can encrypt 1M in say 1.05 ms and it can encrypt 16M in 16.05 ms, then although using 16 M blocks gives you some advantage it becomes diminishingly small.

But if it encrypts 16M with 1M one by one, it will be much more than 16.05ms (should be consider the SW submits bio one by one).

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

Quoted 5 lines

Quoted 1 line

I'm sorry I didn't check it. What's the limitation of one bio on 4.3?

On 4.3 it is 1 MB (which should be enough because requests are limited to 512 KB by default anyway). Previously the maximum bio size depended on the queue parameters such as max number of segments etc.

But it maybe not enough for HW engine which can handle maybe 10M/20M at one time.

Quoted 57 lines · Baolin Wang

Quoted 55 lines · Jan Kara

Quoted 42 lines · Baolin Wang

Quoted 34 lines · Jan Kara

Quoted 25 lines · Baolin Wang

Quoted 24 lines · Jan Kara

Quoted 22 lines · Baolin Wang

Quoted 7 lines · Christoph Hellwig

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 7 lines

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

NAK for more request based stacking or DM drivers. They are a major pain to deal with, and adding more with different requirements then dm-multipath is not helping in actually making that one work properly.

But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later).

Quoted 7 lines

Quoted 3 lines

So you've mentioned several times that hardware needs big blocks. How big those blocks need to be? Ideally, can you give some numbers on how the throughput of the encryption hw grows with the block size?

It depends on the hardware design. My beaglebone black board's AES engine can handle 1M at one time which is not big. As I know some other AES engine can handle 16M data at one time or more.

Quoted 6 lines

Well, one question is "can handle" and other question is how big gain in throughput it will bring compared to say 1M chunks. I suppose there's some constant overhead to issue a request to the crypto hw and by the time it is encrypting 1M it may be that this overhead is well amortized by the cost of the encryption itself which is in principle linear in the size of the block. That's why I'd like to get idea of the real numbers...

Quoted 7 lines

Please correct me if I misunderstood your point. Let's suppose the AES engine can handle 16M at one time. If we give the size of data is less than 16M, the engine can handle it at one time. But if the data size is 20M (more than 16M), the engine driver will split the data with 16M and 4M to deal with. I can not say how many numbers, but I think the engine is like to big chunks than small chunks which is the hardware engine's advantage.

No, I meant something different. I meant that if HW can encrypt 1M in say 1.05 ms and it can encrypt 16M in 16.05 ms, then although using 16 M blocks gives you some advantage it becomes diminishingly small.

Quoted 2 lines

But if it encrypts 16M with 1M one by one, it will be much more than 16.05ms (should be consider the SW submits bio one by one).

Really? In my example, it would take 16.8 ms if we encrypted 16M in 1M chunks and 16.05 ms if done in one chunk. That is a difference for which I would not be willing to bend over backwards. Now these numbers are completely made up and that's why I wanted to see the real numbers...

Quoted 18 lines

Quoted 17 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

You mentioned that you use requests because of size limitations on bios - I had a look and current struct bio can easily describe 1MB requests (that's assuming 64-bit architecture, 4KB pages) when we have 1 page worth of struct bio_vec. Is that not enough?

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Usually one bio does not always use the full 1M, maybe some 1k/2k/8k or some other small chunks. But request can combine some sequential small bios to be a big block and it is better than bio at least.

As Christoph mentions 4.3 should be better in submitting larger bios. Did you check it?

I'm sorry I didn't check it. What's the limitation of one bio on 4.3?

On 4.3 it is 1 MB (which should be enough because requests are limited to 512 KB by default anyway). Previously the maximum bio size depended on the queue parameters such as max number of segments etc.

Quoted 2 lines

But it maybe not enough for HW engine which can handle maybe 10M/20M at one time.

Currently, you would not be able to create larger than 512K / 1M chunks even with request based dm-crypt since requests have limits on number of data they can carry as well... So this is kind of abstract discussion.

Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR

Well, I did a simple test with dd reading, cause my engine limitation is 1M,
(1) so the time like below when handle 1M at one time.
1048576 bytes (1.0 MB) copied, 0.0841235 s, 12.5 MB/s
1048576 bytes (1.0 MB) copied, 0.0836294 s, 12.5 MB/s
1048576 bytes (1.0 MB) copied, 0.0836526 s, 12.5 MB/s

(2) These handle 64K at one time * 16 times 1048576 bytes (1.0 MB) copied, 0.0937223 s, 11.2 MB/s 1048576 bytes (1.0 MB) copied, 0.097205 s, 10.8 MB/s 1048576 bytes (1.0 MB) copied, 0.0935884 s, 11.2 MB/s

Here is a 10ms level difference, try to image if the hardware engine's throughput is bigger than that. But like Jens said, we can measure it by the performance data.

Quoted 12 lines · On Friday 13 November 2015 10:05:28 Baolin Wang wrote:

Well, I did a simple test with dd reading, cause my engine limitation is 1M,
(1) so the time like below when handle 1M at one time.
1048576 bytes (1.0 MB) copied, 0.0841235 s, 12.5 MB/s
1048576 bytes (1.0 MB) copied, 0.0836294 s, 12.5 MB/s
1048576 bytes (1.0 MB) copied, 0.0836526 s, 12.5 MB/s

(2) These handle 64K at one time * 16 times 1048576 bytes (1.0 MB) copied, 0.0937223 s, 11.2 MB/s 1048576 bytes (1.0 MB) copied, 0.097205 s, 10.8 MB/s 1048576 bytes (1.0 MB) copied, 0.0935884 s, 11.2 MB/s

Quoted 3 lines

Here is a 10ms level difference, try to image if the hardware engine's throughput is bigger than that. But like Jens said, we can measure it by the performance data.

The absolute numbers look really low. Does this include writing to a hard drive? That would certainly make the difference appear less significant.

Could you try backing this with a ram disk backing for comparison, and also use 'time dd' to show the CPU utilization for all cases? For completeness, including cpu-only performance might also help put this into perspective.

Arnd

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

Quoted 6 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

Quoted 3 lines

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

The duality of bio-based vs request-based code paths in DM core frankly sucks. So the prospect of polluting dm-crypt with a similar duality is really _not_ interesting.

Request-based DM requires more memory reserves per device than bio-based DM. Also, you cannot stack request-based DM ontop of bio-based devices (be them DM, MD, etc) so request-based DM's underlying storage stack gets a lot less interesting with this change.

That said, it could be that the benefits of supporting both bio-based and request-based DM in dm-crypt outweigh any overhead/limitations. But you haven't given any performance data to justify this patchset.

There needs to be a _really_ compelling benefit to do this.

Also, FYI, having a big CONFIG knob to switch all of dm-crypt from bio-based to request-based is _not_ acceptable. Both modes would need to be supported in parallel. Could easily be that not all devices in a system will benefit from being request-based.

Regardless, the risk of this change causing request-based DM to become more brittle than it already is concerns me.

But I'm trying to keep an open mind... show me data that real hardware _really_ benefits and we'll go from there. Again, it needs to be "OMG, this is amazing!" level performance to warrant any further serious consideration.

That's right. But we'll not introduce the duality things, cause we will remove the bio based things in dm-crypt if the request based things are accepted.

Quoted 9 lines · Baolin Wang

Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ decrypt block data, which can only hanle one bio at one time. As we know, one bio must use the sequential physical address and it also has a limitation of length. Thus it may limit the big block encyrtion/decryption when some hardware support the big block data encryption.

This patch series introduc the 'based-request' method to handle the data encryption/decryption. One request can contain multiple bios, so it can handle big block data to improve the efficiency.

The duality of bio-based vs request-based code paths in DM core frankly sucks. So the prospect of polluting dm-crypt with a similar duality is really _not_ interesting.

Request-based DM requires more memory reserves per device than bio-based DM. Also, you cannot stack request-based DM ontop of bio-based devices (be them DM, MD, etc) so request-based DM's underlying storage stack gets a lot less interesting with this change.

That said, it could be that the benefits of supporting both bio-based and request-based DM in dm-crypt outweigh any overhead/limitations. But you haven't given any performance data to justify this patchset.

There needs to be a _really_ compelling benefit to do this.

Also, FYI, having a big CONFIG knob to switch all of dm-crypt from bio-based to request-based is _not_ acceptable. Both modes would need to be supported in parallel. Could easily be that not all devices in a system will benefit from being request-based.

Regardless, the risk of this change causing request-based DM to become more brittle than it already is concerns me.

But I'm trying to keep an open mind... show me data that real hardware _really_ benefits and we'll go from there. Again, it needs to be "OMG, this is amazing!" level performance to warrant any further serious consideration.

3. perforamence data
It is just a simple dd test result, and will provide the formal report in future. But from the simple test, we can see the improvement.

Quoted 3 lines · Baolin Wang

3. perforamence data
It is just a simple dd test result, and will provide the formal report in future. But from the simple test, we can see the improvement.

It's probably also worth pointing out that Qualcomm have been shipping an out of tree implementation of this as a separate module in their BSP (originally written by Danesh Garg who's on this thread):

https://android.googlesource.com/kernel/msm/+/android-msm-dory-3.10-kitkat-wear/drivers/md/dm-req-crypt.c

Android now wants to encrypt phones and tablets by default and have been seeing substantial performance hits as a result, we can try to get people to share performance data from productionish systems but it might be difficult.

Quoted 13 lines · Mark Brown

Quoted 3 lines · Baolin Wang

3. perforamence data
It is just a simple dd test result, and will provide the formal report in future. But from the simple test, we can see the improvement.

It's probably also worth pointing out that Qualcomm have been shipping an out of tree implementation of this as a separate module in their BSP (originally written by Danesh Garg who's on this thread):

Quoted 6 lines

https://android.googlesource.com/kernel/msm/+/android-msm-dory-3.10-kitkat-wear/drivers/md/dm-req-crypt.c

Android now wants to encrypt phones and tablets by default and have been seeing substantial performance hits as a result, we can try to get people to share performance data from productionish systems but it might be difficult.

Well, shame on them for developing out-of-tree, looks like they are reaping all the benefits of that.

Guys, we need some numbers, enough with the hand waving. There's no point discussing this further until we know how much of a difference it makes to handle X MB chunks instead of Y MB chunks. As was previously stated, unless there's a _substantial_ performance benefit, this patchset isn't going anywhere.

If there is a huge benefit, we can look into ways of making it actually work. That may not even be a request interface, it could just be proper utilization of plugging for in-dm bio merging.

--
Jens Axboe

Quoted 4 lines · Mark Brown

Android now wants to encrypt phones and tablets by default and have been seeing substantial performance hits as a result, we can try to get people to share performance data from productionish systems but it might be difficult.

Well, shame on them for developing out-of-tree, looks like they are reaping all the benefits of that.

Guys, we need some numbers, enough with the hand waving. There's no point discussing this further until we know how much of a difference it makes to handle X MB chunks instead of Y MB chunks. As was previously stated, unless there's a _substantial_ performance benefit, this patchset isn't going anywhere.

Quoted 7 lines · Jens Axboe

Quoted 4 lines · Mark Brown

Android now wants to encrypt phones and tablets by default and have been seeing substantial performance hits as a result, we can try to get people to share performance data from productionish systems but it might be difficult.

Quoted 8 lines

Well, shame on them for developing out-of-tree, looks like they are reaping all the benefits of that.

Guys, we need some numbers, enough with the hand waving. There's no point discussing this further until we know how much of a difference it makes to handle X MB chunks instead of Y MB chunks. As was previously stated, unless there's a _substantial_ performance benefit, this patchset isn't going anywhere.

Yeah, what I'm saying here is that there will issues getting the numbers from relevant production systems - we are most likely to be looking at proxies which are hopefully reasonably representative but there's likely to be more divergence than you'd see just running benchmark workloads on similar systems to those used in production.

These are the benchmarks for request based dm-crypt. Please check it.

For request based things, some sequential bios/requests can merged into one request to expand the IO size to be a big block handled by hardware engine at one time.

Quoted 1 line · Baolin Wang

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

People aren't going to take a request-based solution seriously until you can explain in full detail *why* bio-based is slower AND why it's impossible to improve its performance.

Quoted 3 lines

For request based things, some sequential bios/requests can merged into one request to expand the IO size to be a big block handled by hardware engine at one time.

Bio-based also merges I/O so that does not provide justification. Investigate in much more detail the actual merging and scheduling involved in the cases you need to optimise. See if blktrace gives you any clues, or add your own instrumentation. You could even look at some of the patches we've had in the list archives for optimising bio-based crypt in different situations.

Alasdair

Quoted 7 lines · Alasdair G Kergon

Quoted 1 line · Baolin Wang

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed, that helps the engine palys best performance. But a big IO size does not mean bigger scatterlists (maybe many scatterlists with small length), that's why we can not get the corresponding performance if we just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine likes bigger scatterlists to improve the performance. But for bio based, it only send one scatterlist (the scatterlist's length is always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It means if the bio size is 1M, the bio based will send 2048 times (evey time the only one scatterlist length is 512 bytes) to crypto engine to handle, which is more time-consuming and ineffective for the crypto engine. But for request based, it can map the whole request with many scatterlists (not just one scatterlist), and send all the scatterlists to the crypto engine which can improve the performance, is it right?

Another optimization solution I think is we can expand the scatterlist entry number for bio based.

Quoted 3 lines

Alasdair

--
Baolin.wang
Best Regards

Quoted 34 lines · Alasdair G Kergon

Quoted 7 lines · Baolin Wang

Quoted 1 line

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed, that helps the engine palys best performance. But a big IO size does not mean bigger scatterlists (maybe many scatterlists with small length), that's why we can not get the corresponding performance if we just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine likes bigger scatterlists to improve the performance. But for bio based, it only send one scatterlist (the scatterlist's length is always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It means if the bio size is 1M, the bio based will send 2048 times (evey time the only one scatterlist length is 512 bytes) to crypto engine to handle, which is more time-consuming and ineffective for the crypto engine. But for request based, it can map the whole request with many scatterlists (not just one scatterlist), and send all the scatterlists to the crypto engine which can improve the performance, is it right?

Quoted 3 lines

Another optimization solution I think is we can expand the scatterlist entry number for bio based.

I did some testing about my assumption of expanding the scatterlist entry number for bio based. I did some modification for the bio based to support multiple scatterlists, then it will get the same performance as the request based things.

1. bio based with expanding the scatterlist entry
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s

real    1m34.562s
user    0m0.030s
sys     0m3.850s

2. Sequential read 1G with requset based:
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s

real    1m34.908s
user    0m0.030s
sys     0m4.000s

From the data, we can find the bio based also can get the same
performance as the request based. So if someone still don't like the request based things, I think we can optimize the bio based by expanding the scatterlists number. Thanks.

Dne 3.12.2015 v 11:36 Baolin Wang napsal(a):

Quoted 58 lines · Baolin Wang

Quoted 38 lines · Alasdair G Kergon

Quoted 10 lines · Baolin Wang

Quoted 2 lines

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed, that helps the engine palys best performance. But a big IO size does not mean bigger scatterlists (maybe many scatterlists with small length), that's why we can not get the corresponding performance if we just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine likes bigger scatterlists to improve the performance. But for bio based, it only send one scatterlist (the scatterlist's length is always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It means if the bio size is 1M, the bio based will send 2048 times (evey time the only one scatterlist length is 512 bytes) to crypto engine to handle, which is more time-consuming and ineffective for the crypto engine. But for request based, it can map the whole request with many scatterlists (not just one scatterlist), and send all the scatterlists to the crypto engine which can improve the performance, is it right?

Quoted 3 lines

Another optimization solution I think is we can expand the scatterlist entry number for bio based.

I did some testing about my assumption of expanding the scatterlist entry number for bio based. I did some modification for the bio based to support multiple scatterlists, then it will get the same performance as the request based things.

1. bio based with expanding the scatterlist entry
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s

real    1m34.562s
user    0m0.030s
sys     0m3.850s

2. Sequential read 1G with requset based:
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s

Quoted 9 lines

real    1m34.908s
user    0m0.030s
sys     0m4.000s

From the data, we can find the bio based also can get the same
performance as the request based. So if someone still don't like the request based things, I think we can optimize the bio based by expanding the scatterlists number. Thanks.

Hi

Do you see any performance impact if you use with cryptsetup options:

--perf-same_cpu_crypt
--perf-submit_from_crypt_cpus

with your regular unpatched kernel.

Zdenek

Quoted 34 lines · Baolin Wang

Quoted 7 lines · Alasdair G Kergon

Quoted 1 line · Baolin Wang

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed, that helps the engine palys best performance. But a big IO size does not mean bigger scatterlists (maybe many scatterlists with small length), that's why we can not get the corresponding performance if we just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine likes bigger scatterlists to improve the performance. But for bio based, it only send one scatterlist (the scatterlist's length is always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It means if the bio size is 1M, the bio based will send 2048 times (evey time the only one scatterlist length is 512 bytes) to crypto engine to handle, which is more time-consuming and ineffective for the crypto engine. But for request based, it can map the whole request with many scatterlists (not just one scatterlist), and send all the scatterlists to the crypto engine which can improve the performance, is it right?

Quoted 3 lines

Another optimization solution I think is we can expand the scatterlist entry number for bio based.

I did some testing about my assumption of expanding the scatterlist entry number for bio based. I did some modification for the bio based to support multiple scatterlists, then it will get the same performance as the request based things.

1. bio based with expanding the scatterlist entry
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s

real    1m34.562s
user    0m0.030s
sys     0m3.850s

2. Sequential read 1G with requset based:
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s

real    1m34.908s
user    0m0.030s
sys     0m4.000s

Quoted 51 lines · Baolin Wang

Quoted 34 lines · Baolin Wang

Quoted 7 lines · Alasdair G Kergon

Quoted 1 line · Baolin Wang

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed, that helps the engine palys best performance. But a big IO size does not mean bigger scatterlists (maybe many scatterlists with small length), that's why we can not get the corresponding performance if we just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine likes bigger scatterlists to improve the performance. But for bio based, it only send one scatterlist (the scatterlist's length is always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It means if the bio size is 1M, the bio based will send 2048 times (evey time the only one scatterlist length is 512 bytes) to crypto engine to handle, which is more time-consuming and ineffective for the crypto engine. But for request based, it can map the whole request with many scatterlists (not just one scatterlist), and send all the scatterlists to the crypto engine which can improve the performance, is it right?

Quoted 3 lines

Another optimization solution I think is we can expand the scatterlist entry number for bio based.

I did some testing about my assumption of expanding the scatterlist entry number for bio based. I did some modification for the bio based to support multiple scatterlists, then it will get the same performance as the request based things.

1. bio based with expanding the scatterlist entry
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.5458 s, 11.4 MB/s

real    1m34.562s
user    0m0.030s
sys     0m3.850s

Quoted 6 lines

2. Sequential read 1G with requset based:
time dd if=/dev/dm-0 of=/dev/null bs=64K count=16384 iflag=direct 1073741824 bytes (1.1 GB) copied, 94.8922 s, 11.3 MB/s

real    1m34.908s
user    0m0.030s
sys     0m4.000s

Measuring the system time this way is completely wrong because it doesn't account for the time spent in kernel threads.

Mikulas

Quoted 7 lines · Alasdair G Kergon

Quoted 1 line · Baolin Wang

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed,

that helps the engine palys best performance. But a big IO size does not mean bigger scatterlists (maybe many scatterlists with small length), that's why we can not get the corresponding performance if we just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine likes bigger scatterlists to improve the performance. But for bio based, it only send one scatterlist (the scatterlist's length is always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It means if the bio size is 1M, the bio based will send 2048 times (evey time the only one scatterlist length is 512 bytes) to crypto engine to handle, which is more time-consuming and ineffective for the crypto engine. But for request based, it can map the whole request with many scatterlists (not just one scatterlist), and send all the scatterlists to the crypto engine which can improve the performance, is it right?

Another optimization solution I think is we can expand the scatterlist entry number for bio based.

Quoted 9 lines · Baolin Wang

Quoted 7 lines · Alasdair G Kergon

Quoted 1 line · Baolin Wang

These are the benchmarks for request based dm-crypt. Please check it.

Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this?

Quoted 8 lines

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the request based, we can find it can not get the corresponding performance if we just expand the IO size. Because In dm crypt, it will map the data buffer of one request with scatterlists, and send all scatterlists of one request to the encryption engine to encrypt or decrypt. I found if the scatterlist list number is small and each scatterlist length is bigger, it will improve the encryption speed,

This optimization is only applicable to XTS mode. XTS has its weaknesses and it is not recommended for encryption of more than 1TB of data ( http://grouper.ieee.org/groups/1619/email/msg02357.html )

You can optimize bio-based dm-crypt as well (use larger encryption chunk than 512 bytes when the mode is XTS).

The most commonly used mode aes-cbc-essiv:sha256 can't be optimized that way. You have to do encryption and decryption sector by sector because every sector has different IV.

Mikulas

But I'm trying to keep an open mind... show me data that real hardware _really_ benefits and we'll go from there. Again, it needs to be "OMG, this is amazing!" level performance to warrant any further serious consideration.