> >> > >> When esn is used then high-order 32 bits are included in ICV > >> calculation however are not transmitted. Update packet length > >> to be consistent with auth data offset and length before crypto > >> operation. High-order 32 bits of esn will be removed from packet > >> length in crypto post processing. > > > > Hi Lukasz, > > Why you want to do it? > > I deliberately didn't include SQH bits into the pkt_len/data_len, > > because it is a temporary data and we are going to drop it anyway. > > Konstantin > > > > Hi Konstantin, > > Our OcteonTx crypto driver validates pkt_len with auth data length/offset > > and it complains > > because it is told to authenticate more data that a packet holds (according > > to pkt_len). > > I came across this when running IPSec tests which use esn. > > I understand that sqh 32 bits are temporary and included only for ICV > > calculation however > > not including them in pkt_len for crypto processing is inconsistent in my > > opinion. > > Thanks, > > Lukasz > > > > Hi Konstantin, > > I should have elaborated more. When 32 high bits of esn are not included in > packet length then auth offset and data point to data which is outside packet > (according to packet length). > This makes crypto request (auth data length and offset) incoherent with a > packet > which the crypto request points to. > > This is my argument for including 32 high bits of esn into packet length even > though the inclusion is only temporary.
I understood the reasoning. Will try to have a closer look in next few days. Thanks Konstantin
