Hi Konstantin,
> Subject: [EXT] RE: [PATCH 2/2] lib/security: add SA lifetime configuration
>
> Hi Anoob,
>
> > > > Now that we have an agreement on bitfields (hoping no one else has
> > > > an objection), I would like to discuss one more topic. It is more
> > > > related to
> > > checksum offlo
Hi Anoob,
> > > Now that we have an agreement on bitfields (hoping no one else has an
> > > objection), I would like to discuss one more topic. It is more related to
> > checksum offload, but it's better that we discuss along with other similar
> > items (like soft expiry).
> > >
> > > L3 & L4 che
Hi Konstantin,
> Subject: [EXT] RE: [PATCH 2/2] lib/security: add SA lifetime configuration
>
> External Email
>
> --
> Hi Anoob,
>
> > Now that we have an agreement on bitfields (hoping no one else has an
> > objection), I wou
Hi Anoob,
> Now that we have an agreement on bitfields (hoping no one else has an
> objection), I would like to discuss one more topic. It is more related
> to checksum offload, but it's better that we discuss along with other similar
> items (like soft expiry).
>
> L3 & L4 checksum can be tris
Hi Akhil, Konstantin,
Now that we have an agreement on bitfields (hoping no one else has an
objection), I would like to discuss one more topic. It is more related to
checksum offload, but it's better that we discuss along with other similar
items (like soft expiry).
L3 & L4 checksum can be tri
Hi Konstantin,
> Hi Akhil,
>
> > > > > My vote would probably be for option #2 (use one of the reserved
> fields
> > > for
> > > > > it).
> > > > > That way - existing code wouldn't need to be changed.
> > > >
> > > > Adding a single enum or multiple enums is the same thing. Right wrt
> code
> > >
Hi Akhil,
> > > > > There are two options that we considered,
> > > > > 1. Extend the enum, rte_crypto_op_status, to cover warnings [1]
> > > > > 2. There are reserved fields in rte_cryto_op structure. So we can use
> > bits in
> > > > them to indicate various cases. [2]
> > > > >
> > > > > Both
Hi Konstantin,
> > > > There are two options that we considered,
> > > > 1. Extend the enum, rte_crypto_op_status, to cover warnings [1]
> > > > 2. There are reserved fields in rte_cryto_op structure. So we can use
> bits in
> > > them to indicate various cases. [2]
> > > >
> > > > Both the submit
Hi Akhil,
> Hi Konstantin,
> > > There are two options that we considered,
> > > 1. Extend the enum, rte_crypto_op_status, to cover warnings [1]
> > > 2. There are reserved fields in rte_cryto_op structure. So we can use
> > > bits in
> > them to indicate various cases. [2]
> > >
> > > Both t
Hi Konstantin,
> > There are two options that we considered,
> > 1. Extend the enum, rte_crypto_op_status, to cover warnings [1]
> > 2. There are reserved fields in rte_cryto_op structure. So we can use bits
> > in
> them to indicate various cases. [2]
> >
> > Both the submitted patches follow ap
Hi Anoob,
>
> Hi Akhil, Declan, Fan, Hemant, Konstantin,
>
> This patch & and a patch submitted by Archana earlier
> (http://patches.dpdk.org/project/dpdk/patch/20210630111248.746-1-
> march...@marvell.com/), aims at extending rte_crypto_op so that it can be
> used to communicate any warnings
Hi Akhil, Declan, Fan, Hemant, Konstantin,
This patch & and a patch submitted by Archana earlier
(http://patches.dpdk.org/project/dpdk/patch/20210630111248.746-1-march...@marvell.com/),
aims at extending rte_crypto_op so that it can be used to communicate any
warnings from the rte_security offl
Add SA lifetime configuration to register soft and hard expiry limits.
Expiry can be in units of number of packets or bytes. Crypto op
status is also updated to cover warnings indicating soft expiry in case
of lookaside protocol operations.
In case of soft expiry, the packets are successfully IPse
13 matches
Mail list logo
