The answer depends on how the encryption is designed. Most block level encryptions have a 1:1 mapping between logical and physical sectors. That means reading one plaintext sector from the logical device translates to reading one ciphertext sector from the physical device. And writing one plaintext sector to the logical device translates to writing one ciphertext sector to the physical device. I expect the default on CentOS to fall into this class.
This is a compromise between efficiency and security. There are certain kinds of leaks in this approach, but solving those adds lot of complexity and quite some overhead. To any cryptographer it is obvious, that since the plaintext and ciphertext have the exact same size, you cannot get semantic security.
At first it sounds like this approach means the encryption layer does not change the I/O efficiency at all. However you do lose the ability use the TRIM command. The lack of TRIM support can reduce the efficiency and lifetime of an SSD. If you are using a file system that does not support TRIM anyway, you will be losing nothing in terms of I/O from using encryption.
There is nothing preventing an encryption layer from passing the TRIM command through to the physical layer, but doing so will leak some information about the structure of data on the file system. Here you can see some documentation of an implementation which supports this, but does not enable it by default.
More advanced storage encryption schemes are possible, which have a cost in terms of I/O and storage capacity but have fewer opportunities for data leaks. Such schemes could even support TRIM without leaking data.