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
> ---
...
>
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);
> +
io.com>
> Reviewed-by: Sabrina Dubroca <sdubr...@redhat.com>
uh, what? I definitely didn't give my "Reviewed-by" for any of these
patches. Please never do that again.
--
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))
> +
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
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,
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.
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,
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
)
Reported-by: Ilya Lesokhin <il...@mellanox.com>
Signed-off-by: Sabrina Dubroca <s...@queasysnail.net>
Reviewed-by: Stefano Brivio <sbri...@redhat.com>
---
arch/x86/crypto/aesni-intel_glue.c | 66 +++---
1 file changed, 54 insertions(+), 12 deletions(-)
Signed-off-by: Sabrina Dubroca <s...@queasysnail.net>
Reviewed-by: Stefano Brivio <sbri...@redhat.com>
---
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 3bf3
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 <s...@queasysnail.net>
---
arch/x86/crypto/aesni-intel_asm.S
Signed-off-by: Sabrina Dubroca <s...@queasysnail.net>
---
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
Signed-off-by: Sabrina Dubroca <s...@queasysnail.net>
---
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 605726
Signed-off-by: Sabrina Dubroca <s...@queasysnail.net>
---
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
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 <s...@queasysnail.net>
---
arch/x86/crypto/aesni-intel_glue.c
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 <s...@queasysnail.net>
---
arch/x86/crypto/aesni-intel_avx-x86_64.S
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 <s...@queasysnail.net>
---
arch/x86/crypto/aesni-intel_avx-x86_64.
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: <v...@stable.kernel.org>
> >
> > Should that be sta...@vger.kernel.org?
>
> Oops :)
>
> > > Reported-by:
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: <v...@stable.kernel.org>
Should that be sta...@vger.kernel.org?
> Reported-by: Sa
21 matches
Mail list logo