Thank you Bill!
On Thu, 16 Mar 2017 at 18:34 Bill Fischofer <bill.fischo...@linaro.org> wrote: > Bug https://bugs.linaro.org/show_bug.cgi?id=2895 is already open > regarding the current restriction on odp-linux not supporting segmented > packets as input to crypto. Nikhil is working on this. > > On Thu, Mar 16, 2017 at 7:38 AM, Bala Manoharan <bala.manoha...@linaro.org > > wrote: > > On 16 March 2017 at 18:03, Nanda Gopal <nandana...@gmail.com> wrote: > > > 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? > > > > odp_packet_t could be internally implemented using segments and it could be > stored either as linked list or scatter gather based on the implementation. > Your approach will work only if the packet is not segmented and it will not > work for segmented packets. > > you have to use packet segment APIs documented in packet.h file to access > the packet. > > Regards, > Bala > > > > > > 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* > >> > > >> > > > > >
