* [PATCH net 1/3] net: phy: fix sign type error in genphy_config_eee_advert
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Martin Blumenstingl,
Andre Roth, Andrew Lunn, Neil Armstrong, linux-amlogic,
linux-arm-kernel, linux-kernel, Julia Lawall, Yegor Yefremov,
Andreas Färber
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is
checked to know if the register could be accessed but the result is
assigned to a 'u32'.
Changing to 'int' to correctly get errors from phy_read_mmd_indirect.
Fixes: d853d145ea3e ("net: phy: add an option to disable EEE advertisement")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9c06f8028f0c..ee5ebadb1463 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1187,8 +1187,8 @@ static int genphy_config_advert(struct phy_device *phydev)
*/
static int genphy_config_eee_advert(struct phy_device *phydev)
{
- u32 broken = phydev->eee_broken_modes;
- u32 old_adv, adv;
+ int broken = phydev->eee_broken_modes;
+ int old_adv, adv;
/* Nothing to disable */
if (!broken)
--
2.7.4
^ permalink raw reply related
* [PATCH net] virtio_net: reject XDP programs using header adjustment
From: Jakub Kicinski @ 2016-12-19 15:05 UTC (permalink / raw)
To: netdev
Cc: john.fastabend, kafai, daniel, alexei.starovoitov, mst,
Jakub Kicinski
commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
added a new XDP helper to prepend and remove data from a frame.
Make virtio_net reject programs making use of this helper until
proper support is added.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/virtio_net.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 08327e005ccc..db761f37783e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1677,6 +1677,11 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
u16 xdp_qp = 0, curr_qp;
int i, err;
+ if (prog && prog->xdp_adjust_head) {
+ netdev_warn(dev, "Does not support bpf_xdp_adjust_head()\n");
+ return -EOPNOTSUPP;
+ }
+
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6)) {
netdev_warn(dev, "can't set XDP while host is implementing LRO, disable LRO first\n");
--
2.11.0
^ permalink raw reply related
* Re: Linux support for 802.1AS-Rev.
From: Richard Cochran @ 2016-12-19 15:06 UTC (permalink / raw)
To: Praveen Bajantri; +Cc: netdev
In-Reply-To: <CA+tSgV+DWJHJ4LBHTyX4bzwLyCq+3=4nOF+eLjWwFPyYfP6FsQ@mail.gmail.com>
On Mon, Dec 19, 2016 at 03:50:08PM +0530, Praveen Bajantri wrote:
> I am new to Linux networking and had doubt related to support for
> 802.1AS-Rev. Please point me to appropriate forum/mailing list If this
> is not a right place.
This list is for kernel related issues. The mailing lists for the
user space gPTP stack are at:
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
> Does Linux support 802.1AS-Rev ? Is there any application which can be
> used to test this feature ?
Looking at
http://www.ieee802.org/1/pages/802.1AS-rev.html
this standard hasn't even been published, and the drafts are locked
away for committee's eyes only.
So how on earth do you expect us to support it?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:07 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: Romain Perier, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement, netdev, devicetree,
Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <CABHmqqDqhJa6N=Ayu-GFNyp4g90dXzTje6o8qfCEP2DacCFWdQ@mail.gmail.com>
On Mon, Dec 19, 2016 at 04:04:32PM +0100, Volodymyr Bendiuga wrote:
> Hi Andrew,
>
> No, it did not get accepted. Or at least I did not see
> David accepting it. Let me know if I should resubmit it.
Hi Volodymyr
Please do resend it. Probably netdev will reopen sometime after the
25th.
Don't forget to include the reviewed-by i gave.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Niklas Cassel @ 2016-12-19 15:08 UTC (permalink / raw)
To: Pavel Machek, LinoSanfilippo, peppe.cavallaro, alexandre.torgue,
davem, linux-kernel, netdev, Joao.Pinto
In-Reply-To: <20161218203812.GA1012@amd>
Tested-by: Niklas Cassel <niklas.cassel@axis.com>
On 12/18/2016 09:38 PM, Pavel Machek wrote:
> Fix up memory barriers in stmmac driver. They are meant to protect
> against DMA engine, so smp_ variants are certainly wrong, and dma_
> variants are preferable.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index a340fc8..8816515 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -334,7 +334,7 @@ static void dwmac4_rd_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> @@ -377,7 +377,7 @@ static void dwmac4_rd_prepare_tso_tx_desc(struct dma_desc *p, int is_fs,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> index ce97e52..f0d8632 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> @@ -350,7 +350,7 @@ static void enh_desc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des0 = cpu_to_le32(tdes0);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..bb40382 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2125,7 +2125,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
>
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> @@ -2338,7 +2338,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
> }
>
> netdev_sent_queue(dev, skb->len);
> @@ -2443,14 +2443,14 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv)
> netif_dbg(priv, rx_status, priv->dev,
> "refill entry #%d\n", entry);
> }
> - wmb();
> + dma_wmb();
>
> if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00))
> priv->hw->desc->init_rx_desc(p, priv->use_riwt, 0, 0);
> else
> priv->hw->desc->set_rx_owner(p);
>
> - wmb();
> + dma_wmb();
>
> entry = STMMAC_GET_ENTRY(entry, DMA_RX_SIZE);
> }
>
^ permalink raw reply
* Re: [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
From: Jerome Brunet @ 2016-12-19 15:16 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, netdev, Neil Armstrong, linux-kernel,
Yegor Yefremov, Julia Lawall, Andre Roth, Kevin Hilman,
Carlo Caione, Giuseppe Cavallaro, linux-amlogic,
Andreas Färber, linux-arm-kernel
In-Reply-To: <20161205143942.f3w6nmp3jvmrk5es@rob-hp-laptop>
Hi Rob,
First, Thx for this information and sorry for this late reply
As you may have seen yourself, there was little bit of confusion while
discussing this patch series.
The point is the v3 was applied before your reply (patches 2 and 3 not
combined unfortunately).
Because of this confusion, the series needed a few fixes witch removes
the previously added bindings [0].
This time, I made sure to modify (remove) the bindings along with the
documentation.
[0]: http://lkml.kernel.org/r/1482159938-13239-1-git-send-email-jbrunet
@baylibre.com
Cheers
Jerome
On Mon, 2016-12-05 at 08:39 -0600, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> > Tested-by: Andreas Färber <afaerber@suse.de>
> > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> > create mode 100644 include/dt-bindings/net/mdio.h
>
> Seems changes are wanted on this, but patches 2 and 3 should be
> combined. The header is part of the binding doc.
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH net] virtio_net: reject XDP programs using header adjustment
From: Mintz, Yuval @ 2016-12-19 15:23 UTC (permalink / raw)
To: Jakub Kicinski, netdev@vger.kernel.org
Cc: john.fastabend@gmail.com, kafai@fb.com, daniel@iogearbox.net,
alexei.starovoitov@gmail.com, mst@redhat.com
In-Reply-To: <20161219150500.2600-1-jakub.kicinski@netronome.com>
> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
> added a new XDP helper to prepend and remove data from a frame.
> Make virtio_net reject programs making use of this helper until proper
> support is added.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Is that how it goes until we'll add the proper infrastructure?
Am I expected to provide the same for qede?
I was under the impression that so long as this is being [early] developed
and there's no way to communicate what is and isn't supported by
a given implementation, it would simply be the user's responsibility
to make sure what he's trying is supported.
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Giuseppe CAVALLARO @ 2016-12-19 15:36 UTC (permalink / raw)
To: Pavel Machek, LinoSanfilippo, alexandre.torgue, davem,
linux-kernel, netdev, niklas.cassel, Joao.Pinto
In-Reply-To: <20161218203812.GA1012@amd>
On 12/18/2016 9:38 PM, Pavel Machek wrote:
>
> Fix up memory barriers in stmmac driver. They are meant to protect
> against DMA engine, so smp_ variants are certainly wrong, and dma_
> variants are preferable.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index a340fc8..8816515 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -334,7 +334,7 @@ static void dwmac4_rd_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> @@ -377,7 +377,7 @@ static void dwmac4_rd_prepare_tso_tx_desc(struct dma_desc *p, int is_fs,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des3 = cpu_to_le32(tdes3);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> index ce97e52..f0d8632 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> @@ -350,7 +350,7 @@ static void enh_desc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
> * descriptors for the same frame has to be set before, to
> * avoid race condition.
> */
> - wmb();
> + dma_wmb();
>
> p->des0 = cpu_to_le32(tdes0);
> }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..bb40382 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2125,7 +2125,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
>
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> @@ -2338,7 +2338,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + dma_wmb();
> }
>
> netdev_sent_queue(dev, skb->len);
> @@ -2443,14 +2443,14 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv)
> netif_dbg(priv, rx_status, priv->dev,
> "refill entry #%d\n", entry);
> }
> - wmb();
> + dma_wmb();
>
> if (unlikely(priv->synopsys_id >= DWMAC_CORE_4_00))
> priv->hw->desc->init_rx_desc(p, priv->use_riwt, 0, 0);
> else
> priv->hw->desc->set_rx_owner(p);
>
> - wmb();
> + dma_wmb();
>
> entry = STMMAC_GET_ENTRY(entry, DMA_RX_SIZE);
> }
>
^ permalink raw reply
* Re: [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]
From: David Miller @ 2016-12-19 15:37 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel, scott.wood, mpe
In-Reply-To: <1482139343-8975-3-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Mon, 19 Dec 2016 11:22:20 +0200
> The fsl/fman drivers will use of_platform_populate() on all
> supported platforms.
>
> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
It seems that this creates a failure point between patches #2 and
#3. If the cases handled by this "fsl,fman" entry are only afterwards
covered by the of_platform_populate() code added in patch #3 then you
cannot split these two changes up like this.
The two changes must be done at the same time, otherwise probing will
fail for some people between patches #2 and #3.
^ permalink raw reply
* Re: [PATCH net] virtio_net: reject XDP programs using header adjustment
From: Jakub Kicinski @ 2016-12-19 15:42 UTC (permalink / raw)
To: Mintz, Yuval
Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, kafai@fb.com,
daniel@iogearbox.net, alexei.starovoitov@gmail.com,
mst@redhat.com
In-Reply-To: <BL2PR07MB2306FB78FBB5F2D17681699D8D910@BL2PR07MB2306.namprd07.prod.outlook.com>
On Mon, Dec 19, 2016 at 3:23 PM, Mintz, Yuval <Yuval.Mintz@cavium.com> wrote:
>> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
>> added a new XDP helper to prepend and remove data from a frame.
>> Make virtio_net reject programs making use of this helper until proper
>> support is added.
>>
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> Is that how it goes until we'll add the proper infrastructure?
> Am I expected to provide the same for qede?
I asked Martin to fix the existing drivers like qede but virtio's XDP
was not merged at that point.
> I was under the impression that so long as this is being [early] developed
> and there's no way to communicate what is and isn't supported by
> a given implementation, it would simply be the user's responsibility
> to make sure what he's trying is supported.
IMHO the less user has to guess the better if we're hoping for wide adoption.
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Rob Herring @ 2016-12-19 16:04 UTC (permalink / raw)
To: Dongpo Li
Cc: David Miller, Mark Rutland, Michael Turquette, Stephen Boyd,
Russell King, Zhangfei Gao, Yisen Zhuang, salil.mehta,
Arnd Bergmann, Andrew Lunn, Jiancheng Xue, benjamin.chenhao,
caizhiyong, netdev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <585796D6.1080407@hisilicon.com>
On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
> Hi Rob and David,
>
> On 2016/12/12 22:21, Rob Herring wrote:
>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>>> Hi Rob,
>>>
>>> On 2016/12/10 6:35, Rob Herring wrote:
>>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
[...]
>>>>> @@ -20,7 +25,7 @@ Required properties:
>>>>>
>>>>> Example:
>>>>> gmac0: ethernet@f9840000 {
>>>>> - compatible = "hisilicon,hix5hd2-gmac";
>>>>> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>>>
>>>> You can't just change compatible strings.
>>>>
>>> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
>>> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
>>> Can I just add the generic compatible string without changing the SoCs compatible string?
>>> Like following:
>>> gmac0: ethernet@f9840000 {
>>> - compatible = "hisilicon,hix5hd2-gmac";
>>> + compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>>
>> Yes, this is fine.
>
> As the patch series have been applied to net-next branch,
> in which way should I commit this compatible fix?
> Should I send a new patch fixing this compatible string error with "Fixes: xxx"?
> Looking forward to your reply!
Yes to both.
Rob
^ permalink raw reply
* Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap
From: David Miller @ 2016-12-19 16:04 UTC (permalink / raw)
To: arvind.yadav.cs
Cc: peter.chen, fw, david.daney, f.fainelli, netdev, linux-kernel
In-Reply-To: <1481742210-5609-1-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Thu, 15 Dec 2016 00:33:30 +0530
> Here, If devm_ioremap will fail. It will return NULL.
> Kernel can run into a NULL-pointer dereference.
> This error check will avoid NULL pointer dereference.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Since ioremap() is in fact designed to possibly fail, we do
need to always check it's return value. So this change is
correct and I have applied it to the 'net' tree.
Thanks.
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Niklas Cassel @ 2016-12-19 16:05 UTC (permalink / raw)
To: Joao Pinto, Lars Persson
Cc: Florian Fainelli, Andy Shevchenko, David Miller,
Giuseppe CAVALLARO, Rabin Vincent, netdev,
CARLOS.PALMINHA@synopsys.com, Jie.Deng1@synopsys.com,
Stephen Warren, pavel@ucw.cz
In-Reply-To: <c6eb5745-20b3-daac-33b4-b20c568344b8@synopsys.com>
On 12/13/2016 01:56 PM, Joao Pinto wrote:
> Às 12:50 PM de 12/13/2016, Lars Persson escreveu:
>>> 13 dec. 2016 kl. 13:31 skrev Niklas Cassel <Niklas.Cassel@axis.com>:
>>>
>>>
>>>
>>>> On 12/13/2016 12:49 PM, Joao Pinto wrote:
>>>> Hi Niklas,
>>>>
>>>> Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
>>>>>> On 12/12/2016 11:19 AM, Joao Pinto wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
>>>>>>>> Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
>>>>>>>> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> (snip...)
>>>>
>>>>
>>>>>> @Rabin Vincent: Hi Rabin. Since Axis is more familiar with the synopsys/*qos*
>>>>>> driver would it be possible for you to make an initial analysis of what has to
>>>>>> be merged into Stmmac? This way the development would speed-up.
>>>>> I can answer that question.
>>>>>
>>>>> I've sent out 12 patches to the stmmac driver
>>>>> (all patches are included in the current net-next tree),
>>>>> with these patches the stmmac driver works properly on Axis hardware
>>>>> (we use Synopsys GMAC 4.10a synthesized with multiple TX queues).
>>>>> stmmac's DT binding has also been extended with properties that
>>>>> existed in DWC EQoS's DT binding, such as no-pbl-x8, txpbl, rxpbl.
>>>>>
>>>>> Since we have no problem updating the DTB together with the kernel,
>>>>> we will simply move to using the start using the stmmac driver,
>>>>> with stmmac's DT binding.
>>>>>
>>>>> However, I've noticed that NVIDIA has extended the DWC EQoS DT binding,
>>>>> I don't how easy it would be for them to switch to stmmac's DT binding.
>>>>> (Adding Stephen Warren to CC.)
>>>>>
>>>>> The reset sequence that Lars Persson was worried about is not an issue
>>>>> with the stmmac driver.
>>>> Great! So you saying that stmmac works great with AXIS hardware and no need to
>>>> merge specific code from AXIS' *qos* driver?
>>> Yes. From Axis point of view, we are done.
>>> stmmac works and we will move to that driver + DT binding.
>>>
>>> However, it seems like Stephen Warren will NAK if you try to remove
>>> synopsys/dwc_eth_qos.c before
>>> Documentation/devicetree/bindings/net/stmmac.txt
>>> is compatible with
>>> Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
>>>
>>> You might want to sync with him. I have no idea, but perhaps they are
>>> only using a subset of all the available properties. Perhaps,
>>> only implementing what they are using might be enough, I don't know.
>>> I couldn't find their DTS in arch/arm/dts.
>>> I guess you might want to know David Miller's opinion,
>>> since he's the one who decides in the end.
>> I will also NACK removal of dwc_eth_qos.c until the binding is implemented elsewhere.
> Totally agree.
> @Niklas: David Miller is informed of what we are planning to do. Can you
> estimate the effort of merging the axis driver device tree bindings? If there
> was anyone from axis to do the merge would be better since you are familiar with
> it. What do you think?
Since stmmac supports glue layers, the best thing is probably
to create a new glue layer
(see for example drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
with matching Documentation/devicetree/bindings/net/meson-dwmac.txt).
That way we don't have to "contaminate" the generic code in
stmmac_platform.c and dwmac-generic.c.
The only code needed in the glue driver would be the code to parse the
devicetree properties specific to dwc_eth_qos.c.
Hence, the amount of code you will have to write will be very limited.
Writing the code will probably be quick, but since you will have to
fix review comments etc., I would estimate it to be around 1-2 days work.
Since we have already moved to stmmac's DT binding,
we don't really care about the old binding, but I will gladly
help you by performing code reviews if you would like.
>
>>
>>>>>
>>>>>
>>>>> There are some performance problems with the stmmac driver though:
>>>>>
>>>>> When running iperf3 with 3 streams:
>>>>> iperf3 -c 192.168.0.90 -P 3 -t 30
>>>>> iperf3 -c 192.168.0.90 -P 3 -t 30 -R
>>>>>
>>>>> I get really bad fairness between the streams.
>>>>>
>>>>> This appears to be an issue with how TX IRQ coalescing is implemented in stmmac.
>>>>> Disabling TX IRQ coalescing in the stmmac driver makes the problem go away.
>>>>> We have a local patch that implements TX IRQ coalescing in the dwceqos driver,
>>>>> and we don't see the same problem.
>>>>>
>>>>> Also netperf TCP_RR and UDP_RR gives really bad results compared to the
>>>>> dwceqos driver (without IRQ coalescing).
>>>>> 2000 transactions/sec vs 9000 transactions/sec.
>>>>> Turning TX IRQ coalescing off and RX interrupt watchdog off in stmmac
>>>>> gives the same performance. I guess it's a trade off, low CPU usage
>>>>> vs low latency, so I don't know how important TCP_RR/UDP_RR really is.
>>>>>
>>>>> The best thing would be to get a good working TX IRQ coalesce
>>>>> implementation with HR timers in stmmac.
>>>>> Perhaps it should also be investigated if the RX interrupt watchdog
>>>>> timeout should have a lower default value.
>>>>>
>>>>>
>>>>>
>>>>>> Thanks to all.
>>>>>>
>>>>>> Joao
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: David Miller @ 2016-12-19 16:06 UTC (permalink / raw)
To: pavel
Cc: LinoSanfilippo, peppe.cavallaro, alexandre.torgue, linux-kernel,
netdev, niklas.cassel, Joao.Pinto
In-Reply-To: <20161218203812.GA1012@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Sun, 18 Dec 2016 21:38:12 +0100
> Fix up memory barriers in stmmac driver. They are meant to protect
> against DMA engine, so smp_ variants are certainly wrong, and dma_
> variants are preferable.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
Applied.
^ permalink raw reply
* RE: [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]
From: Madalin-Cristian Bucur @ 2016-12-19 16:07 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Scott Wood
In-Reply-To: <20161219.103712.1578523196484939315.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, December 19, 2016 5:37 PM
>
> From: Madalin Bucur <madalin.bucur@nxp.com>
> Date: Mon, 19 Dec 2016 11:22:20 +0200
>
> > The fsl/fman drivers will use of_platform_populate() on all
> > supported platforms.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
>
> It seems that this creates a failure point between patches #2 and
> #3. If the cases handled by this "fsl,fman" entry are only afterwards
> covered by the of_platform_populate() code added in patch #3 then you
> cannot split these two changes up like this.
>
> The two changes must be done at the same time, otherwise probing will
> fail for some people between patches #2 and #3.
You are right, that will happen. I was not convinced these need to be
merged due to the different places they touch. I'll send a v3.
^ permalink raw reply
* Re: [PATCH net v2] ipvlan: fix crash when master is set in loopback mode
From: David Miller @ 2016-12-19 16:11 UTC (permalink / raw)
To: mahesh; +Cc: netdev, edumazet, maheshb
In-Reply-To: <1482087625-30366-1-git-send-email-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Sun, 18 Dec 2016 11:00:25 -0800
> From: Mahesh Bandewar <maheshb@google.com>
>
> In an IPvlan setup when master is set in loopback mode e.g.
>
> ethtool -K eth0 set loopback on
>
> where eth0 is master device for IPvlan setup.
>
> The failure actually happens while processing mulitcast packets
> but that's a result of unconditionally queueing packets without
> ensuring ether-header is part of the linear part of skb.
>
> This patch forces this check at the reception and drops packets
> which fail this check before queuing them.
...
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> v1->v2: commit log update
Like Eric, I still do not like this change nor the explanation.
Whether in loopback mode or not, your explanation makes no sense at
all.
If the packet comes from the ethernet device, the freakin' ethernet
header is there in the linear SKB area. No pulling should be needed
whatsoever.
Something creates this bad situation where the ethernet header is not
there, but you have not explained that sufficiently yet.
Thank you.
^ permalink raw reply
* [PATCH net v3 0/4] fsl/fman: fixes for ARM
From: Madalin Bucur @ 2016-12-19 16:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
The patch set fixes advertised speeds for QSGMII interfaces, disables
A007273 erratum workaround on non-PowerPC platforms where it does not
apply, enables compilation on ARM64 and addresses a probing issue on
non PPC platforms.
Changes from v2: merged fsl/fman changes to avoid a point of failure
Changes from v1: unifying probing on all supported platforms
Madalin Bucur (4):
fsl/fman: fix 1G support for QSGMII interfaces
powerpc: fsl/fman: remove fsl,fman from of_device_ids[]
fsl/fman: A007273 only applies to PPC SoCs
fsl/fman: enable compilation on ARM64
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
drivers/net/ethernet/freescale/fman/fman.c | 16 ++++++++++++++++
drivers/net/ethernet/freescale/fman/mac.c | 1 +
4 files changed, 18 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net v3 1/4] fsl/fman: fix 1G support for QSGMII interfaces
From: Madalin Bucur @ 2016-12-19 16:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482164013-6111-1-git-send-email-madalin.bucur@nxp.com>
QSGMII ports were not advertising 1G speed.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 69ca42c..0b31f85 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -594,6 +594,7 @@ static const u16 phy2speed[] = {
[PHY_INTERFACE_MODE_RGMII_RXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RGMII_TXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RTBI] = SPEED_1000,
+ [PHY_INTERFACE_MODE_QSGMII] = SPEED_1000,
[PHY_INTERFACE_MODE_XGMII] = SPEED_10000
};
--
2.1.0
^ permalink raw reply related
* [PATCH net v3 2/4] powerpc: fsl/fman: remove fsl,fman from of_device_ids[]
From: Madalin Bucur @ 2016-12-19 16:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482164013-6111-1-git-send-email-madalin.bucur@nxp.com>
The fsl/fman drivers will use of_platform_populate() on all
supported platforms. Call of_platform_populate() to probe the
FMan sub-nodes.
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1179115..824b7f1 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -117,9 +117,6 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qe",
},
- {
- .compatible = "fsl,fman",
- },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index dafd9e1..0b7f711 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2868,6 +2868,14 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
fman->dev = &of_dev->dev;
+ /* call of_platform_populate in order to probe sub-nodes on arm64 */
+ err = of_platform_populate(fm_node, NULL, NULL, &of_dev->dev);
+ if (err) {
+ dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
+ __func__);
+ goto fman_free;
+ }
+
return fman;
fman_node_put:
--
2.1.0
^ permalink raw reply related
* [PATCH net v3 4/4] fsl/fman: enable compilation on ARM64
From: Madalin Bucur @ 2016-12-19 16:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482164013-6111-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig
index 79b7c84..dc0850b 100644
--- a/drivers/net/ethernet/freescale/fman/Kconfig
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -1,6 +1,6 @@
config FSL_FMAN
tristate "FMan support"
- depends on FSL_SOC || COMPILE_TEST
+ depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
select GENERIC_ALLOCATOR
select PHYLIB
default n
--
2.1.0
^ permalink raw reply related
* [PATCH net v3 3/4] fsl/fman: A007273 only applies to PPC SoCs
From: Madalin Bucur @ 2016-12-19 16:13 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482164013-6111-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 0b7f711..003b86d 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -1890,6 +1890,7 @@ static int fman_reset(struct fman *fman)
goto _return;
} else {
+#ifdef CONFIG_PPC
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1921,6 +1922,7 @@ static int fman_reset(struct fman *fman)
/* Enable all MACs */
iowrite32be(reg, &guts_regs->devdisr2);
+#endif
/* Perform FMan reset */
iowrite32be(FPM_RSTC_FM_RESET, &fman->fpm_regs->fm_rstc);
@@ -1932,25 +1934,31 @@ static int fman_reset(struct fman *fman)
} while (((ioread32be(&fman->fpm_regs->fm_rstc)) &
FPM_RSTC_FM_RESET) && --count);
if (count == 0) {
+#ifdef CONFIG_PPC
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
err = -EBUSY;
goto _return;
}
+#ifdef CONFIG_PPC
/* Restore devdisr2 value */
iowrite32be(devdisr2, &guts_regs->devdisr2);
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
goto _return;
+#ifdef CONFIG_PPC
guts_regs:
of_node_put(guts_node);
guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
+#endif
}
_return:
return err;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff
From: Eric Dumazet @ 2016-12-19 16:17 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev, linux-sctp, YueHaibing
In-Reply-To: <1482094596-26046-3-git-send-email-ja@ssi.bg>
On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote:
>
> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour *n)
> +{
> + if (unlikely(skb->dst_pending_confirm)) {
> + struct sock *sk = skb->sk;
> + unsigned long now = jiffies;
> +
> + /* avoid dirtying neighbour */
> + if (n->confirmed != now)
> + n->confirmed = now;
> + if (sk && sk->sk_dst_pending_confirm)
> + sk->sk_dst_pending_confirm = 0;
> + }
> +}
> +
I am still digesting this awesome patch series ;)
Not sure why you used an unlikely() here. TCP for example would hit this
path quite often.
So considering sk_dst_pending_confirm might be dirtied quite often,
I am not sure why you placed it in the cache line that contains
sk_rx_dst (in 1st patch)
Thanks.
^ permalink raw reply
* Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff
From: Hannes Frederic Sowa @ 2016-12-19 16:36 UTC (permalink / raw)
To: Eric Dumazet, Julian Anastasov; +Cc: netdev, linux-sctp, YueHaibing
In-Reply-To: <1482164252.1521.7.camel@edumazet-glaptop3.roam.corp.google.com>
On 19.12.2016 17:17, Eric Dumazet wrote:
> On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote:
>
>>
>> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour *n)
>> +{
>> + if (unlikely(skb->dst_pending_confirm)) {
>> + struct sock *sk = skb->sk;
>> + unsigned long now = jiffies;
>> +
>> + /* avoid dirtying neighbour */
>> + if (n->confirmed != now)
>> + n->confirmed = now;
>> + if (sk && sk->sk_dst_pending_confirm)
>> + sk->sk_dst_pending_confirm = 0;
>> + }
>> +}
>> +
>
> I am still digesting this awesome patch series ;)
>
> Not sure why you used an unlikely() here. TCP for example would hit this
> path quite often.
>
> So considering sk_dst_pending_confirm might be dirtied quite often,
>
> I am not sure why you placed it in the cache line that contains
> sk_rx_dst (in 1st patch)
Because they have to stay synchronized?
If we modify sk_rx_dst, we automatically also must clear
pending_confirm, otherwise we might end up confirming a wrong neighbor.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet
From: Niklas Söderlund @ 2016-12-19 16:39 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Simon Horman, netdev, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <87e3f9e6-0f5a-986c-772d-006cb25b9fd9@cogentembedded.com>
Hi Sergei,
Thanks for the spelling feedback, will include your suggestions in v3.
Which I hope to post once rc1 is released and netdev opens, as you
suggested to me previously.
On 2016-12-18 23:26:11 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 12/12/2016 07:09 PM, Niklas Söderlund wrote:
>
> > Add generic functionality to support Wake-on-Lan using MagicPacket which
> > are supported by at least a few versions of sh_eth. Only add
> > functionality for WoL, no specific sh_eth version are marked to support
>
> Versions.
>
> > WoL yet.
> >
> > WoL is enabled in the suspend callback by setting MagicPacket detection
> > and disabling all interrupts expect MagicPacket. In the resume path the
> > driver needs to reset the hardware to rearm the WoL logic, this prevents
> > the driver from simply restoring the registers and to take advantage of
> > that sh_eth was not suspended to reduce resume time. To reset the
> > hardware the driver close and reopens the device just like it would do
>
> Closes.
>
> > in a normal suspend/resume scenario without WoL enabled, but it both
> > close and open the device in the resume callback since the device needs
>
> Closes and opens.
>
> > to be open for WoL to work.
>
> > One quirk needed for WoL is that the module clock needs to be prevented
> > from being switched off by Runtime PM. To keep the clock alive the
>
> I tried to find the code in question and failed, getting muddled in the
> RPM maze. Could you point at this code for my education? :-)
In my investigation I observed this (simplified) call graph with regards
to clocks for suspend:
pm_suspend
pm_clk_suspend
clk_disable
clk_core_disable
cpg_mstp_clock_disable
The interesting function here are clk_core_disable(). In that function a
'enable_count' for each clock is decremented and the clock is only
turned of if the count reaches zero, hence cpg_mstp_clock_disable() are
only called if the counter reaches 0. At runtime the enable_count can be
displayed by examining /sys/kernel/debug/clk/clk_summary.
However the value for enable_count show at runtime are not the values
which are used when the pm_clk_suspend() are called. For a clock to not
be switched off when suspending the enable_count needs to incremented,
which a few drivers do if they can be used as a wake-up source.
>
> > suspend callback need to call clk_enable() directly to increase the
>
> My main concern is why we need to manipulate the clock directly --
> can't you call RPM to achieve the same effect?
In my early attempts to keep the clock alive when suspending I used
pm_clk_resume()/pm_clk_suspend() to increment/decrement the clock usage
count. pm_clk_resume()/pm_clk_suspend() calls clk_enable()/clk_disable()
for all clocks in the device's PM clock list, among other things.
Geert pointed out to me that this might have side effects and to manages
its clock directly is preferred. Looking how these functions are used at
other places I can only agree with Geert that this feels like the wrong
solution and a layer violation.
>
> > usage count of the clock. Then when Runtime PM decreases the clock usage
> > count it won't reach 0 and be switched off.
>
> You mean it does this even though we don't call pr_runtime_put_sync()
> as done in sh_eth_close()?
Yes.
I had a look at the pm_runtime_* functions in include/linux/pm_runtime.h
and drivers/base/power/runtime.c and could not find any clock handling.
Maybe they only deal with power domains?
I might have missed something when looking in to this. But if I do not
call clk_enable()/clk_disable() (or something equivalent) in the sh_eth
suspend/resume callbacks WoL do not work. That is it suspends fine but
sending a MagicPacket do not wake the system :-)
>
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> [...]
>
> MBR, Sergei
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff
From: Eric Dumazet @ 2016-12-19 16:40 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Julian Anastasov, netdev, linux-sctp, YueHaibing
In-Reply-To: <f9dadb5e-172a-4c39-c564-38be672ef0eb@stressinduktion.org>
On Mon, 2016-12-19 at 17:36 +0100, Hannes Frederic Sowa wrote:
> On 19.12.2016 17:17, Eric Dumazet wrote:
> > On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote:
> >
> >>
> >> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour *n)
> >> +{
> >> + if (unlikely(skb->dst_pending_confirm)) {
> >> + struct sock *sk = skb->sk;
> >> + unsigned long now = jiffies;
> >> +
> >> + /* avoid dirtying neighbour */
> >> + if (n->confirmed != now)
> >> + n->confirmed = now;
> >> + if (sk && sk->sk_dst_pending_confirm)
> >> + sk->sk_dst_pending_confirm = 0;
> >> + }
> >> +}
> >> +
> >
> > I am still digesting this awesome patch series ;)
> >
> > Not sure why you used an unlikely() here. TCP for example would hit this
> > path quite often.
> >
> > So considering sk_dst_pending_confirm might be dirtied quite often,
> >
> > I am not sure why you placed it in the cache line that contains
> > sk_rx_dst (in 1st patch)
>
> Because they have to stay synchronized?
>
> If we modify sk_rx_dst, we automatically also must clear
> pending_confirm, otherwise we might end up confirming a wrong neighbor.
Your answer makes little sense really...
For most TCP flows, we set sk_rx_dst exactly once.
Hardly a good reason to have these in the same cache line.
^ 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