> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Thursday, October 19, 2017 2:23 PM
> To: Nicolau, Radu <radu.nico...@intel.com>; Akhil Goyal
> <akhil.go...@nxp.com>; dev@dpdk.org
> Cc: Doherty, Declan <declan.dohe...@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.gua...@intel.com>; hemant.agra...@nxp.com;
> bor...@mellanox.com; avia...@mellanox.com; tho...@monjalon.net;
> sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com; Mcnamara,
> John <john.mcnam...@intel.com>; shah...@mellanox.com;
> olivier.m...@6wind.com
> Subject: RE: [PATCH v4 10/12] net/ixgbe: enable inline ipsec
> 
> 
> 
> > -----Original Message-----
> > From: Nicolau, Radu
> > Sent: Thursday, October 19, 2017 2:14 PM
> > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Akhil Goyal
> > <akhil.go...@nxp.com>; dev@dpdk.org
> > Cc: Doherty, Declan <declan.dohe...@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.gua...@intel.com>; hemant.agra...@nxp.com;
> > bor...@mellanox.com; avia...@mellanox.com; tho...@monjalon.net;
> > sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com; Mcnamara,
> John
> > <john.mcnam...@intel.com>; shah...@mellanox.com;
> > olivier.m...@6wind.com
> > Subject: Re: [PATCH v4 10/12] net/ixgbe: enable inline ipsec
> >
> >
> >
> > On 10/19/2017 1:29 PM, Ananyev, Konstantin wrote:
> > >
> > >> -----Original Message-----
> > >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev,
> > >> Konstantin
> > >> Sent: Thursday, October 19, 2017 1:17 PM
> > >> To: Nicolau, Radu <radu.nico...@intel.com>; Akhil Goyal
> > >> <akhil.go...@nxp.com>; dev@dpdk.org
> > >> Cc: Doherty, Declan <declan.dohe...@intel.com>; De Lara Guarch,
> > >> Pablo <pablo.de.lara.gua...@intel.com>;
> > hemant.agra...@nxp.com;
> > >> bor...@mellanox.com; avia...@mellanox.com;
> tho...@monjalon.net;
> > >> sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com;
> Mcnamara,
> > >> John <john.mcnam...@intel.com>; shah...@mellanox.com;
> > >> olivier.m...@6wind.com
> > >> Subject: Re: [dpdk-dev] [PATCH v4 10/12] net/ixgbe: enable inline
> > >> ipsec
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Nicolau, Radu
> > >>> Sent: Thursday, October 19, 2017 12:57 PM
> > >>> To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Akhil
> > >>> Goyal <akhil.go...@nxp.com>; dev@dpdk.org
> > >>> Cc: Doherty, Declan <declan.dohe...@intel.com>; De Lara Guarch,
> > >>> Pablo <pablo.de.lara.gua...@intel.com>;
> > hemant.agra...@nxp.com;
> > >>> bor...@mellanox.com; avia...@mellanox.com;
> tho...@monjalon.net;
> > >>> sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com;
> Mcnamara,
> > >>> John <john.mcnam...@intel.com>; shah...@mellanox.com;
> > >>> olivier.m...@6wind.com
> > >>> Subject: RE: [PATCH v4 10/12] net/ixgbe: enable inline ipsec
> > >>>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Ananyev, Konstantin
> > >>>> Sent: Thursday, October 19, 2017 12:04 PM
> > >>>> To: Nicolau, Radu <radu.nico...@intel.com>; Akhil Goyal
> > >>>> <akhil.go...@nxp.com>; dev@dpdk.org
> > >>>> Cc: Doherty, Declan <declan.dohe...@intel.com>; De Lara Guarch,
> > >>>> Pablo <pablo.de.lara.gua...@intel.com>; hemant.agra...@nxp.com;
> > >>>> bor...@mellanox.com; avia...@mellanox.com;
> tho...@monjalon.net;
> > >>>> sandeep.ma...@nxp.com; jerin.ja...@caviumnetworks.com;
> Mcnamara,
> > >>>> John <john.mcnam...@intel.com>; shah...@mellanox.com;
> > >>>> olivier.m...@6wind.com
> > >>>> Subject: RE: [PATCH v4 10/12] net/ixgbe: enable inline ipsec
> > >>>>
> > >>>>
> > >>>>
> > >>>>>>> <snip>
> > >>>>>>> +
> > >>>>>>> +static int
> > >>>>>>> +ixgbe_crypto_update_mb(void *device __rte_unused,
> > >>>>>>> +           struct rte_security_session *session,
> > >>>>>>> +                  struct rte_mbuf *m, void *params __rte_unused)
> {
> > >
> > >
> > > Another sort of generic question - why not make
> > > security_set_pkt_metadata function to accept  bulk of packets?
> > > In that case o can minimize the cost of function calls, accessing session
> data, etc.
> > > Though I suppose that could wait till next patch series.
> > > Konstantin
> > It is a good suggestion, but we need to discuss it further;
> 
> Yes, as I said that's for future.
> 
> > for example
> > if it can accept a bulk of packets, will it need also a bulk of
> > metadata pointers, or just one for all the packets?
> 
> By metadata do you mean a session or ...?
> Konstantin

No, I mean the void *params parameter, (that was named metadata in earlier 
patches).
> 
> > >
> > >>>>>>> +   struct ixgbe_crypto_session *ic_session =
> > >>>>>>> +                   get_sec_session_private_data(session);
> > >>>>>>> +   if (ic_session->op ==
> IXGBE_OP_AUTHENTICATED_ENCRYPTION) {
> > >>>>>>> +           struct ixgbe_crypto_tx_desc_md *mdata =
> > >>>>>>> +                   (struct ixgbe_crypto_tx_desc_md *)&m-
> >udata64;
> > >>>>>>> +           mdata->enc = 1;
> > >>>>>>> +           mdata->sa_idx = ic_session->sa_index;
> > >>>>>>> +           mdata->pad_len = *rte_pktmbuf_mtod_offset(m,
> > >>>>>>> +                   uint8_t *, rte_pktmbuf_pkt_len(m) - 18) +
> 18;
> > >>>>>> Could you explain what pad_len supposed to contain?
> > >>>>>> Also what is a magical constant '18'?
> > >>>>>> Could you create some macro if needed?
> > >>>>> I added an explanation in the code, we read the payload padding
> > >>>>> size that is stored at the len-18 bytes and add 18 bytes, 2 for
> > >>>>> ESP trailer and 16 for ICV.
> > >>>> Ok, can we at least have a macros for all these constants?
> > >>>> Another question: you do use pkt_len() here - does it mean that
> > >>>> multi- segment packets are not supported by ixgbe-ipsec?
> > >>>> Konstantin
> > >>> It does support multisegment, but the pad_len has to be set only
> > >>> for single send, it will be ignored otherwise. I have updated the
> > >>> code
> > to
> > >> set
> > >>> it for single segment packets only.
> > >> Sorry, I didn't understand that.
> > >> If that function does support multiseg packets, then it has to go
> > >> to the last segment via m->next, If it doesn't, then it should return an
> error I case of m->nb_seg != 1.
> > >> Right?
> > >>
> > >>> Also, our test app does not support multisegment packets.
> > >> Ok, I suppose that means, multi-seg case wasn't tested :)
> > >>
> > >>
> > >>

Reply via email to