* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Stephen Hemminger @ 2017-11-30 17:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Solio Sarabia, David Ahern, davem, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <1512062799.19682.19.camel@gmail.com>
On Thu, 30 Nov 2017 09:26:39 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> >
> >
> > The problem goes back into the core GSO networking code.
> > Something like this is needed.
> >
> > static inline bool netif_needs_gso(struct sk_buff *skb,
> > const struct net_device *dev,
> > netdev_features_t features)
> > {
> > return skb_is_gso(skb) &&
> > (!skb_gso_ok(skb, features) ||
> > unlikely(skb_shinfo(skb)->gso_segs > dev-
> > >gso_max_segs) || << new
> > unlikely(skb_shinfo(skb)->gso_size > dev-
> > >gso_max_size) || << new
> > unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> > (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> > }
> >
> > What that will do is split up the monster GSO packets if they ever
> > bleed
> > across from one device to another through the twisty mazes of packet
> > processing paths.
>
>
> Since very few drivers have these gso_max_segs / gso_max_size, check
> could be done in their ndo_features_check()
Agreed, we could do it there.
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: Ard Biesheuvel @ 2017-11-30 17:37 UTC (permalink / raw)
To: David Miller, Dan Williams, Will Deacon
Cc: Jassi Brar, <netdev@vger.kernel.org>,
devicetree@vger.kernel.org, Arnd Bergmann, Rob Herring,
Mark Rutland, Jaswinder Singh
In-Reply-To: <20171130.122917.542712364953497229.davem@davemloft.net>
(+ Dan, Will)
On 30 November 2017 at 17:29, David Miller <davem@davemloft.net> wrote:
> From: jassisinghbrar@gmail.com
> Date: Thu, 30 Nov 2017 21:43:16 +0530
>
>> + priv->eeprom_base = devm_memremap(&pdev->dev, eeprom_res->start,
>> + resource_size(eeprom_res),
>> + MEMREMAP_WT);
>> + if (!priv->eeprom_base) {
>> + dev_err(&pdev->dev, "devm_memremap() failed for EEPROM\n");
>> + ret = -ENXIO;
>> + goto free_ndev;
>> + }
>
> dev_memremap() is implemented via memremap() which for MEMREMAP_WT is
> in turn implemented using ioremap_wt() which returns an "__iomem"
> pointer.
>
> The memremap() function talks about __iomem being about side effects.
> That's not really the full story. The __iomem annotation is also
> about whether a special accessor is necessary to "dereference" the
> pointer. On sparc64, for example, the ioremap_*() functions return a
> physical address not a virtual one. So you cannot directly
> dereference pointers that are returned from the ioremap*() interfaces.
>
> You'll also need to mark priv->eeprom_base as "__iomem".
>
> devm_memremap() returns a straight "void *" without the __iomem
> annotation, and this is wrong then ioremap_*() is used.
Well, the whole point of using memremap() instead of ioremap() is that
the region has memory semantics, i.e., we read the MAC address and the
DMA engine microcode from it. If memremap() itself is flawed in this
regard, I agree we should fix it. But as I understand it, this is
really an implementation problem in memremap() [the fact that it falls
back to ioremap()] and not a problem in this driver.
So what alternative would you propose in this case?
BTW, this should be IOREMAP_WC not IOREMAP_WT, because the EEPROM on
the platform in question does not tolerate cached mappings (or rather,
shareable mappings). ioremap_wt() happens to result in device mappings
rather than writethrough cacheable mappings, but this is another
problem in itself. Once arm64 fixes ioremap_wt(), this code will no
longer work on the SynQuacer SoC.
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: David Miller @ 2017-11-30 17:38 UTC (permalink / raw)
To: eric.dumazet
Cc: stephen, solio.sarabia, dsahern, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <1512062799.19682.19.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 30 Nov 2017 09:26:39 -0800
> On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
>>
>>
>> The problem goes back into the core GSO networking code.
>> Something like this is needed.
>>
>> static inline bool netif_needs_gso(struct sk_buff *skb,
>> const struct net_device *dev,
>> netdev_features_t features)
>> {
>> return skb_is_gso(skb) &&
>> (!skb_gso_ok(skb, features) ||
>> unlikely(skb_shinfo(skb)->gso_segs > dev-
>> >gso_max_segs) || << new
>> unlikely(skb_shinfo(skb)->gso_size > dev-
>> >gso_max_size) || << new
>> unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
>> (skb->ip_summed != CHECKSUM_UNNECESSARY)));
>> }
>>
>> What that will do is split up the monster GSO packets if they ever
>> bleed
>> across from one device to another through the twisty mazes of packet
>> processing paths.
>
>
> Since very few drivers have these gso_max_segs / gso_max_size, check
> could be done in their ndo_features_check()
Agreed.
^ permalink raw reply
* Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Andrew Lunn @ 2017-11-30 17:41 UTC (permalink / raw)
To: Bhaskar Upadhaya
Cc: netdev@vger.kernel.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM3PR04MB4494050122E413E2445BD348C380@AM3PR04MB449.eurprd04.prod.outlook.com>
> [bhaskar] 2.5G in general needs to operate with auto negotiation in
> disabled mode. Its 2.5G requirement and not specific to our system.
> My understanding is that one of the main differences between SGMII and 1000BASE-X is the negotiation.
> [Bhaskar] which of SGMII and 1000BASE-X support negotiation ?
SGMII supports passing auto-negotiation results from the PHY to the
MAC. 1000BASE-X does not.
SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
support this, the MAC needs to replicate the bits 100, or 10 times
when the PHY is running in 10 or 100Mbps mode.
So with your 2.5G SGMII, you need to replicate the bits 250, 25, or
2.5 times if they PHY is running at lower speeds. This last one is
interesting.
Andrew
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: David Miller @ 2017-11-30 17:42 UTC (permalink / raw)
To: ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A
Cc: dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, will.deacon-5wv7dgnIgG8,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <CAKv+Gu8wJkNWufXsRYGe0juLWt9GRfRj=tg3M+on2wtwaj+6EA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Thu, 30 Nov 2017 17:37:27 +0000
> Well, the whole point of using memremap() instead of ioremap() is that
> the region has memory semantics, i.e., we read the MAC address and the
> DMA engine microcode from it. If memremap() itself is flawed in this
> regard, I agree we should fix it. But as I understand it, this is
> really an implementation problem in memremap() [the fact that it falls
> back to ioremap()] and not a problem in this driver.
>
> So what alternative would you propose in this case?
>
> BTW, this should be IOREMAP_WC not IOREMAP_WT, because the EEPROM on
> the platform in question does not tolerate cached mappings (or rather,
> shareable mappings). ioremap_wt() happens to result in device mappings
> rather than writethrough cacheable mappings, but this is another
> problem in itself. Once arm64 fixes ioremap_wt(), this code will no
> longer work on the SynQuacer SoC.
It doesn't "fall back", it directly uses ioremap_wt() for non-RAM
mappings.
It you look, most architectures do a "#define iomrep_wt ioremap"
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: Ard Biesheuvel @ 2017-11-30 17:48 UTC (permalink / raw)
To: David Miller
Cc: Williams, Dan J, Will Deacon, Jassi Brar,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Rob Herring, Mark Rutland, Jaswinder Singh
In-Reply-To: <20171130.124234.1467691580228393484.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 30 November 2017 at 17:42, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date: Thu, 30 Nov 2017 17:37:27 +0000
>
>> Well, the whole point of using memremap() instead of ioremap() is that
>> the region has memory semantics, i.e., we read the MAC address and the
>> DMA engine microcode from it. If memremap() itself is flawed in this
>> regard, I agree we should fix it. But as I understand it, this is
>> really an implementation problem in memremap() [the fact that it falls
>> back to ioremap()] and not a problem in this driver.
>>
>> So what alternative would you propose in this case?
>>
>> BTW, this should be IOREMAP_WC not IOREMAP_WT, because the EEPROM on
>> the platform in question does not tolerate cached mappings (or rather,
>> shareable mappings). ioremap_wt() happens to result in device mappings
>> rather than writethrough cacheable mappings, but this is another
>> problem in itself. Once arm64 fixes ioremap_wt(), this code will no
>> longer work on the SynQuacer SoC.
>
> It doesn't "fall back", it directly uses ioremap_wt() for non-RAM
> mappings.
>
> It you look, most architectures do a "#define iomrep_wt ioremap"
OK, but that still means the implementation of memremap() is flawed,
not its use in this driver.
memremap() exists to allow non-DRAM regions to be mapped with memory
semantics, and if we currently implement that incorrectly, we should
fix it. But that still does not mean we should have __iomem
annotations and special accessors in this case, precisely because it
has memory semantics, and so it is a virtual pointer that may be
dereferenced normally.
So if memremap() is unsuitable, how should we map memory that is not DRAM?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Stephen Hemminger @ 2017-11-30 17:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Solio Sarabia, David Ahern, davem, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <1512062799.19682.19.camel@gmail.com>
On Thu, 30 Nov 2017 09:26:39 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> >
> >
> > The problem goes back into the core GSO networking code.
> > Something like this is needed.
> >
> > static inline bool netif_needs_gso(struct sk_buff *skb,
> > const struct net_device *dev,
> > netdev_features_t features)
> > {
> > return skb_is_gso(skb) &&
> > (!skb_gso_ok(skb, features) ||
> > unlikely(skb_shinfo(skb)->gso_segs > dev-
> > >gso_max_segs) || << new
> > unlikely(skb_shinfo(skb)->gso_size > dev-
> > >gso_max_size) || << new
> > unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> > (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> > }
> >
> > What that will do is split up the monster GSO packets if they ever
> > bleed
> > across from one device to another through the twisty mazes of packet
> > processing paths.
>
>
> Since very few drivers have these gso_max_segs / gso_max_size, check
> could be done in their ndo_features_check()
Actually, we already check for max_segs, just missing check for size here:
From 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <sthemmin@microsoft.com>
Date: Thu, 30 Nov 2017 09:45:11 -0800
Subject: [PATCH] net: do not GSO if frame is too large
This adds an additional check to breakup skb's that exceed a devices
GSO maximum size. The code was already checking for too many segments
but did not check size.
This has been observed to be a problem when using containers on
Hyper-V/Azure where the allowed GSO maximum size is less than
maximum and skb's have gone through multiple layers to arrive
at the virtual device.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
net/core/dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 07ed21d64f92..0bb398f3bfa3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2918,9 +2918,11 @@ static netdev_features_t gso_features_check(const struct sk_buff *skb,
struct net_device *dev,
netdev_features_t features)
{
+ unsigned int gso_size = skb_shinfo(skb)->gso_size;
u16 gso_segs = skb_shinfo(skb)->gso_segs;
- if (gso_segs > dev->gso_max_segs)
+ if (gso_segs > dev->gso_max_segs ||
+ gso_size > dev->gso_max_size)
return features & ~NETIF_F_GSO_MASK;
/* Support for GSO partial features requires software
--
2.11.0
^ permalink raw reply related
* [PATCH net-next] net: dsa: bcm_sf2: Utilize b53_get_tag_protocol()
From: Florian Fainelli @ 2017-11-30 17:55 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, open list
Utilize the much more capable b53_get_tag_protocol() which takes care of
all Broadcom switches specifics to resolve which port can have Broadcom
tags enabled or not.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 4 ++--
drivers/net/dsa/b53/b53_priv.h | 1 +
drivers/net/dsa/bcm_sf2.c | 8 +-------
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index f5a8dd96fd75..7f26f5dafca7 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1495,8 +1495,7 @@ static bool b53_can_enable_brcm_tags(struct dsa_switch *ds, int port)
return false;
}
-static enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds,
- int port)
+enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds, int port)
{
struct b53_device *dev = ds->priv;
@@ -1514,6 +1513,7 @@ static enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds,
return DSA_TAG_PROTO_BRCM;
}
+EXPORT_SYMBOL(b53_get_tag_protocol);
int b53_mirror_add(struct dsa_switch *ds, int port,
struct dsa_mall_mirror_tc_entry *mirror, bool ingress)
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index daaaa1ecb996..2af0155efce2 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -310,6 +310,7 @@ int b53_fdb_dump(struct dsa_switch *ds, int port,
dsa_fdb_dump_cb_t *cb, void *data);
int b53_mirror_add(struct dsa_switch *ds, int port,
struct dsa_mall_mirror_tc_entry *mirror, bool ingress);
+enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds, int port);
void b53_mirror_del(struct dsa_switch *ds, int port,
struct dsa_mall_mirror_tc_entry *mirror);
int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ea01f24f15e7..a640b220b19b 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -35,12 +35,6 @@
#include "b53/b53_priv.h"
#include "b53/b53_regs.h"
-static enum dsa_tag_protocol bcm_sf2_sw_get_tag_protocol(struct dsa_switch *ds,
- int port)
-{
- return DSA_TAG_PROTO_BRCM;
-}
-
static void bcm_sf2_imp_setup(struct dsa_switch *ds, int port)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
@@ -861,7 +855,7 @@ static const struct b53_io_ops bcm_sf2_io_ops = {
};
static const struct dsa_switch_ops bcm_sf2_ops = {
- .get_tag_protocol = bcm_sf2_sw_get_tag_protocol,
+ .get_tag_protocol = b53_get_tag_protocol,
.setup = bcm_sf2_sw_setup,
.get_strings = b53_get_strings,
.get_ethtool_stats = b53_get_ethtool_stats,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 0/2] net: dsa: cross-chip FDB support
From: Vivien Didelot @ 2017-11-30 17:56 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
DSA can have interconnected switches. For instance, the ZII Dev Rev B
board described in arch/arm/boot/dts/vf610-zii-dev-rev-b.dts has a
switch fabric composed of 3 switch devices like this:
lan4 lan6
CPU (eth1) | lan5 | lan7
| | | | |
[0 1 2 3 4 6 5]---[6 0 1 2 3 4 5]---[9 0 1 2 3 4 5 6 7 8]
| | | | | | |
lan0 | lan2 lan3 lan8 | optical4
lan1 optical3
One current issue with DSA is cross-chip FDB. If we add a static MAC
address on lan3, only its parent switch 1 (the one in the middle) will
be programmed. That is not correct in a cross-chip environment, because
the DSA ports connecting to switch 1 of adjacent switch 0 (on the left)
and switch 2 (on the right) must be programmed too.
Without this patchset, a dump of the hardware FDB of switches 0, 1 and 2
after programming a MAC address on lan3 looks like this (*):
# bridge fdb add 11:22:33:44:55:66 dev lan3
# cat /sys/kernel/debug/mv88e6xxx/sw*/atu/0 | grep -v FID
0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6
0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n 0 - - - - - -
0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6
0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 7 8 9
With this patchset applied, adjacent DSA ports get programmed too:
# bridge fdb add 11:22:33:44:55:66 dev lan3
# cat /sys/kernel/debug/mv88e6xxx/sw*/atu/0 | grep -v FID
0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n - - - - - 5 -
0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6
0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n 0 - - - - - -
0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6
0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n - - - - - - - - - 9
0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 7 8 9
In order to do that, the first commit introduces a dsa_towards_port()
helper which returns the local port of a switch which must be used to
reach an arbitrary switch port (local or from an adjacent switch.)
The second patch uses this helper to configure the port reaching the
target port for every switches of the fabric.
(*) a patch for squashed debugfs interface which applies on top of this
patchset is available here:
https://github.com/vivien/linux/commit/f8e6ba34c68a72d3bf42f4dea79abacb2e61a3cc.patch
Vivien Didelot (2):
net: dsa: introduce dsa_towards_port helper
net: dsa: support cross-chip FDB operations
include/net/dsa.h | 23 +++++++++++++----------
net/dsa/switch.c | 14 ++++----------
2 files changed, 17 insertions(+), 20 deletions(-)
--
2.15.0
^ permalink raw reply
* [PATCH net-next 1/2] net: dsa: introduce dsa_towards_port helper
From: Vivien Didelot @ 2017-11-30 17:56 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171130175643.14022-1-vivien.didelot@savoirfairelinux.com>
Add a new helper returning the local port used to reach an arbitrary
switch port in the fabric.
Its only user at the moment is the dsa_upstream_port helper, which
returns the local port reaching the dedicated CPU port, but it will be
used in cross-chip FDB operations.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
include/net/dsa.h | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 2a05738570d8..f90f342dc5b4 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -296,20 +296,23 @@ static inline u32 dsa_user_ports(struct dsa_switch *ds)
return mask;
}
+/* Return the local port used to reach an arbitrary switch port */
+static inline unsigned int dsa_towards_port(struct dsa_switch *ds, int device,
+ int port)
+{
+ if (device == ds->index)
+ return port;
+ else
+ return ds->rtable[device];
+}
+
+/* Return the local port used to reach the dedicated CPU port */
static inline u8 dsa_upstream_port(struct dsa_switch *ds)
{
struct dsa_switch_tree *dst = ds->dst;
+ struct dsa_port *cpu_dp = dst->cpu_dp;
- /*
- * If this is the root switch (i.e. the switch that connects
- * to the CPU), return the cpu port number on this switch.
- * Else return the (DSA) port number that connects to the
- * switch that is one hop closer to the cpu.
- */
- if (dst->cpu_dp->ds == ds)
- return dst->cpu_dp->index;
- else
- return ds->rtable[dst->cpu_dp->ds->index];
+ return dsa_towards_port(ds, cpu_dp->ds->index, cpu_dp->index);
}
typedef int dsa_fdb_dump_cb_t(const unsigned char *addr, u16 vid,
--
2.15.0
^ permalink raw reply related
* [PATCH net-next 2/2] net: dsa: support cross-chip FDB operations
From: Vivien Didelot @ 2017-11-30 17:56 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171130175643.14022-1-vivien.didelot@savoirfairelinux.com>
When a MAC address is added to or removed from a switch port in the
fabric, the target switch must program its port and adjacent switches
must program their local DSA port used to reach the target switch.
For this purpose, use the dsa_towards_port() helper to identify the
local switch port which must be programmed.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
net/dsa/switch.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 29608d087a7c..de1dddc320ff 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -83,29 +83,23 @@ static int dsa_switch_bridge_leave(struct dsa_switch *ds,
static int dsa_switch_fdb_add(struct dsa_switch *ds,
struct dsa_notifier_fdb_info *info)
{
- /* Do not care yet about other switch chips of the fabric */
- if (ds->index != info->sw_index)
- return 0;
+ int port = dsa_towards_port(ds, info->sw_index, info->port);
if (!ds->ops->port_fdb_add)
return -EOPNOTSUPP;
- return ds->ops->port_fdb_add(ds, info->port, info->addr,
- info->vid);
+ return ds->ops->port_fdb_add(ds, port, info->addr, info->vid);
}
static int dsa_switch_fdb_del(struct dsa_switch *ds,
struct dsa_notifier_fdb_info *info)
{
- /* Do not care yet about other switch chips of the fabric */
- if (ds->index != info->sw_index)
- return 0;
+ int port = dsa_towards_port(ds, info->sw_index, info->port);
if (!ds->ops->port_fdb_del)
return -EOPNOTSUPP;
- return ds->ops->port_fdb_del(ds, info->port, info->addr,
- info->vid);
+ return ds->ops->port_fdb_del(ds, port, info->addr, info->vid);
}
static int dsa_switch_mdb_add(struct dsa_switch *ds,
--
2.15.0
^ permalink raw reply related
* Re: [BUG] kernel stack corruption during/after Netlabel error
From: Eric Dumazet @ 2017-11-30 17:57 UTC (permalink / raw)
To: David Ahern, Casey Schaufler, James Morris
Cc: Paul Moore, netdev, Stephen Smalley, selinux, LSM
In-Reply-To: <d29937fd-dd04-8568-f89c-505ff725761a@gmail.com>
On Thu, 2017-11-30 at 10:30 -0700, David Ahern wrote:
> On 11/30/17 8:44 AM, David Ahern wrote:
> > On 11/30/17 3:50 AM, Eric Dumazet wrote:
> > > @@ -1631,24 +1659,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
> > >
> > > th = (const struct tcphdr *)skb->data;
> > > iph = ip_hdr(skb);
> > > - /* This is tricky : We move IPCB at its correct location
> > > into TCP_SKB_CB()
> > > - * barrier() makes sure compiler wont play
> > > fool^Waliasing games.
> > > - */
> > > - memmove(&TCP_SKB_CB(skb)->header.h4, IPCB(skb),
> > > - sizeof(struct inet_skb_parm));
> > > - barrier();
> > > -
> > > - TCP_SKB_CB(skb)->seq = ntohl(th->seq);
> > > - TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th-
> > > >syn + th->fin +
> > > - skb->len - th->doff * 4);
> > > - TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
> > > - TCP_SKB_CB(skb)->tcp_flags = tcp_flag_byte(th);
> > > - TCP_SKB_CB(skb)->tcp_tw_isn = 0;
> > > - TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
> > > - TCP_SKB_CB(skb)->sacked = 0;
> > > - TCP_SKB_CB(skb)->has_rxtstamp =
> > > - skb->tstamp || skb_hwtstamps(skb)-
> > > >hwtstamp;
> > > -
> > > lookup:
> > > sk = __inet_lookup_skb(&tcp_hashinfo, skb,
> > > __tcp_hdrlen(th), th->source,
> > > th->dest, sdif, &refcounted);
> >
> > I believe moving the above is going to affect lookups with VRF. Let
> > me
> > take a look before this gets committed.
> >
>
> Eric:
>
> Can you add this to the patch? Fixes socket lookups with VRF which
> stashes a flag in the cb.
>
> Thanks,
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 4e09398009c1..6c020015d556 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -849,7 +849,7 @@ static inline bool inet_exact_dif_match(struct
> net
> *net, struct sk_buff *skb)
> {
> #if IS_ENABLED(CONFIG_NET_L3_MASTER_DEV)
> if (!net->ipv4.sysctl_tcp_l3mdev_accept &&
> - skb && ipv4_l3mdev_skb(TCP_SKB_CB(skb)->header.h4.flags))
> + skb && ipv4_l3mdev_skb(IPCB(skb)->flags))
> return true;
> #endif
> return false;
I wonder if this should not be in a separate patch ?
Bug was added in 971f10eca186cab238c49daa91f703c5a001b0b1 ("tcp: better
TCP_SKB_CB layout to reduce cache line misses") in linux 3.18
While VRF was added later.
If you agree, I will prepare a patch series, with different Fixes tag
so that David can decide which path needs to be backported into each
stable version.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: David Miller @ 2017-11-30 17:58 UTC (permalink / raw)
To: ard.biesheuvel
Cc: dan.j.williams, will.deacon, jassisinghbrar, netdev, devicetree,
arnd.bergmann, robh+dt, mark.rutland, jaswinder.singh
In-Reply-To: <CAKv+Gu9sOzce_r3JKU8B4JDK2Gr5cB5NZdQxUMEmmy6SZ+sOFw@mail.gmail.com>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Thu, 30 Nov 2017 17:48:44 +0000
> On 30 November 2017 at 17:42, David Miller <davem@davemloft.net> wrote:
>> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Date: Thu, 30 Nov 2017 17:37:27 +0000
>>
>>> Well, the whole point of using memremap() instead of ioremap() is that
>>> the region has memory semantics, i.e., we read the MAC address and the
>>> DMA engine microcode from it. If memremap() itself is flawed in this
>>> regard, I agree we should fix it. But as I understand it, this is
>>> really an implementation problem in memremap() [the fact that it falls
>>> back to ioremap()] and not a problem in this driver.
>>>
>>> So what alternative would you propose in this case?
>>>
>>> BTW, this should be IOREMAP_WC not IOREMAP_WT, because the EEPROM on
>>> the platform in question does not tolerate cached mappings (or rather,
>>> shareable mappings). ioremap_wt() happens to result in device mappings
>>> rather than writethrough cacheable mappings, but this is another
>>> problem in itself. Once arm64 fixes ioremap_wt(), this code will no
>>> longer work on the SynQuacer SoC.
>>
>> It doesn't "fall back", it directly uses ioremap_wt() for non-RAM
>> mappings.
>>
>> It you look, most architectures do a "#define iomrep_wt ioremap"
>
> OK, but that still means the implementation of memremap() is flawed,
> not its use in this driver.
>
> memremap() exists to allow non-DRAM regions to be mapped with memory
> semantics, and if we currently implement that incorrectly, we should
> fix it. But that still does not mean we should have __iomem
> annotations and special accessors in this case, precisely because it
> has memory semantics, and so it is a virtual pointer that may be
> dereferenced normally.
Memory semantics and how to access that memory are two different things.
On sparc64 the cacheability etc. can be specified in the load and
store instructions.
That's why I have all of the ioremap*() routines return a physical
address. The value returned from all of the ioremap*() interfaces is
completely opaque. That's why the return type is __iomem.
The iomem accessors on sparc64 use the appropriate access bits in the
load and store instructions as needed.
So in order for this to work properly, new sets of acessors need to be
implemented to let me give you the access semantics you want yet at
the same time allowing architectures to have the flexibility of
still returning an opaque "pointer".
There is no reason for me to make a virtual mapping on sparc64 because
it is completely unnecessary overhead since I can give you whatever
cacheability/IO/etc. attributes needed in the load and store
instructions themselves.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Eric Dumazet @ 2017-11-30 17:59 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Solio Sarabia, David Ahern, davem, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <20171130094932.6d9e7c61@xeon-e3>
On Thu, 2017-11-30 at 09:49 -0800, Stephen Hemminger wrote:
> On Thu, 30 Nov 2017 09:26:39 -0800
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> > >
> > >
> > > The problem goes back into the core GSO networking code.
> > > Something like this is needed.
> > >
> > > static inline bool netif_needs_gso(struct sk_buff *skb,
> > > const struct net_device *dev,
> > > netdev_features_t features)
> > > {
> > > return skb_is_gso(skb) &&
> > > (!skb_gso_ok(skb, features) ||
> > > unlikely(skb_shinfo(skb)->gso_segs > dev-
> > > > gso_max_segs) || << new
> > >
> > > unlikely(skb_shinfo(skb)->gso_size > dev-
> > > > gso_max_size) || << new
> > >
> > > unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> > > (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> > > }
> > >
> > > What that will do is split up the monster GSO packets if they
> > > ever
> > > bleed
> > > across from one device to another through the twisty mazes of
> > > packet
> > > processing paths.
> >
> >
> > Since very few drivers have these gso_max_segs / gso_max_size,
> > check
> > could be done in their ndo_features_check()
>
> Actually, we already check for max_segs, just missing check for size
> here:
>
> From 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00
> 2001
> From: Stephen Hemminger <sthemmin@microsoft.com>
> Date: Thu, 30 Nov 2017 09:45:11 -0800
> Subject: [PATCH] net: do not GSO if frame is too large
>
> This adds an additional check to breakup skb's that exceed a devices
> GSO maximum size. The code was already checking for too many segments
> but did not check size.
>
> This has been observed to be a problem when using containers on
> Hyper-V/Azure where the allowed GSO maximum size is less than
> maximum and skb's have gone through multiple layers to arrive
> at the virtual device.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> net/core/dev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 07ed21d64f92..0bb398f3bfa3 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2918,9 +2918,11 @@ static netdev_features_t
> gso_features_check(const struct sk_buff *skb,
> struct net_device *dev,
> netdev_features_t
> features)
> {
> + unsigned int gso_size = skb_shinfo(skb)->gso_size;
> u16 gso_segs = skb_shinfo(skb)->gso_segs;
>
> - if (gso_segs > dev->gso_max_segs)
> + if (gso_segs > dev->gso_max_segs ||
> + gso_size > dev->gso_max_size)
> return features & ~NETIF_F_GSO_MASK;
>
> /* Support for GSO partial features requires software
Yes, but check commit 743b03a83297690f0bd38c452a3bbb47d2be300a
("net: remove netdevice gso_min_segs")
Plan was to get rid of the existing check, not adding new ones :/
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: bcm_sf2: Utilize b53_get_tag_protocol()
From: David Miller @ 2017-11-30 18:00 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20171130175536.1925-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 30 Nov 2017 09:55:35 -0800
> Utilize the much more capable b53_get_tag_protocol() which takes care of
> all Broadcom switches specifics to resolve which port can have Broadcom
> tags enabled or not.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks Florian.
^ permalink raw reply
* Re: [BUG] kernel stack corruption during/after Netlabel error
From: David Ahern @ 2017-11-30 18:03 UTC (permalink / raw)
To: Eric Dumazet, Casey Schaufler, James Morris
Cc: Paul Moore, netdev, Stephen Smalley, selinux, LSM
In-Reply-To: <1512064629.19682.21.camel@gmail.com>
On 11/30/17 10:57 AM, Eric Dumazet wrote:
> I wonder if this should not be in a separate patch ?
>
> Bug was added in 971f10eca186cab238c49daa91f703c5a001b0b1 ("tcp: better
> TCP_SKB_CB layout to reduce cache line misses") in linux 3.18
>
> While VRF was added later.
>
> If you agree, I will prepare a patch series, with different Fixes tag
> so that David can decide which path needs to be backported into each
> stable version.
>
That's sound fine to me.
^ permalink raw reply
* Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level
From: Joe Perches @ 2017-11-30 18:06 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, dhowells, linux-afs
In-Reply-To: <20171130.123117.1742804316627893121.davem@davemloft.net>
On Thu, 2017-11-30 at 12:31 -0500, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Thu, 30 Nov 2017 08:21:14 -0800
>
> > When enabled, the current debug logging does not have a KERN_<LEVEL>.
> > Add KERN_DEBUG to the logging macros.
> >
> > Miscellanea:
> >
> > o Remove #define redundancy and neaten the macros a bit
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Please also CC: the proper mailing list and maintainer for rxrpc.
>
> The MAINTAINERS entry for rxrpc needs to include more than just
> net/rxrpc/af_rxrpc.c, David please fix this up as I know Joe is going
> to use the excuse that he didn't CC: you and the AFS list because of
> this.
There is no listed rxrpc maintainer.
David Howells entry is:
AFS FILESYSTEM & AF_RXRPC SOCKET DOMAIN
M: David Howells <dhowells@redhat.com>
L: linux-afs@lists.infradead.org
S: Supported
F: fs/afs/
F: include/net/af_rxrpc.h
F: net/rxrpc/af_rxrpc.c
W: https://www.infradead.org/~dhowells/kafs/
which seems pretty specific to AFS and its rxrpc kernel interface.
Excuse is probably the wrong word here David.
Rationale maybe...
cheers, Joe
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Stephen Hemminger @ 2017-11-30 18:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Solio Sarabia, David Ahern, davem, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <1512064763.19682.23.camel@gmail.com>
On Thu, 30 Nov 2017 09:59:23 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2017-11-30 at 09:49 -0800, Stephen Hemminger wrote:
> > On Thu, 30 Nov 2017 09:26:39 -0800
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> > > >
> > > >
> > > > The problem goes back into the core GSO networking code.
> > > > Something like this is needed.
> > > >
> > > > static inline bool netif_needs_gso(struct sk_buff *skb,
> > > > const struct net_device *dev,
> > > > netdev_features_t features)
> > > > {
> > > > return skb_is_gso(skb) &&
> > > > (!skb_gso_ok(skb, features) ||
> > > > unlikely(skb_shinfo(skb)->gso_segs > dev-
> > > > > gso_max_segs) || << new
> > > >
> > > > unlikely(skb_shinfo(skb)->gso_size > dev-
> > > > > gso_max_size) || << new
> > > >
> > > > unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> > > > (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> > > > }
> > > >
> > > > What that will do is split up the monster GSO packets if they
> > > > ever
> > > > bleed
> > > > across from one device to another through the twisty mazes of
> > > > packet
> > > > processing paths.
> > >
> > >
> > > Since very few drivers have these gso_max_segs / gso_max_size,
> > > check
> > > could be done in their ndo_features_check()
> >
> > Actually, we already check for max_segs, just missing check for size
> > here:
> >
> > From 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00
> > 2001
> > From: Stephen Hemminger <sthemmin@microsoft.com>
> > Date: Thu, 30 Nov 2017 09:45:11 -0800
> > Subject: [PATCH] net: do not GSO if frame is too large
> >
> > This adds an additional check to breakup skb's that exceed a devices
> > GSO maximum size. The code was already checking for too many segments
> > but did not check size.
> >
> > This has been observed to be a problem when using containers on
> > Hyper-V/Azure where the allowed GSO maximum size is less than
> > maximum and skb's have gone through multiple layers to arrive
> > at the virtual device.
> >
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > ---
> > net/core/dev.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 07ed21d64f92..0bb398f3bfa3 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -2918,9 +2918,11 @@ static netdev_features_t
> > gso_features_check(const struct sk_buff *skb,
> > struct net_device *dev,
> > netdev_features_t
> > features)
> > {
> > + unsigned int gso_size = skb_shinfo(skb)->gso_size;
> > u16 gso_segs = skb_shinfo(skb)->gso_segs;
> >
> > - if (gso_segs > dev->gso_max_segs)
> > + if (gso_segs > dev->gso_max_segs ||
> > + gso_size > dev->gso_max_size)
> > return features & ~NETIF_F_GSO_MASK;
> >
> > /* Support for GSO partial features requires software
>
>
> Yes, but check commit 743b03a83297690f0bd38c452a3bbb47d2be300a
> ("net: remove netdevice gso_min_segs")
>
> Plan was to get rid of the existing check, not adding new ones :/
Sure can do it in the driver and that has other benefits like ability
to backport to older distributions.
Still need gso_max_size though since want to tell TCP to avoid
generating mega-jumbo frames.
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: Ard Biesheuvel @ 2017-11-30 18:08 UTC (permalink / raw)
To: David Miller
Cc: Williams, Dan J, Will Deacon, Jassi Brar,
<netdev@vger.kernel.org>, devicetree@vger.kernel.org,
Arnd Bergmann, Rob Herring, Mark Rutland, Jaswinder Singh
In-Reply-To: <20171130.125813.1832145274236885737.davem@davemloft.net>
On 30 November 2017 at 17:58, David Miller <davem@davemloft.net> wrote:
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date: Thu, 30 Nov 2017 17:48:44 +0000
>
>> On 30 November 2017 at 17:42, David Miller <davem@davemloft.net> wrote:
>>> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> Date: Thu, 30 Nov 2017 17:37:27 +0000
>>>
>>>> Well, the whole point of using memremap() instead of ioremap() is that
>>>> the region has memory semantics, i.e., we read the MAC address and the
>>>> DMA engine microcode from it. If memremap() itself is flawed in this
>>>> regard, I agree we should fix it. But as I understand it, this is
>>>> really an implementation problem in memremap() [the fact that it falls
>>>> back to ioremap()] and not a problem in this driver.
>>>>
>>>> So what alternative would you propose in this case?
>>>>
>>>> BTW, this should be IOREMAP_WC not IOREMAP_WT, because the EEPROM on
>>>> the platform in question does not tolerate cached mappings (or rather,
>>>> shareable mappings). ioremap_wt() happens to result in device mappings
>>>> rather than writethrough cacheable mappings, but this is another
>>>> problem in itself. Once arm64 fixes ioremap_wt(), this code will no
>>>> longer work on the SynQuacer SoC.
>>>
>>> It doesn't "fall back", it directly uses ioremap_wt() for non-RAM
>>> mappings.
>>>
>>> It you look, most architectures do a "#define iomrep_wt ioremap"
>>
>> OK, but that still means the implementation of memremap() is flawed,
>> not its use in this driver.
>>
>> memremap() exists to allow non-DRAM regions to be mapped with memory
>> semantics, and if we currently implement that incorrectly, we should
>> fix it. But that still does not mean we should have __iomem
>> annotations and special accessors in this case, precisely because it
>> has memory semantics, and so it is a virtual pointer that may be
>> dereferenced normally.
>
> Memory semantics and how to access that memory are two different things.
>
> On sparc64 the cacheability etc. can be specified in the load and
> store instructions.
>
> That's why I have all of the ioremap*() routines return a physical
> address. The value returned from all of the ioremap*() interfaces is
> completely opaque. That's why the return type is __iomem.
>
> The iomem accessors on sparc64 use the appropriate access bits in the
> load and store instructions as needed.
>
> So in order for this to work properly, new sets of acessors need to be
> implemented to let me give you the access semantics you want yet at
> the same time allowing architectures to have the flexibility of
> still returning an opaque "pointer".
>
> There is no reason for me to make a virtual mapping on sparc64 because
> it is completely unnecessary overhead since I can give you whatever
> cacheability/IO/etc. attributes needed in the load and store
> instructions themselves.
>
But the whole point of memremap() is obtaining a virtual mapping that
does not require accessors, but can be used like ordinary memory. The
fact that Sparc64 can do nifty things using special accessors but
without a virtual mapping is interesting, but not really relevant
IMHO.
So I will work with Jassi to reimplement this using ioremap(), given
that it is not performance critical, and given the fact that your
criticism appears to be directed to memremap() in general, and not the
way it is being used here.
Thanks,
Ard.
^ permalink raw reply
* Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
From: Eric Dumazet @ 2017-11-30 18:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Solio Sarabia, David Ahern, davem, netdev, sthemmin,
shiny.sebastian
In-Reply-To: <20171130100825.01ea1d14@xeon-e3>
On Thu, 2017-11-30 at 10:08 -0800, Stephen Hemminger wrote:
> On Thu, 30 Nov 2017 09:59:23 -0800
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Thu, 2017-11-30 at 09:49 -0800, Stephen Hemminger wrote:
> > > On Thu, 30 Nov 2017 09:26:39 -0800
> > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >
> > > > On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> > > > >
> > > > >
> > > > > The problem goes back into the core GSO networking code.
> > > > > Something like this is needed.
> > > > >
> > > > > static inline bool netif_needs_gso(struct sk_buff *skb,
> > > > > const struct net_device
> > > > > *dev,
> > > > > netdev_features_t features)
> > > > > {
> > > > > return skb_is_gso(skb) &&
> > > > > (!skb_gso_ok(skb, features) ||
> > > > > unlikely(skb_shinfo(skb)->gso_segs > dev-
> > > > > > gso_max_segs) || << new
> > > > >
> > > > > unlikely(skb_shinfo(skb)->gso_size > dev-
> > > > > > gso_max_size) || << new
> > > > >
> > > > > unlikely((skb->ip_summed != CHECKSUM_PARTIAL)
> > > > > &&
> > > > > (skb->ip_summed !=
> > > > > CHECKSUM_UNNECESSARY)));
> > > > > }
> > > > >
> > > > > What that will do is split up the monster GSO packets if they
> > > > > ever
> > > > > bleed
> > > > > across from one device to another through the twisty mazes of
> > > > > packet
> > > > > processing paths.
> > > >
> > > >
> > > > Since very few drivers have these gso_max_segs / gso_max_size,
> > > > check
> > > > could be done in their ndo_features_check()
> > >
> > > Actually, we already check for max_segs, just missing check for
> > > size
> > > here:
> > >
> > > From 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00
> > > 2001
> > > From: Stephen Hemminger <sthemmin@microsoft.com>
> > > Date: Thu, 30 Nov 2017 09:45:11 -0800
> > > Subject: [PATCH] net: do not GSO if frame is too large
> > >
> > > This adds an additional check to breakup skb's that exceed a
> > > devices
> > > GSO maximum size. The code was already checking for too many
> > > segments
> > > but did not check size.
> > >
> > > This has been observed to be a problem when using containers on
> > > Hyper-V/Azure where the allowed GSO maximum size is less than
> > > maximum and skb's have gone through multiple layers to arrive
> > > at the virtual device.
> > >
> > > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > > ---
> > > net/core/dev.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 07ed21d64f92..0bb398f3bfa3 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -2918,9 +2918,11 @@ static netdev_features_t
> > > gso_features_check(const struct sk_buff *skb,
> > > struct net_device
> > > *dev,
> > > netdev_features_t
> > > features)
> > > {
> > > + unsigned int gso_size = skb_shinfo(skb)->gso_size;
> > > u16 gso_segs = skb_shinfo(skb)->gso_segs;
> > >
> > > - if (gso_segs > dev->gso_max_segs)
> > > + if (gso_segs > dev->gso_max_segs ||
> > > + gso_size > dev->gso_max_size)
> > > return features & ~NETIF_F_GSO_MASK;
> > >
> > > /* Support for GSO partial features requires software
> >
> >
> > Yes, but check commit 743b03a83297690f0bd38c452a3bbb47d2be300a
> > ("net: remove netdevice gso_min_segs")
> >
> > Plan was to get rid of the existing check, not adding new ones :/
>
> Sure can do it in the driver and that has other benefits like ability
> to backport to older distributions.
>
> Still need gso_max_size though since want to tell TCP to avoid
> generating mega-jumbo frames.
>
Sure, the netdev->gso_max_{size|segs} are staying.
I was simply trying to not add another check in fast path :/
Thanks.
^ permalink raw reply
* Re: [PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level
From: David Miller @ 2017-11-30 18:13 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, netdev, dhowells, linux-afs
In-Reply-To: <1512065211.19952.112.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 30 Nov 2017 10:06:51 -0800
> Excuse is probably the wrong word here David.
> Rationale maybe...
I guess you turn a blind eye to the hundreds of the rxrpc patches
David has posted here over the past few months....
That's all I'm saying. If you see reality is disconnected from
what is in the MAINTAINERS file, please don't just ignore it.
^ permalink raw reply
* Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: David Miller @ 2017-11-30 18:14 UTC (permalink / raw)
To: ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A
Cc: dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, will.deacon-5wv7dgnIgG8,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <CAKv+Gu9qpLWTjjCZBvyn87HoNNY+U5++2UeHxF8jXYQPDd3U1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Thu, 30 Nov 2017 18:08:34 +0000
> But the whole point of memremap() is obtaining a virtual mapping
> that does not require accessors, but can be used like ordinary
> memory.
That's unfortunately not what it's doing.
It's relying on the fact that some architectures (I guess x86
and arm) do happen to give a virutal address from ioremap_wt()
even though it's return type is annotated __iomem.
Thanks in advance for changing your driver to use ioremap() and
accessors for now.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Russell King - ARM Linux @ 2017-11-30 18:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bhaskar Upadhaya, netdev@vger.kernel.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20171130174127.GA28828@lunn.ch>
On Thu, Nov 30, 2017 at 06:41:27PM +0100, Andrew Lunn wrote:
> SGMII supports passing auto-negotiation results from the PHY to the
> MAC. 1000BASE-X does not.
>
> SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
> support this, the MAC needs to replicate the bits 100, or 10 times
> when the PHY is running in 10 or 100Mbps mode.
>
> So with your 2.5G SGMII, you need to replicate the bits 250, 25, or
> 2.5 times if they PHY is running at lower speeds. This last one is
> interesting.
That's not what I've read so far - but I don't know about the PHY
in this exact case because the docs are only available under NDA
(which makes it incredibly difficult to have this discussion.)
However, from what I can ascertain from a Xilinx document, 2.5G is
1G SGMII clocked 2.5x faster. When in 2.5G mode, the other modes
are unavailable. There's also no 250M or 25M as the speed bits
are not relevant.
The Xilinx doc does talk about a "2.5G SGMII standard" but I haven't
been able to locate such a thing - maybe someone can provide some
pointers?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [BUG] kernel stack corruption during/after Netlabel error
From: Casey Schaufler @ 2017-11-30 18:16 UTC (permalink / raw)
To: Eric Dumazet, David Ahern, James Morris
Cc: Paul Moore, netdev, Stephen Smalley, selinux, LSM
In-Reply-To: <1512064629.19682.21.camel@gmail.com>
On 11/30/2017 9:57 AM, Eric Dumazet wrote:
> On Thu, 2017-11-30 at 10:30 -0700, David Ahern wrote:
>> On 11/30/17 8:44 AM, David Ahern wrote:
>>> On 11/30/17 3:50 AM, Eric Dumazet wrote:
>>>> @@ -1631,24 +1659,6 @@ int tcp_v4_rcv(struct sk_buff *skb)
>>>>
>>>> th = (const struct tcphdr *)skb->data;
>>>> iph = ip_hdr(skb);
>>>> - /* This is tricky : We move IPCB at its correct location
>>>> into TCP_SKB_CB()
>>>> - * barrier() makes sure compiler wont play
>>>> fool^Waliasing games.
>>>> - */
>>>> - memmove(&TCP_SKB_CB(skb)->header.h4, IPCB(skb),
>>>> - sizeof(struct inet_skb_parm));
>>>> - barrier();
>>>> -
>>>> - TCP_SKB_CB(skb)->seq = ntohl(th->seq);
>>>> - TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th-
>>>>> syn + th->fin +
>>>> - skb->len - th->doff * 4);
>>>> - TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
>>>> - TCP_SKB_CB(skb)->tcp_flags = tcp_flag_byte(th);
>>>> - TCP_SKB_CB(skb)->tcp_tw_isn = 0;
>>>> - TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
>>>> - TCP_SKB_CB(skb)->sacked = 0;
>>>> - TCP_SKB_CB(skb)->has_rxtstamp =
>>>> - skb->tstamp || skb_hwtstamps(skb)-
>>>>> hwtstamp;
>>>> -
>>>> lookup:
>>>> sk = __inet_lookup_skb(&tcp_hashinfo, skb,
>>>> __tcp_hdrlen(th), th->source,
>>>> th->dest, sdif, &refcounted);
>>> I believe moving the above is going to affect lookups with VRF. Let
>>> me
>>> take a look before this gets committed.
>>>
>> Eric:
>>
>> Can you add this to the patch? Fixes socket lookups with VRF which
>> stashes a flag in the cb.
I've done my testing and it works both ways for Smack.
>>
>> Thanks,
>>
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 4e09398009c1..6c020015d556 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -849,7 +849,7 @@ static inline bool inet_exact_dif_match(struct
>> net
>> *net, struct sk_buff *skb)
>> {
>> #if IS_ENABLED(CONFIG_NET_L3_MASTER_DEV)
>> if (!net->ipv4.sysctl_tcp_l3mdev_accept &&
>> - skb && ipv4_l3mdev_skb(TCP_SKB_CB(skb)->header.h4.flags))
>> + skb && ipv4_l3mdev_skb(IPCB(skb)->flags))
>> return true;
>> #endif
>> return false;
>
> I wonder if this should not be in a separate patch ?
>
> Bug was added in 971f10eca186cab238c49daa91f703c5a001b0b1 ("tcp: better
> TCP_SKB_CB layout to reduce cache line misses") in linux 3.18
>
> While VRF was added later.
>
> If you agree, I will prepare a patch series, with different Fixes tag
> so that David can decide which path needs to be backported into each
> stable version.
>
> Thanks.
>
>
^ permalink raw reply
* [PATCH 0/3] Receive packets filtering for macb driver
From: Rafal Ozieblo @ 2017-11-30 18:17 UTC (permalink / raw)
To: Nicolas Ferre, netdev, linux-kernel; +Cc: Rafal Ozieblo
This patch series adds support for receive packets
filtering for Cadence GEM driver. Packets can be redirect
to different hardware queues based on source IP, destination IP,
source port or destination port. To enable filtering,
support for RX queueing was added as well.
Rafal Ozieblo (3):
net: macb: Added support for many RX queues
net: macb: Added some queue statistics
net: macb: Added support for RX filtering
drivers/net/ethernet/cadence/macb.h | 166 +++++++-
drivers/net/ethernet/cadence/macb_main.c | 679 +++++++++++++++++++++++++------
2 files changed, 699 insertions(+), 146 deletions(-)
--
2.4.5
^ 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