Steffen,
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Steffen Klassert
> Sent: Monday, January 20, 2020 10:37 AM
> To: Ayush Sawal <[email protected]>
> Cc: Herbert Xu <[email protected]>; [email protected]; [email protected]; Ayush Sawal
> <[email protected]>; [email protected]
> Subject: Re: Advertise maximum number of sg supported by driver in single request
>
> <<< External Email >>>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the
> sender/sender address and know the content is safe.
>
>
> On Fri, Jan 17, 2020 at 07:08:05PM +0530, Ayush Sawal wrote:
> > Hi steffen,
> >
> > On 1/17/2020 5:47 PM, Steffen Klassert wrote:
> > > On Fri, Jan 17, 2020 at 04:28:54PM +0530, Ayush Sawal wrote:
> > > > Hi steffen,
> > > >
> > > > On 1/17/2020 12:34 PM, Steffen Klassert wrote:
> > > > > On Fri, Jan 17, 2020 at 12:13:07PM +0530, Ayush Sawal wrote:
> > > > > > Hi Herbert,
> > > > > >
> > > > > > On 1/17/2020 11:53 AM, Herbert Xu wrote:
> > > > > > > On Thu, Jan 16, 2020 at 01:27:24PM +0530, Ayush Sawal wrote:
> > > > > > > > The max data limit is 15 sgs where each sg contains data of mtu size .
> > > > > > > > we are running a netperf udp stream test over ipsec tunnel .The ipsec tunnel
> > > > > > > > is established between two hosts which are directly connected
> > > > > > > Are you actually getting 15-element SG lists from IPsec? What is
> > > > > > > generating an skb with 15-element SG lists?
> > > > > > we have established the ipsec tunnel in transport mode using ip xfrm.
> > > > > > and running traffic using netserver and netperf.
> > > > > >
> > > > > > In server side we are running
> > > > > > netserver -4
> > > > > > In client side we are running
> > > > > > "netperf -H <serverip> -p <port> -t UDP_STREAM -Cc -- -m 21k"
> > > > > > where the packet size is 21k ,which is then fragmented into 15 ip fragments
> > > > > > each of mtu size.
> > > > > I'm lacking a bit of context here, but this should generate 15 IP
> > > > > packets that are encrypted one by one.
> > > > This is what i observed ,please correct me if i am wrong.
> > > > The packet when reaches esp_output(),is in socket buffer and based on the
> > > > number of frags ,sg is initialized using
> > > > sg_init_table(sg,frags),where frags are 15 in our case.
> > > The packet should be IP fragmented before it enters esp_output()
> > > unless this is a UDP GSO packet. What kind of device do you use
> > > here? Is it a crypto accelerator or a NIC that can do ESP offloads?
> >
> > We have device which works as a crypto accelerator . It just encrypts the
> > packets and send it back to kernel.
>
> I just did a test and I see the same behaviour. Seems like I was
> mistaken, we actually fragment the ESP packets. The only case
> where we do pre-encap fragmentation is IPv6 tunnel mode. But I
> wonder if it would make sense to avoid to have ESP fragments on
> the wire.
>
Well, for one thing, I don't know of any HW IPsec accelerator that can
handle fragmented IPsec packets directly. None of our hardware, that we've
been developing for over 2 decades now, can do that. All fragments would be
deferred to the slowpath for reassembly, killing performance.
So from that perspective you'd want to avoid systematic post-encapsulation
fragmentation whenever possible.
Proper path MTU discovery, accounting for the added IPsec headers, should
normally prevent this from being necessary.
Having said all that, it's not possible to encapsulate IPv4 fragments in transport
mode. So if PMTU discovery does not properly avoid that situation, then you
have no choice but to fragment _after_ ESP. But _only_ for that specific case.
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>