On Thu, Oct 24, 2024 at 3:17 PM David Marchand
wrote:
> @@ -1209,14 +1195,16 @@ process_openssl_cipher_des3ctr(struct rte_mbuf
> *mbuf_src, uint8_t *dst,
> l = rte_pktmbuf_data_len(m) - offset;
>
> memcpy(ctr, iv, 8);
> + host_ctr = rte_be_64_to_cpu(ctr);
>
> for (n =
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Thursday, 24 October 2024 14.06
>
> Caught by code review.
>
> Don't byte swap unconditionally (assuming that CPU is little endian is
> wrong). Instead, convert from big endian to cpu and vice versa.
Yes looks like a bug.
I wonder
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Thursday, 24 October 2024 15.30
>
> On Thu, Oct 24, 2024 at 3:17 PM David Marchand
> wrote:
> > @@ -1209,14 +1195,16 @@ process_openssl_cipher_des3ctr(struct
> rte_mbuf
> > *mbuf_src, uint8_t *dst,
> > l = rte_pktmbuf_data_
On Thu, Oct 24, 2024 at 2:55 PM Morten Brørup
wrote:
>
> > From: David Marchand [mailto:david.march...@redhat.com]
> > Sent: Thursday, 24 October 2024 14.06
> >
> > Caught by code review.
> >
> > Don't byte swap unconditionally (assuming that CPU is little endian is
> > wrong). Instead, convert f
On Thu, Oct 24, 2024 at 3:10 PM David Marchand
wrote:
> > There may be an alignment bug too; the way it is used in
> > process_openssl_cipher_des3ctr(), "ctr" is not guaranteed to be uint64_t
> > aligned.
> >
> > How about this instead:
> >
> > ctr_inc(void *ctr)
> > {
> > uint64_t ctr64
5 matches
Mail list logo
