* Re: [GIT PULL] Keys: Set 4 - Key ACLs for 5.3
From: pr-tracker-bot @ 2019-07-09 3:15 UTC (permalink / raw)
To: David Howells
Cc: torvalds, dhowells, jmorris, keyrings, netdev, linux-nfs,
linux-cifs, linux-afs, linux-fsdevel, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <28477.1562362239@warthog.procyon.org.uk>
The pull request you sent on Fri, 05 Jul 2019 22:30:39 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-acl-20190703
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0f75ef6a9cff49ff612f7ce0578bced9d0b38325
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH 14/14] net: phy: Make use of linkmode_mod_bit helper
From: David Miller @ 2019-07-09 3:11 UTC (permalink / raw)
To: huangfq.daxian; +Cc: andrew, f.fainelli, hkallweit1, netdev, linux-kernel
In-Reply-To: <20190708123417.12265-1-huangfq.daxian@gmail.com>
From: Fuqian Huang <huangfq.daxian@gmail.com>
Date: Mon, 8 Jul 2019 20:34:17 +0800
> linkmode_mod_bit is introduced as a helper function to set/clear
> bits in a linkmode.
> Replace the if else code structure with a call to the helper
> linkmode_mod_bit.
>
> Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v7 0/5] Add MPLS actions to TC
From: David Miller @ 2019-07-09 3:05 UTC (permalink / raw)
To: john.hurley
Cc: netdev, jiri, xiyou.wangcong, dsahern, willemdebruijn.kernel,
dcaratti, mrv, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1562508118-28841-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Sun, 7 Jul 2019 15:01:53 +0100
> This patchset introduces a new TC action module that allows the
> manipulation of the MPLS headers of packets. The code impliments
> functionality including push, pop, and modify.
>
> Also included are tests for the new funtionality. Note that these will
> require iproute2 changes to be submitted soon.
>
> NOTE: these patches are applied to net-next along with the patch:
> [PATCH net 1/1] net: openvswitch: fix csum updates for MPLS actions
> This patch has been accepted into net but, at time of posting, is not yet
> in net-next.
...
Thanks for mentioning that dependency.
Series applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH bpf-next v3] virtio_net: add XDP meta data support
From: Jason Wang @ 2019-07-09 3:04 UTC (permalink / raw)
To: Daniel Borkmann, Yuya Kusakabe
Cc: ast, davem, hawk, jakub.kicinski, john.fastabend, kafai, mst,
netdev, songliubraving, yhs
In-Reply-To: <a5f4601a-db0e-e65b-5b32-cc7e04ba90be@iogearbox.net>
On 2019/7/9 上午6:38, Daniel Borkmann wrote:
> On 07/02/2019 04:11 PM, Yuya Kusakabe wrote:
>> On 7/2/19 5:33 PM, Jason Wang wrote:
>>> On 2019/7/2 下午4:16, Yuya Kusakabe wrote:
>>>> This adds XDP meta data support to both receive_small() and
>>>> receive_mergeable().
>>>>
>>>> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
>>>> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
>>>> ---
>>>> v3:
>>>> - fix preserve the vnet header in receive_small().
>>>> v2:
>>>> - keep copy untouched in page_to_skb().
>>>> - preserve the vnet header in receive_small().
>>>> - fix indentation.
>>>> ---
>>>> drivers/net/virtio_net.c | 45 +++++++++++++++++++++++++++-------------
>>>> 1 file changed, 31 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>> index 4f3de0ac8b0b..03a1ae6fe267 100644
>>>> --- a/drivers/net/virtio_net.c
>>>> +++ b/drivers/net/virtio_net.c
>>>> @@ -371,7 +371,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>>>> struct receive_queue *rq,
>>>> struct page *page, unsigned int offset,
>>>> unsigned int len, unsigned int truesize,
>>>> - bool hdr_valid)
>>>> + bool hdr_valid, unsigned int metasize)
>>>> {
>>>> struct sk_buff *skb;
>>>> struct virtio_net_hdr_mrg_rxbuf *hdr;
>>>> @@ -393,7 +393,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>>>> else
>>>> hdr_padded_len = sizeof(struct padded_vnet_hdr);
>>>> - if (hdr_valid)
>>>> + if (hdr_valid && !metasize)
>>>> memcpy(hdr, p, hdr_len);
>>>> len -= hdr_len;
>>>> @@ -405,6 +405,11 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>>>> copy = skb_tailroom(skb);
>>>> skb_put_data(skb, p, copy);
>>>> + if (metasize) {
>>>> + __skb_pull(skb, metasize);
>>>> + skb_metadata_set(skb, metasize);
>>>> + }
>>>> +
>>>> len -= copy;
>>>> offset += copy;
>>>> @@ -644,6 +649,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
>>>> unsigned int delta = 0;
>>>> struct page *xdp_page;
>>>> int err;
>>>> + unsigned int metasize = 0;
>>>> len -= vi->hdr_len;
>>>> stats->bytes += len;
>>>> @@ -683,10 +689,13 @@ static struct sk_buff *receive_small(struct net_device *dev,
>>>> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
>>>> xdp.data = xdp.data_hard_start + xdp_headroom;
>>>> - xdp_set_data_meta_invalid(&xdp);
>>>> xdp.data_end = xdp.data + len;
>>>> + xdp.data_meta = xdp.data;
>>>> xdp.rxq = &rq->xdp_rxq;
>>>> orig_data = xdp.data;
>>>> + /* Copy the vnet header to the front of data_hard_start to avoid
>>>> + * overwriting by XDP meta data */
>>>> + memcpy(xdp.data_hard_start - vi->hdr_len, xdp.data - vi->hdr_len, vi->hdr_len);
> I'm not fully sure if I'm following this one correctly, probably just missing
> something. Isn't the vnet header based on how we set up xdp.data_hard_start
> earlier already in front of it? Wouldn't we copy invalid data from xdp.data -
> vi->hdr_len into the vnet header at that point (given there can be up to 256
> bytes of headroom between the two)? If it's relative to xdp.data and headroom
> is >0, then BPF prog could otherwise mangle this; something doesn't add up to
> me here. Could you clarify? Thx
Vnet headr sits just in front of xdp.data not xdp.data_hard_start. So it
could be overwrote by metadata, that's why we need a copy here.
Thanks
>
>>> What happens if we have a large metadata that occupies all headroom here?
>>>
>>> Thanks
>> Do you mean a large "XDP" metadata? If a large metadata is a large "XDP" metadata, I think we can not use a metadata that occupies all headroom. The size of metadata limited by bpf_xdp_adjust_meta() as below.
>> bpf_xdp_adjust_meta() in net/core/filter.c:
>> if (unlikely((metalen & (sizeof(__u32) - 1)) ||
>> (metalen > 32)))
>> return -EACCES;
>>
>> Thanks.
>>
>>>
>>>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>>>> stats->xdp_packets++;
>>>> @@ -695,9 +704,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
>>>> /* Recalculate length in case bpf program changed it */
>>>> delta = orig_data - xdp.data;
>>>> len = xdp.data_end - xdp.data;
>>>> + metasize = xdp.data - xdp.data_meta;
>>>> break;
>>>> case XDP_TX:
>>>> stats->xdp_tx++;
>>>> + xdp.data_meta = xdp.data;
>>>> xdpf = convert_to_xdp_frame(&xdp);
>>>> if (unlikely(!xdpf))
>>>> goto err_xdp;
>>>> @@ -736,10 +747,12 @@ static struct sk_buff *receive_small(struct net_device *dev,
>>>> skb_reserve(skb, headroom - delta);
>>>> skb_put(skb, len);
>>>> if (!delta) {
>>>> - buf += header_offset;
>>>> - memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
>>>> + memcpy(skb_vnet_hdr(skb), buf + VIRTNET_RX_PAD, vi->hdr_len);
>>>> } /* keep zeroed vnet hdr since packet was changed by bpf */
>>>> + if (metasize)
>>>> + skb_metadata_set(skb, metasize);
>>>> +
>>>> err:
>>>> return skb;
>>>> @@ -760,8 +773,8 @@ static struct sk_buff *receive_big(struct net_device *dev,
>>>> struct virtnet_rq_stats *stats)
>>>> {
>>>> struct page *page = buf;
>>>> - struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len,
>>>> - PAGE_SIZE, true);
>>>> + struct sk_buff *skb =
>>>> + page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, true, 0);
>>>> stats->bytes += len - vi->hdr_len;
>>>> if (unlikely(!skb))
>>>> @@ -793,6 +806,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>>>> unsigned int truesize;
>>>> unsigned int headroom = mergeable_ctx_to_headroom(ctx);
>>>> int err;
>>>> + unsigned int metasize = 0;
>>>> head_skb = NULL;
>>>> stats->bytes += len - vi->hdr_len;
>>>> @@ -839,8 +853,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>>>> data = page_address(xdp_page) + offset;
>>>> xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;
>>>> xdp.data = data + vi->hdr_len;
>>>> - xdp_set_data_meta_invalid(&xdp);
>>>> xdp.data_end = xdp.data + (len - vi->hdr_len);
>>>> + xdp.data_meta = xdp.data;
>>>> xdp.rxq = &rq->xdp_rxq;
>>>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>>>> @@ -852,8 +866,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>>>> * adjustments. Note other cases do not build an
>>>> * skb and avoid using offset
>>>> */
>>>> - offset = xdp.data -
>>>> - page_address(xdp_page) - vi->hdr_len;
>>>> + metasize = xdp.data - xdp.data_meta;
>>>> + offset = xdp.data - page_address(xdp_page) -
>>>> + vi->hdr_len - metasize;
>>>> /* recalculate len if xdp.data or xdp.data_end were
>>>> * adjusted
>>>> @@ -863,14 +878,15 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>>>> if (unlikely(xdp_page != page)) {
>>>> rcu_read_unlock();
>>>> put_page(page);
>>>> - head_skb = page_to_skb(vi, rq, xdp_page,
>>>> - offset, len,
>>>> - PAGE_SIZE, false);
>>>> + head_skb = page_to_skb(vi, rq, xdp_page, offset,
>>>> + len, PAGE_SIZE, false,
>>>> + metasize);
>>>> return head_skb;
>>>> }
>>>> break;
>>>> case XDP_TX:
>>>> stats->xdp_tx++;
>>>> + xdp.data_meta = xdp.data;
>>>> xdpf = convert_to_xdp_frame(&xdp);
>>>> if (unlikely(!xdpf))
>>>> goto err_xdp;
>>>> @@ -921,7 +937,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>>>> goto err_skb;
>>>> }
>>>> - head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog);
>>>> + head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
>>>> + metasize);
>>>> curr_skb = head_skb;
>>>> if (unlikely(!curr_skb))
^ permalink raw reply
* [PATCH net-next] net: dsa: vsc73xx: Fix Kconfig warning and build errors
From: YueHaibing @ 2019-07-09 3:02 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, davem, paweldembicki
Cc: linux-kernel, netdev, YueHaibing
In-Reply-To: <20190708172808.GG9027@lunn.ch>
Fix Kconfig dependency warning and subsequent build errors
caused by OF is not set:
WARNING: unmet direct dependencies detected for NET_DSA_VITESSE_VSC73XX
Depends on [n]: NETDEVICES [=y] && HAVE_NET_DSA [=y] && OF [=n] && NET_DSA [=m]
Selected by [m]:
- NET_DSA_VITESSE_VSC73XX_PLATFORM [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && HAS_IOMEM [=y]
Make NET_DSA_VITESSE_VSC73XX_SPI and NET_DSA_VITESSE_VSC73XX_PLATFORM
depends on NET_DSA_VITESSE_VSC73XX to fix this.
Reported-by: Hulk Robot <hulkci@huawei.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 95711cd5f0b4 ("net: dsa: vsc73xx: Split vsc73xx driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: Use "depends on" instead of "select" NET_DSA_VITESSE_VSC73XX
---
drivers/net/dsa/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index cf9dbd1..618853d 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -99,7 +99,7 @@ config NET_DSA_SMSC_LAN9303_MDIO
for MDIO managed mode.
config NET_DSA_VITESSE_VSC73XX
- tristate
+ tristate "Vitesse VSC7385/7388/7395/7398 support"
depends on OF
depends on NET_DSA
select FIXED_PHY
@@ -112,7 +112,7 @@ config NET_DSA_VITESSE_VSC73XX
config NET_DSA_VITESSE_VSC73XX_SPI
tristate "Vitesse VSC7385/7388/7395/7398 SPI mode support"
depends on SPI
- select NET_DSA_VITESSE_VSC73XX
+ depends on NET_DSA_VITESSE_VSC73XX
---help---
This enables support for the Vitesse VSC7385, VSC7388, VSC7395
and VSC7398 SparX integrated ethernet switches in SPI managed mode.
@@ -120,7 +120,7 @@ config NET_DSA_VITESSE_VSC73XX_SPI
config NET_DSA_VITESSE_VSC73XX_PLATFORM
tristate "Vitesse VSC7385/7388/7395/7398 Platform mode support"
depends on HAS_IOMEM
- select NET_DSA_VITESSE_VSC73XX
+ depends on NET_DSA_VITESSE_VSC73XX
---help---
This enables support for the Vitesse VSC7385, VSC7388, VSC7395
and VSC7398 SparX integrated ethernet switches, connected over
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 net-next 00/19] Add ionic driver
From: Shannon Nelson @ 2019-07-09 3:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20190708.195806.758232640547515457.davem@davemloft.net>
On 7/8/19 7:58 PM, David Miller wrote:
> From: Shannon Nelson <snelson@pensando.io>
> Date: Mon, 8 Jul 2019 12:25:13 -0700
>
>> This is a patch series that adds the ionic driver, supporting the Pensando
>> ethernet device.
> ...
>
> I think with the review comments and feedback still coming in you will
> have to wait until the next merge window, sorry.
Yep, that's what I was expecting - I'll have another patchset version
ready by then.
Cheers,
sln
^ permalink raw reply
* Re: [PATCH v3 net-next 00/19] Add ionic driver
From: David Miller @ 2019-07-09 2:58 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190708192532.27420-1-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 8 Jul 2019 12:25:13 -0700
> This is a patch series that adds the ionic driver, supporting the Pensando
> ethernet device.
...
I think with the review comments and feedback still coming in you will
have to wait until the next merge window, sorry.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: David Miller @ 2019-07-09 2:57 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, mcroce, fw
In-Reply-To: <20190709102728.70299ba8@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jul 2019 10:27:28 +1000
> I am still getting this conflict (the commit ids may have changed).
> Just a reminder in case you think Linus may need to know.
I'm resolving this right now, thanks Stephen.
^ permalink raw reply
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
From: wenxu @ 2019-07-09 2:56 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20190708141730.ozycgmtrub7ok2qs@breakpoint.cc>
On 7/8/2019 10:17 PM, Florian Westphal wrote:
> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> Add nf_nat_bridge_ops to do nat in the bridge family
> Whats the use case for this?
>
> The reason I'm asking is that a bridge doesn't know about IP,
> Bridge netfilter (the call-iptables thing) has a lot of glue code
> to detect dnat rewrites and updates target mac address, including
> support for redirect (suddently packet has to be pushed up the stack)
> or changes in the oif to non-bridge ports (it even checks forward sysctl
> state ..) and so on.
>
> Thats something that I don't want to support in nftables.
>
> For NAT on bridge, it should be possible already to push such packets
> up the stack by
>
> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
> meta pkttype set unicast ether daddr set 00:11:22:33:44:55
yes, packet can be push up to IP stack to handle the nat through bridge device.
In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
is the same known by outer. So The bridge can just do nat( without modify mac address or oif).
But in This case modify the packet dmac to bridge device, the packet push up through bridge device
Then do nat and route send back to bridge device.
^ permalink raw reply
* [PATCH net-next 11/11] net/tls: fix socket wmem accounting on fallback with netem
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
netem runs skb_orphan_partial() which "disconnects" the skb
from normal TCP write memory accounting. We should not adjust
sk->sk_wmem_alloc on the fallback path for such skbs.
Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
net/tls/tls_device_fallback.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/tls/tls_device_fallback.c b/net/tls/tls_device_fallback.c
index 1d2d804ac633..9070d68a92a4 100644
--- a/net/tls/tls_device_fallback.c
+++ b/net/tls/tls_device_fallback.c
@@ -209,6 +209,10 @@ static void complete_skb(struct sk_buff *nskb, struct sk_buff *skb, int headln)
update_chksum(nskb, headln);
+ /* sock_efree means skb must gone through skb_orphan_partial() */
+ if (nskb->destructor == sock_efree)
+ return;
+
delta = nskb->truesize - skb->truesize;
if (likely(delta < 0))
WARN_ON_ONCE(refcount_sub_and_test(-delta, &sk->sk_wmem_alloc));
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 10/11] nfp: tls: undo TLS sequence tracking when dropping the frame
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
If driver has to drop the TLS frame it needs to undo the TCP
sequence tracking changes, otherwise device will receive
segments out of order and drop them.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
.../ethernet/netronome/nfp/nfp_net_common.c | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 54dd98b2d645..9903805717da 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -893,6 +893,28 @@ nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
return skb;
}
+static void nfp_net_tls_tx_undo(struct sk_buff *skb, u64 tls_handle)
+{
+#ifdef CONFIG_TLS_DEVICE
+ struct nfp_net_tls_offload_ctx *ntls;
+ u32 datalen, seq;
+
+ if (!tls_handle)
+ return;
+ if (WARN_ON_ONCE(!skb->sk || !tls_is_sk_tx_device_offloaded(skb->sk)))
+ return;
+
+ datalen = skb->len - (skb_transport_offset(skb) + tcp_hdrlen(skb));
+ seq = ntohl(tcp_hdr(skb)->seq);
+
+ ntls = tls_driver_ctx(skb->sk, TLS_OFFLOAD_CTX_DIR_TX);
+ if (ntls->next_seq == seq + datalen)
+ ntls->next_seq = seq;
+ else
+ WARN_ON_ONCE(1);
+#endif
+}
+
static void nfp_net_tx_xmit_more_flush(struct nfp_net_tx_ring *tx_ring)
{
wmb();
@@ -1102,6 +1124,7 @@ static int nfp_net_tx(struct sk_buff *skb, struct net_device *netdev)
u64_stats_update_begin(&r_vec->tx_sync);
r_vec->tx_errors++;
u64_stats_update_end(&r_vec->tx_sync);
+ nfp_net_tls_tx_undo(skb, tls_handle);
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 08/11] net/tls: add missing prot info init
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Turns out TLS_TX in HW offload mode does not initialize tls_prot_info.
Since commit 9cd81988cce1 ("net/tls: use version from prot") we actually
use this field on the datapath. Luckily we always compare it to TLS 1.3,
and assume 1.2 otherwise. So since zero is not equal to 1.3, everything
worked fine.
Fixes: 9cd81988cce1 ("net/tls: use version from prot")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
net/tls/tls_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 56135f3ff4ff..06c30f677f7a 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -878,6 +878,8 @@ int tls_set_device_offload(struct sock *sk, struct tls_context *ctx)
goto free_offload_ctx;
}
+ prot->version = crypto_info->version;
+ prot->cipher_type = crypto_info->cipher_type;
prot->prepend_size = TLS_HEADER_SIZE + nonce_size;
prot->tag_size = tag_size;
prot->overhead_size = prot->prepend_size + prot->tag_size;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 09/11] nfp: tls: avoid one of the ifdefs for TLS
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Move the #ifdef CONFIG_TLS_DEVICE a little so we can eliminate
the other one.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 9a4421df9be9..54dd98b2d645 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -822,11 +822,11 @@ static void nfp_net_tx_csum(struct nfp_net_dp *dp,
u64_stats_update_end(&r_vec->tx_sync);
}
-#ifdef CONFIG_TLS_DEVICE
static struct sk_buff *
nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
struct sk_buff *skb, u64 *tls_handle, int *nr_frags)
{
+#ifdef CONFIG_TLS_DEVICE
struct nfp_net_tls_offload_ctx *ntls;
struct sk_buff *nskb;
bool resync_pending;
@@ -889,9 +889,9 @@ nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
memcpy(tls_handle, ntls->fw_handle, sizeof(ntls->fw_handle));
ntls->next_seq += datalen;
+#endif
return skb;
}
-#endif
static void nfp_net_tx_xmit_more_flush(struct nfp_net_tx_ring *tx_ring)
{
@@ -985,13 +985,11 @@ static int nfp_net_tx(struct sk_buff *skb, struct net_device *netdev)
return NETDEV_TX_BUSY;
}
-#ifdef CONFIG_TLS_DEVICE
skb = nfp_net_tls_tx(dp, r_vec, skb, &tls_handle, &nr_frags);
if (unlikely(!skb)) {
nfp_net_tx_xmit_more_flush(tx_ring);
return NETDEV_TX_OK;
}
-#endif
md_bytes = nfp_net_prep_tx_meta(skb, tls_handle);
if (unlikely(md_bytes < 0))
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 07/11] nfp: tls: don't leave key material in freed FW cmsg skbs
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Make sure the contents of the skb which carried key material
to the FW is cleared.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/crypto/tls.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index d448c6de8ea4..96a96b35c0ca 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -4,6 +4,7 @@
#include <linux/bitfield.h>
#include <linux/ipv6.h>
#include <linux/skbuff.h>
+#include <linux/string.h>
#include <net/tls.h>
#include "../ccm.h"
@@ -340,8 +341,22 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
memcpy(&back->salt, tls_ci->salt, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
memcpy(back->rec_no, tls_ci->rec_seq, sizeof(tls_ci->rec_seq));
+ /* Get an extra ref on the skb so we can wipe the key after */
+ skb_get(skb);
+
err = nfp_ccm_mbox_communicate(nn, skb, NFP_CCM_TYPE_CRYPTO_ADD,
sizeof(*reply), sizeof(*reply));
+ reply = (void *)skb->data;
+
+ /* We depend on CCM MBOX code not reallocating skb we sent
+ * so we can clear the key material out of the memory.
+ */
+ if (!WARN_ON_ONCE((u8 *)back < skb->head ||
+ (u8 *)back > skb_end_pointer(skb)) &&
+ !WARN_ON_ONCE((u8 *)&reply[1] > (u8 *)back))
+ memzero_explicit(back, sizeof(*back));
+ dev_consume_skb_any(skb); /* the extra ref from skb_get() above */
+
if (err) {
nn_dp_warn(&nn->dp, "failed to add TLS: %d (%d)\n",
err, direction == TLS_OFFLOAD_CTX_DIR_TX);
@@ -349,7 +364,6 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
goto err_conn_remove;
}
- reply = (void *)skb->data;
err = -be32_to_cpu(reply->error);
if (err) {
if (err == -ENOSPC) {
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 06/11] net/tls: don't clear TX resync flag on error
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Dirk van der Merwe,
Jakub Kicinski
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Introduce a return code for the tls_dev_resync callback.
When the driver TX resync fails, kernel can retry the resync again
until it succeeds. This prevents drivers from attempting to offload
TLS packets if the connection is known to be out of sync.
We don't worry about the RX resync since they will be retried naturally
as more encrypted records get received.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../net/ethernet/mellanox/mlx5/core/en_accel/tls.c | 8 +++++---
drivers/net/ethernet/netronome/nfp/crypto/tls.c | 13 +++++++++----
include/net/tls.h | 6 +++---
net/tls/tls_device.c | 8 ++++++--
4 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
index f8b93b62a7d2..ca07c86427a7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
@@ -160,9 +160,9 @@ static void mlx5e_tls_del(struct net_device *netdev,
direction == TLS_OFFLOAD_CTX_DIR_TX);
}
-static void mlx5e_tls_resync(struct net_device *netdev, struct sock *sk,
- u32 seq, u8 *rcd_sn_data,
- enum tls_offload_ctx_dir direction)
+static int mlx5e_tls_resync(struct net_device *netdev, struct sock *sk,
+ u32 seq, u8 *rcd_sn_data,
+ enum tls_offload_ctx_dir direction)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct mlx5e_priv *priv = netdev_priv(netdev);
@@ -177,6 +177,8 @@ static void mlx5e_tls_resync(struct net_device *netdev, struct sock *sk,
be64_to_cpu(rcd_sn));
mlx5_accel_tls_resync_rx(priv->mdev, rx_ctx->handle, seq, rcd_sn);
atomic64_inc(&priv->tls->sw_stats.rx_tls_resync_reply);
+
+ return 0;
}
static const struct tlsdev_ops mlx5e_tls_ops = {
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index b49405b4af55..d448c6de8ea4 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -403,7 +403,7 @@ nfp_net_tls_del(struct net_device *netdev, struct tls_context *tls_ctx,
nfp_net_tls_del_fw(nn, ntls->fw_handle);
}
-static void
+static int
nfp_net_tls_resync(struct net_device *netdev, struct sock *sk, u32 seq,
u8 *rcd_sn, enum tls_offload_ctx_dir direction)
{
@@ -412,11 +412,12 @@ nfp_net_tls_resync(struct net_device *netdev, struct sock *sk, u32 seq,
struct nfp_crypto_req_update *req;
struct sk_buff *skb;
gfp_t flags;
+ int err;
flags = direction == TLS_OFFLOAD_CTX_DIR_TX ? GFP_KERNEL : GFP_ATOMIC;
skb = nfp_net_tls_alloc_simple(nn, sizeof(*req), flags);
if (!skb)
- return;
+ return -ENOMEM;
ntls = tls_driver_ctx(sk, direction);
req = (void *)skb->data;
@@ -428,13 +429,17 @@ nfp_net_tls_resync(struct net_device *netdev, struct sock *sk, u32 seq,
memcpy(req->rec_no, rcd_sn, sizeof(req->rec_no));
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- nfp_net_tls_communicate_simple(nn, skb, "sync",
- NFP_CCM_TYPE_CRYPTO_UPDATE);
+ err = nfp_net_tls_communicate_simple(nn, skb, "sync",
+ NFP_CCM_TYPE_CRYPTO_UPDATE);
+ if (err)
+ return err;
ntls->next_seq = seq;
} else {
nfp_ccm_mbox_post(nn, skb, NFP_CCM_TYPE_CRYPTO_UPDATE,
sizeof(struct nfp_crypto_reply_simple));
}
+
+ return 0;
}
static const struct tlsdev_ops nfp_net_tls_ops = {
diff --git a/include/net/tls.h b/include/net/tls.h
index 0279938386ab..0e4b9624361b 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -304,9 +304,9 @@ struct tlsdev_ops {
void (*tls_dev_del)(struct net_device *netdev,
struct tls_context *ctx,
enum tls_offload_ctx_dir direction);
- void (*tls_dev_resync)(struct net_device *netdev,
- struct sock *sk, u32 seq, u8 *rcd_sn,
- enum tls_offload_ctx_dir direction);
+ int (*tls_dev_resync)(struct net_device *netdev,
+ struct sock *sk, u32 seq, u8 *rcd_sn,
+ enum tls_offload_ctx_dir direction);
};
enum tls_offload_sync_type {
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 40076f423dcb..56135f3ff4ff 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -214,6 +214,7 @@ static void tls_device_resync_tx(struct sock *sk, struct tls_context *tls_ctx,
{
struct net_device *netdev;
struct sk_buff *skb;
+ int err = 0;
u8 *rcd_sn;
skb = tcp_write_queue_tail(sk);
@@ -225,9 +226,12 @@ static void tls_device_resync_tx(struct sock *sk, struct tls_context *tls_ctx,
down_read(&device_offload_lock);
netdev = tls_ctx->netdev;
if (netdev)
- netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq, rcd_sn,
- TLS_OFFLOAD_CTX_DIR_TX);
+ err = netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq,
+ rcd_sn,
+ TLS_OFFLOAD_CTX_DIR_TX);
up_read(&device_offload_lock);
+ if (err)
+ return;
clear_bit_unlock(TLS_TX_SYNC_SCHED, &tls_ctx->flags);
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 05/11] nfp: tls: count TSO segments separately for the TLS offload
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Count the number of successfully submitted TLS segments,
not skbs. This will make it easier to compare the TLS
encryption count against other counters.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 270334427448..9a4421df9be9 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -880,7 +880,10 @@ nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
if (datalen) {
u64_stats_update_begin(&r_vec->tx_sync);
- r_vec->hw_tls_tx++;
+ if (!skb_is_gso(skb))
+ r_vec->hw_tls_tx++;
+ else
+ r_vec->hw_tls_tx += skb_shinfo(skb)->gso_segs;
u64_stats_update_end(&r_vec->tx_sync);
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 04/11] nfp: ccm: increase message limits
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Dirk van der Merwe,
Jakub Kicinski
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Increase the batch limit to consume small message bursts more
effectively. Practically, the effect on the 'add' messages is not
significant since the mailbox is sized such that the 'add' messages are
still limited to the same order of magnitude that it was originally set
for.
Furthermore, increase the queue size limit to 1024 entries. This further
improves the handling of bursts of small control messages.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/ccm_mbox.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
index d160ac794d98..f0783aa9e66e 100644
--- a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
+++ b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
@@ -13,7 +13,7 @@
* form a batch. Threads come in with CMSG formed in an skb, then
* enqueue that skb onto the request queue. If threads skb is first
* in queue this thread will handle the mailbox operation. It copies
- * up to 16 messages into the mailbox (making sure that both requests
+ * up to 64 messages into the mailbox (making sure that both requests
* and replies will fit. After FW is done processing the batch it
* copies the data out and wakes waiting threads.
* If a thread is waiting it either gets its the message completed
@@ -23,9 +23,9 @@
* to limit potential cache line bounces.
*/
-#define NFP_CCM_MBOX_BATCH_LIMIT 16
+#define NFP_CCM_MBOX_BATCH_LIMIT 64
#define NFP_CCM_TIMEOUT (NFP_NET_POLL_TIMEOUT * 1000)
-#define NFP_CCM_MAX_QLEN 256
+#define NFP_CCM_MAX_QLEN 1024
enum nfp_net_mbox_cmsg_state {
NFP_NET_MBOX_CMSG_STATE_QUEUED,
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 03/11] nfp: tls: use unique connection ids instead of 4-tuple for TX
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Connection 4 tuple reuse is slightly problematic - TLS socket
and context do not get destroyed until all the associated skbs
left the system and all references are released. This leads
to stale connection entry in the device preventing addition
of new one if the 4 tuple is reused quickly enough.
Instead of using read 4 tuple as the key use a unique ID.
Set the protocol to TCP and port to 0 to ensure no collisions
with real connections.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
.../net/ethernet/netronome/nfp/crypto/fw.h | 2 +
.../net/ethernet/netronome/nfp/crypto/tls.c | 43 +++++++++++++------
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 ++
3 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/fw.h b/drivers/net/ethernet/netronome/nfp/crypto/fw.h
index 192ba907d91b..67413d946c4a 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/fw.h
+++ b/drivers/net/ethernet/netronome/nfp/crypto/fw.h
@@ -31,6 +31,8 @@ struct nfp_crypto_req_add_front {
u8 key_len;
__be16 ipver_vlan __packed;
u8 l4_proto;
+#define NFP_NET_TLS_NON_ADDR_KEY_LEN 8
+ u8 l3_addrs[0];
};
struct nfp_crypto_req_add_back {
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index b13b3dbd4843..b49405b4af55 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -155,17 +155,30 @@ nfp_net_tls_set_ipver_vlan(struct nfp_crypto_req_add_front *front, u8 ipver)
NFP_NET_TLS_VLAN_UNUSED));
}
+static void
+nfp_net_tls_assign_conn_id(struct nfp_net *nn,
+ struct nfp_crypto_req_add_front *front)
+{
+ u32 len;
+ u64 id;
+
+ id = atomic64_inc_return(&nn->ktls_conn_id_gen);
+ len = front->key_len - NFP_NET_TLS_NON_ADDR_KEY_LEN;
+
+ memcpy(front->l3_addrs, &id, sizeof(id));
+ memset(front->l3_addrs + sizeof(id), 0, len - sizeof(id));
+}
+
static struct nfp_crypto_req_add_back *
-nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
- int direction)
+nfp_net_tls_set_ipv4(struct nfp_net *nn, struct nfp_crypto_req_add_v4 *req,
+ struct sock *sk, int direction)
{
struct inet_sock *inet = inet_sk(sk);
req->front.key_len += sizeof(__be32) * 2;
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- req->src_ip = inet->inet_saddr;
- req->dst_ip = inet->inet_daddr;
+ nfp_net_tls_assign_conn_id(nn, &req->front);
} else {
req->src_ip = inet->inet_daddr;
req->dst_ip = inet->inet_saddr;
@@ -175,8 +188,8 @@ nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
}
static struct nfp_crypto_req_add_back *
-nfp_net_tls_set_ipv6(struct nfp_crypto_req_add_v6 *req, struct sock *sk,
- int direction)
+nfp_net_tls_set_ipv6(struct nfp_net *nn, struct nfp_crypto_req_add_v6 *req,
+ struct sock *sk, int direction)
{
#if IS_ENABLED(CONFIG_IPV6)
struct ipv6_pinfo *np = inet6_sk(sk);
@@ -184,8 +197,7 @@ nfp_net_tls_set_ipv6(struct nfp_crypto_req_add_v6 *req, struct sock *sk,
req->front.key_len += sizeof(struct in6_addr) * 2;
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- memcpy(req->src_ip, &np->saddr, sizeof(req->src_ip));
- memcpy(req->dst_ip, &sk->sk_v6_daddr, sizeof(req->dst_ip));
+ nfp_net_tls_assign_conn_id(nn, &req->front);
} else {
memcpy(req->src_ip, &sk->sk_v6_daddr, sizeof(req->src_ip));
memcpy(req->dst_ip, &np->saddr, sizeof(req->dst_ip));
@@ -205,8 +217,8 @@ nfp_net_tls_set_l4(struct nfp_crypto_req_add_front *front,
front->l4_proto = IPPROTO_TCP;
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- back->src_port = inet->inet_sport;
- back->dst_port = inet->inet_dport;
+ back->src_port = 0;
+ back->dst_port = 0;
} else {
back->src_port = inet->inet_dport;
back->dst_port = inet->inet_sport;
@@ -260,6 +272,7 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
struct nfp_crypto_reply_add *reply;
struct sk_buff *skb;
size_t req_sz;
+ void *req;
bool ipv6;
int err;
@@ -302,16 +315,17 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
front = (void *)skb->data;
front->ep_id = 0;
- front->key_len = 8;
+ front->key_len = NFP_NET_TLS_NON_ADDR_KEY_LEN;
front->opcode = nfp_tls_1_2_dir_to_opcode(direction);
memset(front->resv, 0, sizeof(front->resv));
nfp_net_tls_set_ipver_vlan(front, ipv6 ? 6 : 4);
+ req = (void *)skb->data;
if (ipv6)
- back = nfp_net_tls_set_ipv6((void *)skb->data, sk, direction);
+ back = nfp_net_tls_set_ipv6(nn, req, sk, direction);
else
- back = nfp_net_tls_set_ipv4((void *)skb->data, sk, direction);
+ back = nfp_net_tls_set_ipv4(nn, req, sk, direction);
nfp_net_tls_set_l4(front, back, sk, direction);
@@ -329,7 +343,8 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
err = nfp_ccm_mbox_communicate(nn, skb, NFP_CCM_TYPE_CRYPTO_ADD,
sizeof(*reply), sizeof(*reply));
if (err) {
- nn_dp_warn(&nn->dp, "failed to add TLS: %d\n", err);
+ nn_dp_warn(&nn->dp, "failed to add TLS: %d (%d)\n",
+ err, direction == TLS_OFFLOAD_CTX_DIR_TX);
/* communicate frees skb on error */
goto err_conn_remove;
}
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net.h b/drivers/net/ethernet/netronome/nfp/nfp_net.h
index 0659756bf2bb..5d6c3738b494 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net.h
@@ -583,6 +583,7 @@ struct nfp_net_dp {
* @tlv_caps: Parsed TLV capabilities
* @ktls_tx_conn_cnt: Number of offloaded kTLS TX connections
* @ktls_rx_conn_cnt: Number of offloaded kTLS RX connections
+ * @ktls_conn_id_gen: Trivial generator for kTLS connection ids (for TX)
* @ktls_no_space: Counter of firmware rejecting kTLS connection due to
* lack of space
* @mbox_cmsg: Common Control Message via vNIC mailbox state
@@ -670,6 +671,8 @@ struct nfp_net {
unsigned int ktls_tx_conn_cnt;
unsigned int ktls_rx_conn_cnt;
+ atomic64_t ktls_conn_id_gen;
+
atomic_t ktls_no_space;
struct {
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 02/11] nfp: tls: move setting ipver_vlan to a helper
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Long lines are ugly. No functional changes.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/crypto/tls.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index 086bea0a7f2d..b13b3dbd4843 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -147,6 +147,14 @@ static void nfp_net_tls_del_fw(struct nfp_net *nn, __be32 *fw_handle)
NFP_CCM_TYPE_CRYPTO_DEL);
}
+static void
+nfp_net_tls_set_ipver_vlan(struct nfp_crypto_req_add_front *front, u8 ipver)
+{
+ front->ipver_vlan = cpu_to_be16(FIELD_PREP(NFP_NET_TLS_IPVER, ipver) |
+ FIELD_PREP(NFP_NET_TLS_VLAN,
+ NFP_NET_TLS_VLAN_UNUSED));
+}
+
static struct nfp_crypto_req_add_back *
nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
int direction)
@@ -154,9 +162,6 @@ nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
struct inet_sock *inet = inet_sk(sk);
req->front.key_len += sizeof(__be32) * 2;
- req->front.ipver_vlan = cpu_to_be16(FIELD_PREP(NFP_NET_TLS_IPVER, 4) |
- FIELD_PREP(NFP_NET_TLS_VLAN,
- NFP_NET_TLS_VLAN_UNUSED));
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
req->src_ip = inet->inet_saddr;
@@ -177,9 +182,6 @@ nfp_net_tls_set_ipv6(struct nfp_crypto_req_add_v6 *req, struct sock *sk,
struct ipv6_pinfo *np = inet6_sk(sk);
req->front.key_len += sizeof(struct in6_addr) * 2;
- req->front.ipver_vlan = cpu_to_be16(FIELD_PREP(NFP_NET_TLS_IPVER, 6) |
- FIELD_PREP(NFP_NET_TLS_VLAN,
- NFP_NET_TLS_VLAN_UNUSED));
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
memcpy(req->src_ip, &np->saddr, sizeof(req->src_ip));
@@ -304,6 +306,8 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
front->opcode = nfp_tls_1_2_dir_to_opcode(direction);
memset(front->resv, 0, sizeof(front->resv));
+ nfp_net_tls_set_ipver_vlan(front, ipv6 ? 6 : 4);
+
if (ipv6)
back = nfp_net_tls_set_ipv6((void *)skb->data, sk, direction);
else
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 01/11] nfp: tls: ignore queue limits for delete commands
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
We need to do our best not to drop delete commands, otherwise
we will have stale entries in the connection table. Ignore
the control message queue limits for delete commands.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/ccm.h | 4 +++
drivers/net/ethernet/netronome/nfp/ccm_mbox.c | 25 +++++++++++++------
.../net/ethernet/netronome/nfp/crypto/tls.c | 5 ++--
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/ccm.h b/drivers/net/ethernet/netronome/nfp/ccm.h
index da1b1e20df51..a460c75522be 100644
--- a/drivers/net/ethernet/netronome/nfp/ccm.h
+++ b/drivers/net/ethernet/netronome/nfp/ccm.h
@@ -118,6 +118,10 @@ bool nfp_ccm_mbox_fits(struct nfp_net *nn, unsigned int size);
struct sk_buff *
nfp_ccm_mbox_msg_alloc(struct nfp_net *nn, unsigned int req_size,
unsigned int reply_size, gfp_t flags);
+int __nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
+ enum nfp_ccm_type type,
+ unsigned int reply_size,
+ unsigned int max_reply_size, bool critical);
int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
enum nfp_ccm_type type,
unsigned int reply_size,
diff --git a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
index 02fccd90961d..d160ac794d98 100644
--- a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
+++ b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
@@ -515,13 +515,13 @@ nfp_ccm_mbox_msg_prepare(struct nfp_net *nn, struct sk_buff *skb,
static int
nfp_ccm_mbox_msg_enqueue(struct nfp_net *nn, struct sk_buff *skb,
- enum nfp_ccm_type type)
+ enum nfp_ccm_type type, bool critical)
{
struct nfp_ccm_hdr *hdr;
assert_spin_locked(&nn->mbox_cmsg.queue.lock);
- if (nn->mbox_cmsg.queue.qlen >= NFP_CCM_MAX_QLEN) {
+ if (!critical && nn->mbox_cmsg.queue.qlen >= NFP_CCM_MAX_QLEN) {
nn_dp_warn(&nn->dp, "mailbox request queue too long\n");
return -EBUSY;
}
@@ -536,10 +536,10 @@ nfp_ccm_mbox_msg_enqueue(struct nfp_net *nn, struct sk_buff *skb,
return 0;
}
-int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
- enum nfp_ccm_type type,
- unsigned int reply_size,
- unsigned int max_reply_size)
+int __nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
+ enum nfp_ccm_type type,
+ unsigned int reply_size,
+ unsigned int max_reply_size, bool critical)
{
int err;
@@ -550,7 +550,7 @@ int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
spin_lock_bh(&nn->mbox_cmsg.queue.lock);
- err = nfp_ccm_mbox_msg_enqueue(nn, skb, type);
+ err = nfp_ccm_mbox_msg_enqueue(nn, skb, type, critical);
if (err)
goto err_unlock;
@@ -594,6 +594,15 @@ int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
return err;
}
+int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
+ enum nfp_ccm_type type,
+ unsigned int reply_size,
+ unsigned int max_reply_size)
+{
+ return __nfp_ccm_mbox_communicate(nn, skb, type, reply_size,
+ max_reply_size, false);
+}
+
static void nfp_ccm_mbox_post_runq_work(struct work_struct *work)
{
struct sk_buff *skb;
@@ -650,7 +659,7 @@ int nfp_ccm_mbox_post(struct nfp_net *nn, struct sk_buff *skb,
spin_lock_bh(&nn->mbox_cmsg.queue.lock);
- err = nfp_ccm_mbox_msg_enqueue(nn, skb, type);
+ err = nfp_ccm_mbox_msg_enqueue(nn, skb, type, false);
if (err)
goto err_unlock;
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index 9f7ccb7da417..086bea0a7f2d 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -112,8 +112,9 @@ nfp_net_tls_communicate_simple(struct nfp_net *nn, struct sk_buff *skb,
struct nfp_crypto_reply_simple *reply;
int err;
- err = nfp_ccm_mbox_communicate(nn, skb, type,
- sizeof(*reply), sizeof(*reply));
+ err = __nfp_ccm_mbox_communicate(nn, skb, type,
+ sizeof(*reply), sizeof(*reply),
+ type == NFP_CCM_TYPE_CRYPTO_DEL);
if (err) {
nn_dp_warn(&nn->dp, "failed to %s TLS: %d\n", name, err);
return err;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 00/11] nfp: tls: fixes for initial TLS support
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski
Hi!
This series brings various fixes to nfp tls offload recently added
to net-next.
First 4 patches revolve around device mailbox communication, trying
to make it more reliable. Next patch fixes statistical counter.
Patch 6 improves the TX resync if device communication failed.
Patch 7 makes sure we remove keys from memory after talking to FW.
Patch 8 adds missing tls context initialization, we fill in the
context information from various places based on the configuration
and looks like we missed the init in the case of where TX is
offloaded, but RX wasn't initialized yet. Patches 9 and 10 make
the nfp driver undo TLS state changes if we need to drop the
frame (e.g. due to DMA mapping error).
Last but not least TLS fallback should not adjust socket memory
after skb_orphan_partial(). This code will go away once we forbid
orphaning of skbs in need of crypto, but that's "real" -next
material, so lets do a quick fix.
Dirk van der Merwe (2):
nfp: ccm: increase message limits
net/tls: don't clear TX resync flag on error
Jakub Kicinski (9):
nfp: tls: ignore queue limits for delete commands
nfp: tls: move setting ipver_vlan to a helper
nfp: tls: use unique connection ids instead of 4-tuple for TX
nfp: tls: count TSO segments separately for the TLS offload
nfp: tls: don't leave key material in freed FW cmsg skbs
net/tls: add missing prot info init
nfp: tls: avoid one of the ifdefs for TLS
nfp: tls: undo TLS sequence tracking when dropping the frame
net/tls: fix socket wmem accounting on fallback with netem
.../mellanox/mlx5/core/en_accel/tls.c | 8 +-
drivers/net/ethernet/netronome/nfp/ccm.h | 4 +
drivers/net/ethernet/netronome/nfp/ccm_mbox.c | 31 ++++---
.../net/ethernet/netronome/nfp/crypto/fw.h | 2 +
.../net/ethernet/netronome/nfp/crypto/tls.c | 93 +++++++++++++------
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 +
.../ethernet/netronome/nfp/nfp_net_common.c | 32 ++++++-
include/net/tls.h | 6 +-
net/tls/tls_device.c | 10 +-
net/tls/tls_device_fallback.c | 4 +
10 files changed, 143 insertions(+), 50 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
From: Jason Wang @ 2019-07-09 2:50 UTC (permalink / raw)
To: Tiwei Bie, Alex Williamson
Cc: mst, maxime.coquelin, linux-kernel, kvm, virtualization, netdev,
dan.daly, cunming.liang, zhihong.wang, idos, Rob Miller,
Ariel Adam
In-Reply-To: <20190708061625.GA15936@___>
On 2019/7/8 下午2:16, Tiwei Bie wrote:
> On Fri, Jul 05, 2019 at 08:49:46AM -0600, Alex Williamson wrote:
>> On Thu, 4 Jul 2019 14:21:34 +0800
>> Tiwei Bie <tiwei.bie@intel.com> wrote:
>>> On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote:
>>>> On 2019/7/3 下午9:08, Tiwei Bie wrote:
>>>>> On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
>>>>>> On 2019/7/3 下午7:52, Tiwei Bie wrote:
>>>>>>> On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
>>>>>>>> On 2019/7/3 下午5:13, Tiwei Bie wrote:
>>>>>>>>> Details about this can be found here:
>>>>>>>>>
>>>>>>>>> https://lwn.net/Articles/750770/
>>>>>>>>>
>>>>>>>>> What's new in this version
>>>>>>>>> ==========================
>>>>>>>>>
>>>>>>>>> A new VFIO device type is introduced - vfio-vhost. This addressed
>>>>>>>>> some comments from here:https://patchwork.ozlabs.org/cover/984763/
>>>>>>>>>
>>>>>>>>> Below is the updated device interface:
>>>>>>>>>
>>>>>>>>> Currently, there are two regions of this device: 1) CONFIG_REGION
>>>>>>>>> (VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to setup the
>>>>>>>>> device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX), which
>>>>>>>>> can be used to notify the device.
>>>>>>>>>
>>>>>>>>> 1. CONFIG_REGION
>>>>>>>>>
>>>>>>>>> The region described by CONFIG_REGION is the main control interface.
>>>>>>>>> Messages will be written to or read from this region.
>>>>>>>>>
>>>>>>>>> The message type is determined by the `request` field in message
>>>>>>>>> header. The message size is encoded in the message header too.
>>>>>>>>> The message format looks like this:
>>>>>>>>>
>>>>>>>>> struct vhost_vfio_op {
>>>>>>>>> __u64 request;
>>>>>>>>> __u32 flags;
>>>>>>>>> /* Flag values: */
>>>>>>>>> #define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need reply */
>>>>>>>>> __u32 size;
>>>>>>>>> union {
>>>>>>>>> __u64 u64;
>>>>>>>>> struct vhost_vring_state state;
>>>>>>>>> struct vhost_vring_addr addr;
>>>>>>>>> } payload;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> The existing vhost-kernel ioctl cmds are reused as the message
>>>>>>>>> requests in above structure.
>>>>>>>> Still a comments like V1. What's the advantage of inventing a new protocol?
>>>>>>> I'm trying to make it work in VFIO's way..
>>>>>>>
>>>>>>>> I believe either of the following should be better:
>>>>>>>>
>>>>>>>> - using vhost ioctl, we can start from SET_VRING_KICK/SET_VRING_CALL and
>>>>>>>> extend it with e.g notify region. The advantages is that all exist userspace
>>>>>>>> program could be reused without modification (or minimal modification). And
>>>>>>>> vhost API hides lots of details that is not necessary to be understood by
>>>>>>>> application (e.g in the case of container).
>>>>>>> Do you mean reusing vhost's ioctl on VFIO device fd directly,
>>>>>>> or introducing another mdev driver (i.e. vhost_mdev instead of
>>>>>>> using the existing vfio_mdev) for mdev device?
>>>>>> Can we simply add them into ioctl of mdev_parent_ops?
>>>>> Right, either way, these ioctls have to be and just need to be
>>>>> added in the ioctl of the mdev_parent_ops. But another thing we
>>>>> also need to consider is that which file descriptor the userspace
>>>>> will do the ioctl() on. So I'm wondering do you mean let the
>>>>> userspace do the ioctl() on the VFIO device fd of the mdev
>>>>> device?
>>>>>
>>>> Yes.
>>> Got it! I'm not sure what's Alex opinion on this. If we all
>>> agree with this, I can do it in this way.
>>>
>>>> Is there any other way btw?
>>> Just a quick thought.. Maybe totally a bad idea. I was thinking
>>> whether it would be odd to do non-VFIO's ioctls on VFIO's device
>>> fd. So I was wondering whether it's possible to allow binding
>>> another mdev driver (e.g. vhost_mdev) to the supported mdev
>>> devices. The new mdev driver, vhost_mdev, can provide similar
>>> ways to let userspace open the mdev device and do the vhost ioctls
>>> on it. To distinguish with the vfio_mdev compatible mdev devices,
>>> the device API of the new vhost_mdev compatible mdev devices
>>> might be e.g. "vhost-net" for net?
>>>
>>> So in VFIO case, the device will be for passthru directly. And
>>> in VHOST case, the device can be used to accelerate the existing
>>> virtualized devices.
>>>
>>> How do you think?
>> VFIO really can't prevent vendor specific ioctls on the device file
>> descriptor for mdevs, but a) we'd want to be sure the ioctl address
>> space can't collide with ioctls we'd use for vfio defined purposes and
>> b) maybe the VFIO user API isn't what you want in the first place if
>> you intend to mostly/entirely ignore the defined ioctl set and replace
>> them with your own. In the case of the latter, you're also not getting
>> the advantages of the existing VFIO userspace code, so why expose a
>> VFIO device at all.
> Yeah, I totally agree.
I guess the original idea is to reuse the VFIO DMA/IOMMU API for this.
Then we have the chance to reuse vfio codes in qemu for dealing with e.g
vIOMMU.
>
>> The mdev interface does provide a general interface for creating and
>> managing virtual devices, vfio-mdev is just one driver on the mdev
>> bus. Parav (Mellanox) has been doing work on mdev-core to help clean
>> out vfio-isms from the interface, aiui, with the intent of implementing
>> another mdev bus driver for using the devices within the kernel.
> Great to know this! I found below series after some searching:
>
> https://lkml.org/lkml/2019/3/8/821
>
> In above series, the new mlx5_core mdev driver will do the probe
> by calling mlx5_get_core_dev() first on the parent device of the
> mdev device. In vhost_mdev, maybe we can also keep track of all
> the compatible mdev devices and use this info to do the probe.
I don't get why this is needed. My understanding is if we want to go
this way, there're actually two parts. 1) Vhost mdev that implements the
device managements and vhost ioctl. 2) Vhost it self, which can accept
mdev fd as it backend through VHOST_NET_SET_BACKEND.
> But we also need a way to allow vfio_mdev driver to distinguish
> and reject the incompatible mdev devices.
One issue for this series is that it doesn't consider DMA isolation at all.
>
>> It
>> seems like this vhost-mdev driver might be similar, using mdev but not
>> necessarily vfio-mdev to expose devices. Thanks,
> Yeah, I also think so!
I've cced some driver developers for their inputs. I think we need a
sample parent drivers in the next version for us to understand the full
picture.
Thanks
>
> Thanks!
> Tiwei
>
>> Alex
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: allow up to four clocks for orion-mdio
From: Andrew Lunn @ 2019-07-09 2:41 UTC (permalink / raw)
To: Rob Herring; +Cc: josua, netdev, stable, David S. Miller, Mark Rutland
In-Reply-To: <CAL_JsqJJA6=2b=VzDzS1ipOatpRuVBUmReYoOMf-9p39=jyF8Q@mail.gmail.com>
> > Optional properties:
> > - interrupts: interrupt line number for the SMI error/done interrupt
> > -- clocks: phandle for up to three required clocks for the MDIO instance
> > +- clocks: phandle for up to four required clocks for the MDIO instance
>
> This needs to enumerate exactly what the clocks are. Shouldn't there
> be an additional clock-names value too?
Hi Rob
The driver does not care what they are called. It just turns them all
on, and turns them off again when removed.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2] skbuff: increase verbosity when dumping skb data
From: David Miller @ 2019-07-09 2:39 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, linyunsheng, willemb
In-Reply-To: <20190707095155.58578-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sun, 7 Jul 2019 05:51:55 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload and netdev_rx_csum_fault trigger on hard to debug
> issues. Dump more state and the header.
>
> Optionally dump the entire packet and linear segment. This is required
> to debug checksum bugs that may include bytes past skb_tail_pointer().
>
> Both call sites call this function inside a net_ratelimit() block.
> Limit full packet log further to a hard limit of can_dump_full (5).
>
> Based on an earlier patch by Cong Wang, see link below.
>
> Changes v1 -> v2
> - dump frag_list only on full_pkt
>
> Link: https://patchwork.ozlabs.org/patch/1000841/
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Nice to finally have this, applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: elide flowlabel check if no exclusive leases exist
From: David Miller @ 2019-07-09 2:38 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20190707093445.15121-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sun, 7 Jul 2019 05:34:45 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Processes can request ipv6 flowlabels with cmsg IPV6_FLOWINFO.
> If not set, by default an autogenerated flowlabel is selected.
>
> Explicit flowlabels require a control operation per label plus a
> datapath check on every connection (every datagram if unconnected).
> This is particularly expensive on unconnected sockets multiplexing
> many flows, such as QUIC.
>
> In the common case, where no lease is exclusive, the check can be
> safely elided, as both lease request and check trivially succeed.
> Indeed, autoflowlabel does the same even with exclusive leases.
>
> Elide the check if no process has requested an exclusive lease.
>
> fl6_sock_lookup previously returns either a reference to a lease or
> NULL to denote failure. Modify to return a real error and update
> all callers. On return NULL, they can use the label and will elide
> the atomic_dec in fl6_sock_release.
>
> This is an optimization. Robust applications still have to revert to
> requesting leases if the fast path fails due to an exclusive lease.
>
> Changes RFC->v1:
> - use static_key_false_deferred to rate limit jump label operations
> - call static_key_deferred_flush to stop timers on exit
> - move decrement out of RCU context
> - defer optimization also if opt data is associated with a lease
> - updated all fp6_sock_lookup callers, not just udp
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Looks good, applied, thanks Willem.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox