Hi Shally,
Yes, I meant Segmented packets.
I am facing the issue when I try to read the Next Header from the ESP
trailer.
My assumption would be that the end of packet would be l3 ptr + ip->
tot_len.
>From this , I would do go back by 1 byte to the ESP trailer ( Something
like =>odph_esptrl_t *esp_t = (odph_esptrl_t *)(eop) - 1; )
When I try to access the next_header in the ESP trailer, I get some
arbitrary value but not ODPH_IPV4.
Would segmented packets need to be handled specially?
Regards,
{Nanda]
On Thu, 16 Mar 2017 at 15:51 Verma, Shally <shally.ve...@cavium.com> wrote:
> Have a question by chained , do you mean a "Segmented" packets?
>
> -----Original Message-----
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala
> Manoharan
> Sent: 16 March 2017 14:01
> To: Nanda Gopal <nandana...@gmail.com>
> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] Regarding Chained Buffers and Crypto
>
> On 15 March 2017 at 18:42, Nanda Gopal <nandana...@gmail.com> wrote:
>
> > *Hi,*
> >
> >
> >
> > *When we pass, odp_crypto_op_params_t params to odp_crypto_operation
> > (), as per the documentation, if we set params-> out_pkt to INVALID, a
> > new pkt would be created from the original pkt pool, data copied from
> > original pkt and then passed on to DPDK. *
> >
> > *In our test case, we are passing a chained buffer to this crypto API,
> > so in order for send the same buffer to lower layer without a copy,
> > are there any flags to be set? *
> >
>
> If your requirement is to support in-place crypto processing you can
> specify the output packet as same as input packet (i.e out_pkt = pkt).
>
> Regards,
> Bala
>
> >
> >
> > *Regards,*
> >
> > *Nanda*
> >
>
