* [PATCH v2 08/10] net: hisilicon: Offset buf address to adapt HI13X1_GMAC
From: Jiangfeng Xiao @ 2019-07-09 3:31 UTC (permalink / raw)
To: davem, robh+dt, yisen.zhuang, salil.mehta, mark.rutland,
dingtianhong, xiaojiangfeng
Cc: netdev, devicetree, linux-kernel, leeyou.li, nixiaoming,
jianping.liu, xiekunxun
In-Reply-To: <1562643071-46811-1-git-send-email-xiaojiangfeng@huawei.com>
The buf unit size of HI13X1_GMAC is cache_line_size,
which is 64, so the address we write to the buf register
needs to be shifted right by 6 bits.
The 31st bit of the PPE_CFG_CPU_ADD_ADDR register
of HI13X1_GMAC indicates whether to release the buffer
of the message, and the low indicates that it is valid.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 5328219..c578934 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -120,12 +120,20 @@
#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(0)
#define PPE_CFG_QOS_VMID_MODE BIT(15)
#define PPE_CFG_BUS_LOCAL_REL (BIT(9) | BIT(15) | BIT(19) | BIT(23))
+
+/* buf unit size is cache_line_size, which is 64, so the shift is 6 */
+#define PPE_BUF_SIZE_SHIFT 6
+#define PPE_TX_BUF_HOLD BIT(31)
#else
#define PPE_CFG_QOS_VMID_GRP_SHIFT 8
#define PPE_CFG_RX_CTRL_ALIGN_SHIFT 11
#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(12)
#define PPE_CFG_QOS_VMID_MODE BIT(14)
#define PPE_CFG_BUS_LOCAL_REL BIT(14)
+
+/* buf unit size is 1, so the shift is 6 */
+#define PPE_BUF_SIZE_SHIFT 0
+#define PPE_TX_BUF_HOLD 0
#endif /* CONFIG_HI13X1_GMAC */
#define PPE_CFG_RX_FIFO_FSFU BIT(11)
@@ -286,7 +294,7 @@ static void hip04_config_fifo(struct hip04_priv *priv)
val |= PPE_CFG_QOS_VMID_MODE;
writel_relaxed(val, priv->base + PPE_CFG_QOS_VMID_GEN);
- val = RX_BUF_SIZE;
+ val = RX_BUF_SIZE >> PPE_BUF_SIZE_SHIFT;
regmap_write(priv->map, priv->port * 4 + PPE_CFG_RX_BUF_SIZE, val);
val = RX_DESC_NUM << PPE_CFG_RX_DEPTH_SHIFT;
@@ -369,12 +377,18 @@ static void hip04_mac_disable(struct net_device *ndev)
static void hip04_set_xmit_desc(struct hip04_priv *priv, dma_addr_t phys)
{
- writel(phys, priv->base + PPE_CFG_CPU_ADD_ADDR);
+ u32 val;
+
+ val = phys >> PPE_BUF_SIZE_SHIFT | PPE_TX_BUF_HOLD;
+ writel(val, priv->base + PPE_CFG_CPU_ADD_ADDR);
}
static void hip04_set_recv_desc(struct hip04_priv *priv, dma_addr_t phys)
{
- regmap_write(priv->map, priv->port * 4 + PPE_CFG_RX_ADDR, phys);
+ u32 val;
+
+ val = phys >> PPE_BUF_SIZE_SHIFT;
+ regmap_write(priv->map, priv->port * 4 + PPE_CFG_RX_ADDR, val);
}
static u32 hip04_recv_cnt(struct hip04_priv *priv)
--
1.8.5.6
^ permalink raw reply related
* [PATCH v2 09/10] net: hisilicon: Add an rx_desc to adapt HI13X1_GMAC
From: Jiangfeng Xiao @ 2019-07-09 3:31 UTC (permalink / raw)
To: davem, robh+dt, yisen.zhuang, salil.mehta, mark.rutland,
dingtianhong, xiaojiangfeng
Cc: netdev, devicetree, linux-kernel, leeyou.li, nixiaoming,
jianping.liu, xiekunxun
In-Reply-To: <1562643071-46811-1-git-send-email-xiaojiangfeng@huawei.com>
HI13X1 changed the offsets and bitmaps for rx_desc
registers in the same peripheral device on different
models of the hip04_eth.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index c578934..780fc46 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -171,11 +171,20 @@ struct tx_desc {
} __aligned(64);
struct rx_desc {
+#if defined(CONFIG_HI13X1_GMAC)
+ u32 reserved1[3];
+ u16 pkt_len;
+ u16 reserved_16;
+ u32 reserved2[6];
+ u32 pkt_err;
+ u32 reserved3[5];
+#else
u16 reserved_16;
u16 pkt_len;
u32 reserve1[3];
u32 pkt_err;
u32 reserve2[4];
+#endif
};
struct hip04_priv {
--
1.8.5.6
^ permalink raw reply related
* Re: [PATCH] phy: added a PHY_BUSY state into phy_state_machine
From: Andrew Lunn @ 2019-07-09 3:22 UTC (permalink / raw)
To: kwangdo yi; +Cc: Florian Fainelli, netdev, Heiner Kallweit
In-Reply-To: <CAFHy5LAQyL2JW1Lox67OSz2WuRnzhVgSk6-0hfHf=gG2fXYmRQ@mail.gmail.com>
On Mon, Jul 08, 2019 at 11:16:02PM -0400, kwangdo yi wrote:
> I simply fixed this issue by increasing the polling time from 20 msec to
> 60 msec in Xilinx EMAC driver. But the state machine would be in a
> better shape if it is capable of handling sub system driver's fake failure.
> PHY device driver could advertising the min/max timeouts for its subsystem,
> but still some vendor's EMAC driver fails to meet the deadline if this value
> is not set properly in PHY driver.
Hi Kwangdo
That is not how MDIO works. The PHY has two clock cycles to prepare
its response to any request. There is no min/max. This was always an
MDIO bus driver problem, not a PHY problem.
Andrew
^ permalink raw reply
* Re: [PATCH] r8169: add enable_aspm parameter
From: AceLan Kao @ 2019-07-09 3:19 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Realtek linux nic maintainers, David S. Miller, netdev,
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <53f82481-ed41-abc5-2e4e-ac1026617219@gmail.com>
Heiner Kallweit <hkallweit1@gmail.com> 於 2019年7月9日 週二 上午2:27寫道：
>
> On 08.07.2019 08:37, AceLan Kao wrote:
> > We have many commits in the driver which enable and then disable ASPM
> > function over and over again.
> > commit b75bb8a5b755 ("r8169: disable ASPM again")
> > commit 0866cd15029b ("r8169: enable ASPM on RTL8106E")
> > commit 94235460f9ea ("r8169: Align ASPM/CLKREQ setting function with vendor driver")
> > commit aa1e7d2c31ef ("r8169: enable ASPM on RTL8168E-VL")
> > commit f37658da21aa ("r8169: align ASPM entry latency setting with vendor driver")
> > commit a99790bf5c7f ("r8169: Reinstate ASPM Support")
> > commit 671646c151d4 ("r8169: Don't disable ASPM in the driver")
> > commit 4521e1a94279 ("Revert "r8169: enable internal ASPM and clock request settings".")
> > commit d64ec841517a ("r8169: enable internal ASPM and clock request settings")
> >
> > This function is very important for production, and if we can't come out
> > a solution to make both happy, I'd suggest we add a parameter in the
> > driver to toggle it.
> >
> The usage of a module parameter to control ASPM is discouraged.
> There have been more such attempts in the past that have been declined.
>
> Pending with the PCI maintainers is a series adding ASPM control
> via sysfs, see here: https://www.spinics.net/lists/linux-pci/msg83228.html
Cool, I'll try your patches and reply on that thread.
>
> Also more details than just stating "it's important for production"
> would have been appreciated in the commit message, e.g. which
> power-savings you can achieve with ASPM on which systems.
I should use more specific wordings rather than "important for
production", thanks.
^ permalink raw reply
* Re: [PATCH net-next] sctp: remove rcu_read_lock from sctp_bind_addr_state
From: David Miller @ 2019-07-09 3:18 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <30ff9e8a45fa0c64d1c71bc13e217f3374f6120e.1562605180.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 9 Jul 2019 00:59:40 +0800
> sctp_bind_addr_state() is called either in packet rcv path or
> by sctp_copy_local_addr_list(), which are under rcu_read_lock.
> So there's no need to call it again in sctp_bind_addr_state().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
This is correct, patch applied.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: vsc73xx: Fix Kconfig warning and build errors
From: Andrew Lunn @ 2019-07-09 3:17 UTC (permalink / raw)
To: YueHaibing
Cc: vivien.didelot, f.fainelli, davem, paweldembicki, linux-kernel,
netdev
In-Reply-To: <20190709030224.40292-1-yuehaibing@huawei.com>
On Tue, Jul 09, 2019 at 11:02:24AM +0800, YueHaibing wrote:
> 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>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/4] sctp: tidy up some ep and asoc feature flags
From: David Miller @ 2019-07-09 3:17 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1562604972.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 9 Jul 2019 00:57:03 +0800
> This patchset is to remove some unnecessary feature flags from
> sctp_assocation and move some others to the right places.
Since I'm trying to close up the net-next tree first thing tomorrow morning
I've taken the liberty of reviewing this the best that I can and it looks
good.
Series applied, thanks Xin.
^ permalink raw reply
* Re: [PATCH] phy: added a PHY_BUSY state into phy_state_machine
From: kwangdo yi @ 2019-07-09 3:16 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Andrew Lunn, Heiner Kallweit
In-Reply-To: <539888f4-e5be-7ad5-53ce-63dd182708b1@gmail.com>
I simply fixed this issue by increasing the polling time from 20 msec to
60 msec in Xilinx EMAC driver. But the state machine would be in a
better shape if it is capable of handling sub system driver's fake failure.
PHY device driver could advertising the min/max timeouts for its subsystem,
but still some vendor's EMAC driver fails to meet the deadline if this value
is not set properly in PHY driver.
On Sun, Jul 7, 2019 at 11:07 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> +Andrew, Heiner (please CC PHY library maintainers).
>
> On 7/7/2019 3:32 PM, kwangdo.yi wrote:
> > When mdio driver polling the phy state in the phy_state_machine,
> > sometimes it results in -ETIMEDOUT and link is down. But the phy
> > is still alive and just didn't meet the polling deadline.
> > Closing the phy link in this case seems too radical. Failing to
> > meet the deadline happens very rarely. When stress test runs for
> > tens of hours with multiple target boards (Xilinx Zynq7000 with
> > marvell 88E1512 PHY, Xilinx custom emac IP), it happens. This
> > patch gives another chance to the phy_state_machine when polling
> > timeout happens. Only two consecutive failing the deadline is
> > treated as the real phy halt and close the connection.
>
> How about simply increasing the MDIO polling timeout in the Xilinx EMAC
> driver instead? Or if the PHY is where the timeout needs to be
> increased, allow the PHY device drivers to advertise min/max timeouts
> such that the MDIO bus layer can use that information?
>
> >
> >
> > Signed-off-by: kwangdo.yi <kwangdo.yi@gmail.com>
> > ---
> > drivers/net/phy/phy.c | 6 ++++++
> > include/linux/phy.h | 1 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> > index e888542..9e8138b 100644
> > --- a/drivers/net/phy/phy.c
> > +++ b/drivers/net/phy/phy.c
> > @@ -919,7 +919,13 @@ void phy_state_machine(struct work_struct *work)
> > break;
> > case PHY_NOLINK:
> > case PHY_RUNNING:
> > + case PHY_BUSY:
> > err = phy_check_link_status(phydev);
> > + if (err == -ETIMEDOUT && old_state == PHY_RUNNING) {
> > + phy->state = PHY_BUSY;
> > + err = 0;
> > +
> > + }
> > break;
> > case PHY_FORCING:
> > err = genphy_update_link(phydev);
> > diff --git a/include/linux/phy.h b/include/linux/phy.h
> > index 6424586..4a49401 100644
> > --- a/include/linux/phy.h
> > +++ b/include/linux/phy.h
> > @@ -313,6 +313,7 @@ enum phy_state {
> > PHY_RUNNING,
> > PHY_NOLINK,
> > PHY_FORCING,
> > + PHY_BUSY,
> > };
> >
> > /**
> >
>
> --
> Florian
^ permalink raw reply
* Re: [GIT PULL] Keys: Set 3 - Keyrings namespacing for 5.3
From: pr-tracker-bot @ 2019-07-09 3:15 UTC (permalink / raw)
To: David Howells
Cc: torvalds, dhowells, jmorris, ebiederm, dwalsh, keyrings, netdev,
linux-nfs, linux-cifs, linux-afs, linux-security-module,
linux-kernel
In-Reply-To: <27850.1562361644@warthog.procyon.org.uk>
The pull request you sent on Fri, 05 Jul 2019 22:20:44 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-namespace-20190627
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e12256b9a76584fa3a6da19210509d4775aee36
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* 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
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