netdev - Re: Advertise maximum number of sg supported by driver in single request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b0b4ba4b-1cdd-ad0b-32e4-2bc9610ff3e1@asicdesigners.com>
Date:   Mon, 20 Jan 2020 18:05:17 +0530
From:   Ayush Sawal <ayush.sawal@...cdesigners.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     ayush.sawal@...cdesigners.com,
        Herbert Xu <herbert@...dor.apana.org.au>,
        linux-crypto@...r.kernel.org, manojmalviya@...lsio.com,
        Ayush Sawal <ayush.sawal@...lsio.com>, netdev@...r.kernel.org
Subject: Re: Advertise maximum number of sg supported by driver in single
 request

Hi Steffen,

On 1/20/2020 3:07 PM, Steffen Klassert wrote:
> 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.


As we have a crypto accelarator as device when the request is send to 
the crypto driver from esp_output ,
the aead_request has all the fragments in its src sg and the problem 
which we are facing is when this
src sg nents becomes greater than 15 ,15 is our crypto driver's max sg 
limit to handle the request in one shot.

Does it make sense for a crypto driver to advertise the maximum amount 
of sg it can handle for a single
request and then handling this in crypto framework while forming the 
crypto request?

Thanks,
Ayush