Hi,
We believe we found a behavior inconsistency based of different source mbuf layout in the QAT PMD code. file link: https://github.com/DPDK/dpdk/blob/main/drivers/crypto/qat/qat_sym.c The inconsistent behavior happens when: * symmetric operation * out-of-place operation * encryption * do cipher + not do hash * cipher offset is non-zero inconsistent behavior: * scenario 1: When SGL is disabled; or when SGL is enabled, cipher offset is smaller than the length of the first segment of the src mbuf chain o behavior: In dst mbuf, characters loacted in cipher offset is not copied over from the src mbuf. ||| data_len:2 ||| ---chained---> ||| data_len:66 ||| src mbuf SGL: seg 1: 2 bytes(cipher_offset) seg 2: payload ||| data_len:2 ||| ---chained---> ||| data_len:66 ||| dst mbuf SGL: seg 1: 2 bytes copied over seg 2: ciphered payload * scenario 2: when SGL is enabled, cipher offset is larger than or equal to the length of the first segment of the src mbuf chain o behavior: In dst mbuf, characters loacted in cipher offset is copied over from the src mbuf. ||| data_len:68 ||| src mbuf LB: src: 2 bytes(cipher_offset) + payload in single mbuf ||| data_len:2 ||| ---chained---> ||| data_len:66 ||| dst mbuf SGL: seg 1: 2 bytes untouched seg 2: ciphered payload Actual packet data: Src mbuf 0xcc 0x33, 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 dst mbuf: in LB, out SGL (scenario 1) 0x00 0x00 0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 0x76 0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb 0xbb 0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49 0xde 0x25 0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e 0x08 dst mbuf: in SGL, out SGL (scenario 2) 0xcc 0x33 0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 0x76 0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb 0xbb 0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49 0xde 0x25 0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e 0x08 For the actual use case, we have header information preceding the payload and the header should remain unencrypted in the dst mbuf. Therefore, we strongly believe that the second scenario is the desired behavior. There are cases where we do need to execute cipher only (which we can do today via a NULL hash). To attest to that claim, we tested this scenario where we enable the authentication operation with everything else being the same: * symmetric operation * out-of-place operation * encryption * do cipher + do hash * cipher offset is non-zero * auth offset is zero The content in dst mbuf located in the cipher offset is copied over from src mbuf for both src mbuf layout. Actual packet data: Src mbuf 0xcc 0x33, 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 dst mbuf: Both in SGL, out SGL and in SGL, out SGL (both scenario 1 & 2) 0xcc 0x33 0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 0x76 0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb 0xbb 0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49 0xde 0x25 0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e 0x08 0x50 0xa0 0x9f 0x15 Please let us know what your thoughts are about this issue and feel free to contact us if there are any questions. Linfeng
