2020-08-10, 12:09:40 -0400, Scott Dial wrote:
> On 8/10/2020 9:34 AM, Sabrina Dubroca wrote:
> > [adding the linux-crypto list]
> >
> > 2020-08-06, 23:48:16 -0400, Scott Dial wrote:
> >> On 8/6/2020 5:11 PM, Ryan Cox wrote:
> >>> With 5.7 I ge
[adding the linux-crypto list]
2020-08-06, 23:48:16 -0400, Scott Dial wrote:
> On 8/6/2020 5:11 PM, Ryan Cox wrote:
> > With 5.7 I get:
> > * 9.90 Gb/s with no macsec at all
> > * 1.80 Gb/s with macsec WITHOUT encryption
> > * 1.00 Gb/s (sometimes, but often less) with macsec WITH encryption
> >
2018-03-29, 21:27:51 +0530, Atul Gupta wrote:
> TLS handler for record transmit.
> Create Inline TLS work request and post to FW.
> Create Inline TLS record CPLs for hardware
>
> Signed-off-by: Atul Gupta
> Signed-off-by: Michael Werner
> ---
...
> +int chtls_sendmsg(struct sock *sk, struct msg
2018-03-29, 21:27:50 +0530, Atul Gupta wrote:
...
> +static void chtls_pass_accept_request(struct sock *sk,
> + struct sk_buff *skb)
> +{
...
> + if (chtls_get_module(newsk))
> + goto reject;
> + inet_csk_reqsk_queue_added(sk);
> + reply_skb
2018-03-27, 23:06:31 +0530, Atul Gupta wrote:
> Ethtool option enables TLS record offload on HW, user
> configures the feature for netdev capable of Inline TLS.
> This allows user to define custom sk_prot for Inline TLS sock
>
> Signed-off-by: Atul Gupta
> Reviewed-by: Sabrina
2018-03-16, 21:07:35 +0530, Atul Gupta wrote:
[...]
> +#define SOCK_INLINE (31)
[...]
> +static inline int csk_flag(const struct sock *sk, enum csk_flags flag)
> +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> +
> + if (!sock_flag(sk, SOCK_INLINE))
> + retur
2018-03-06, 21:09:27 +0530, Atul Gupta wrote:
[snip]
> +static int chtls_set_tcb_field(struct sock *sk, u16 word, u64 mask, u64 val)
> +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> + struct sk_buff *skb;
> + struct cpl_set_tcb_field *req;
> + struct ulptx_idata
2018-03-06, 21:09:25 +0530, Atul Gupta wrote:
> Read FW capability. Read key area size. Dump the TLS record count.
That's not a really helpful commit message. Have a look at other
commit messages and try to be more descriptive.
It's also not clear if those changes belong together in one patch, but
Since you're saying the driver supports offloading TLS records to the
HW, why not call the feature "record offloading"? With, for example,
NETIF_F_HW_TLS_RECORD as the feature, and maybe "tls-hw-record" for
the ethtool string. This "Inline TLS" name sounds rather like
marketing to me.
2018-03-06
2018-03-06, 21:05:23 +0530, Atul Gupta wrote:
> Series for Chelsio Inline TLS driver (chtls)
>
> Use tls ULP infrastructure to register chtls as Inline TLS driver.
> Chtls use TCP Sockets to transmit and receive TLS record. TCP proto_ops is
> extended to offload TLS record.
>
> T6 adapter provid
Hello Atul,
One quick note before you start replying: please fix your email
client, as you've been told before. Quoting has to add a quoting
marker (the '>' character) at the beginning of the line, otherwise
it's impossible to separate your reply from the email you're quoting.
2018-03-06, 21:06:2
2017-12-20, 17:03:02 +0530, Atul Gupta wrote:
> RFC series for Chelsio Inline TLS driver (chtls.ko)
>
> Driver use the ULP infrastructure to register chtls as Inline TLS ULP.
I don't think drivers should be registering their own ULP. TLS
offloading should be transparent to userspace, whatever HW
t;)
Reported-by: Ilya Lesokhin
Signed-off-by: Sabrina Dubroca
Reviewed-by: Stefano Brivio
---
arch/x86/crypto/aesni-intel_glue.c | 66 +++---
1 file changed, 54 insertions(+), 12 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aes
ned-off-by: Sabrina Dubroca
Reviewed-by: Stefano Brivio
---
arch/x86/crypto/aesni-intel_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 3bf3dcf29825..8981ed1eb7ad 100644
--- a/arch/x86/cr
This is the first step to make the aesni AES-GCM implementation
generic. The current code was written for rfc4106, so it handles only
some specific sizes of associated data.
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_asm.S | 169 +-
1 file
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index a73117c84904..ee6283120f83
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_asm.S | 62 ++-
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S
b/arch/x86/crypto/aesni-intel_asm.S
index 605726aaf0a2..16627fec80b2 100644
--- a
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index 7230808a7cef..faecb1518bf8
Now that the asm side of things can support all the valid lengths of ICV
and all lengths of associated data, provide the glue code to expose a
generic gcm(aes) crypto algorithm.
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_glue.c | 208 -
1
This is the first step to make the aesni AES-GCM implementation
generic. The current code was written for rfc4106, so it handles
only some specific sizes of associated data.
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 122 ++-
1 file
This is the first step to make the aesni AES-GCM implementation
generic. The current code was written for rfc4106, so it handles only
some specific sizes of associated data.
Signed-off-by: Sabrina Dubroca
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 85 ++--
1 file
6.3Gbps).
Sabrina Dubroca (7):
crypto: aesni: make non-AVX AES-GCM work with any aadlen
crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len
crypto: aesni: make AVX AES-GCM work with any aadlen
crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len
crypto: aesni
2017-04-10, 17:27:57 +0800, Herbert Xu wrote:
> On Mon, Apr 10, 2017 at 11:21:27AM +0200, Sabrina Dubroca wrote:
> >
> > > Cc:
> >
> > Should that be sta...@vger.kernel.org?
>
> Oops :)
>
> > > Reported-by: Sabrina Dubroca
> > &
ry request
> object on the stack which is used to relay EINPROGRESS back to
> the original completion function.
>
> This patch also adds code to preserve the original flags value.
>
> Cc:
Should that be sta...@vger.kernel.org?
> Reported-by: Sabrina Dubroca
> Signed
24 matches
Mail list logo
