Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sat, 17 Apr 2021 15:29:04 +0800 you wrote:
> Issue was traffic problems after a while with increased ping times if
> flow offload is active. It turns out that key_offset with cookie is
> needed in rhashtable_params but w
On Thu, Apr 15, 2021 at 04:27:58PM -0500, Rob Herring wrote:
> On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote:
> > The 'dsa,tag-protocol' is used to force a switch tree to use a
> > particular tag protocol, typically because the Ethernet controller
> > that it is connected to is
Tested on Bananapi-r2 (please see my mt7623 patch for supporting offloading)
with ~300 iperf3 iterations and uptime >6h
Tested-by: Frank Wunderlich
regards Frank
Issue was traffic problems after a while with increased ping times if
flow offload is active. It turns out that key_offset with cookie is
needed in rhashtable_params but was re-assigned to head_offset.
Fix the assignment.
Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading suppor
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Fri, 16 Apr 2021 11:15:17 +0300 you wrote:
> From: Stefan Chulski
>
> Add parser entries for different IPv4 IHL values.
> Each entry will set the L4 header offset according to the IPv4 IHL field.
> L3 header offset wil
From: Stefan Chulski
Add parser entries for different IPv4 IHL values.
Each entry will set the L4 header offset according to the IPv4 IHL field.
L3 header offset will set during the parsing of the IPv4 protocol.
Because of missed parser support for IP header length > 20, RX IPv4 checksum HW
off
On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote:
> The 'dsa,tag-protocol' is used to force a switch tree to use a
> particular tag protocol, typically because the Ethernet controller
> that it is connected to is not compatible with the default one.
>
> Signed-off-by: Tobias Walde
On Thu, Apr 15, 2021 at 11:26:09AM +0200, Tobias Waldekranz wrote:
> Some combinations of tag protocols and Ethernet controllers are
> incompatible, and it is hard for the driver to keep track of these.
>
> Therefore, allow the device tree author (typically the board vendor)
> to inform the driver
On 4/15/2021 2:26 AM, Tobias Waldekranz wrote:
> Previously DSA ports were also included, on the assumption that the
> protocol used by the CPU port had to the matched throughout the entire
> tree.
>
> As there is not yet any consumer in need of this, drop the call.
>
> Signed-off-by: Tobias W
On 4/15/2021 2:26 AM, Tobias Waldekranz wrote:
> For devices that supports both regular and Ethertyped DSA tags, allow
> the user to change the protocol.
>
> Additionally, because there are ethernet controllers that do not
> handle regular DSA tags in all cases, also allow the protocol to be
>
On 4/15/2021 2:26 AM, Tobias Waldekranz wrote:
> All devices are capable of using regular DSA tags. Support for
> Ethertyped DSA tags sort into three categories:
>
> 1. No support. Older chips fall into this category.
>
> 2. Full support. Datasheet explicitly supports configuring the CPU
>
On Thu, Apr 15, 2021 at 11:26:08AM +0200, Tobias Waldekranz wrote:
> Previously DSA ports were also included, on the assumption that the
> protocol used by the CPU port had to the matched throughout the entire
> tree.
>
> As there is not yet any consumer in need of this, drop the call.
>
> Signed
On Thu, Apr 15, 2021 at 11:26:07AM +0200, Tobias Waldekranz wrote:
> For devices that supports both regular and Ethertyped DSA tags, allow
> the user to change the protocol.
>
> Additionally, because there are ethernet controllers that do not
> handle regular DSA tags in all cases, also allow the
On Thu, Apr 15, 2021 at 11:26:06AM +0200, Tobias Waldekranz wrote:
> All devices are capable of using regular DSA tags. Support for
> Ethertyped DSA tags sort into three categories:
>
> 1. No support. Older chips fall into this category.
>
> 2. Full support. Datasheet explicitly supports configur
Some combinations of tag protocols and Ethernet controllers are
incompatible, and it is hard for the driver to keep track of these.
Therefore, allow the device tree author (typically the board vendor)
to inform the driver of this fact by selecting an alternate protocol
that is known to work.
Sign
For devices that supports both regular and Ethertyped DSA tags, allow
the user to change the protocol.
Additionally, because there are ethernet controllers that do not
handle regular DSA tags in all cases, also allow the protocol to be
changed on devices with undocumented support for EDSA. But, in
The 'dsa,tag-protocol' is used to force a switch tree to use a
particular tag protocol, typically because the Ethernet controller
that it is connected to is not compatible with the default one.
Signed-off-by: Tobias Waldekranz
---
Documentation/devicetree/bindings/net/dsa/dsa.yaml | 9 +
Previously DSA ports were also included, on the assumption that the
protocol used by the CPU port had to the matched throughout the entire
tree.
As there is not yet any consumer in need of this, drop the call.
Signed-off-by: Tobias Waldekranz
---
net/dsa/switch.c | 25 +++--
This is a continuation of the work started in this patch:
https://lore.kernel.org/netdev/20210323102326.3677940-1-tob...@waldekranz.com/
In addition to the mv88e6xxx support to dynamically change the
protocol, it is now possible to override the protocol from the device
tree. This means that when a
All devices are capable of using regular DSA tags. Support for
Ethertyped DSA tags sort into three categories:
1. No support. Older chips fall into this category.
2. Full support. Datasheet explicitly supports configuring the CPU
port to receive FORWARDs with a DSA tag.
3. Undocumented suppor
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Thomas-Bogendoerfer/net-Korina-improvements/20210414-233326
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
5871d0c6b8e
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 14 Apr 2021 22:22:57 +0300 you wrote:
> From: Florian Fainelli
>
> Some Ethernet switches might only be able to support disabling multicast
> snooping globally, which is an issue for example when several bridges
>
From: Thomas Bogendoerfer
Date: Wed, 14 Apr 2021 17:29:36 +0200
> While converting Mikrotik RB532 support to use device tree I stumbled
> over the korina ethernet driver, which used way too many MIPS specific
> hacks. This series cleans this all up and adds support for device tree.
>
> Changes i
From: Florian Fainelli
Some Ethernet switches might only be able to support disabling multicast
snooping globally, which is an issue for example when several bridges
span the same physical device and request contradictory settings.
Propagate the return value of br_mc_disabled_update() such that
On 4/14/2021 8:29 AM, Thomas Bogendoerfer wrote:
> If there is no mac address passed via platform data try to get it via
> device tree and fall back to a random mac address, if all fail.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> drivers/net/ethernet/korina.c | 29
Get rid of access to struct korina_device by just passing the mac
address via platform data and use drvdata for passing netdev to remove
function.
Signed-off-by: Thomas Bogendoerfer
---
arch/mips/rb532/devices.c | 5 +++--
drivers/net/ethernet/korina.c | 11 ++-
2 files changed, 9 i
Move structs/defines for ethernet/dma register into driver, since they
are only used for this driver and remove any MIPS specific includes.
This makes it possible to COMPILE_TEST the driver.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/Kconfig | 2 +-
drivers/net/ethernet/korin
With device tree clock is provided via CCF. For non device tree
use a maximum clock value to not overclock the PHY. The non device
tree usage will go away after platform is converted to DT.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/korina.c | 19 +--
1 file chan
If there is no mac address passed via platform data try to get it via
device tree and fall back to a random mac address, if all fail.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/korina.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --
Remove helpers, which are only used in one call site.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/korina.c | 28 +++-
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index b6dcbb6
Instead of messing with MIPS specific macros use DMA API for mapping
descriptors and skbs.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/korina.c | 158 +-
1 file changed, 98 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/korina.c
Descriptors are mapped uncached so there is no need to do any cache
handling for them.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/korina.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 3a454f6214b0..b
Simplify probe/remove code by using devm_ functions.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/korina.c | 64 ---
1 file changed, 21 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index
Fixed MDIO functions to work reliable and not just by accident.
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/korina.c | 57 +++
2 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethern
While converting Mikrotik RB532 support to use device tree I stumbled
over the korina ethernet driver, which used way too many MIPS specific
hacks. This series cleans this all up and adds support for device tree.
Changes in v2:
- added device tree support to get rid of idt_cpu_freq
- fixed com
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 13 Apr 2021 10:22:16 -0700 you wrote:
> All the uses of HWTSTAMP_FILTER_* values need to be
> bit shifters, not straight values.
>
> v2: fixed subject and added Cc Dan and SoB Allen
>
> Fixes: f8ba81da73fc ("ionic
All the uses of HWTSTAMP_FILTER_* values need to be
bit shifters, not straight values.
v2: fixed subject and added Cc Dan and SoB Allen
Fixes: f8ba81da73fc ("ionic: add ethtool support for PTP")
Cc: Dan Carpenter
Signed-off-by: Shannon Nelson
Signed-off-by: Allen Hubbe
---
.../ethernet/pensan
Ability for user to set seed value for multipath routing hashes.
Now kernel uses random seed value:
this is done to prevent hash-flooding DoS attacks,
but it breaks some scenario, f.e:
+---++--+++
| |-eth0---| FW0 |---eth0-||
| |+--+
> From: Stephen Hemminger
> Sent: Thursday, April 8, 2021 9:52 AM
Thanks all for your input! We'll make the below changes as suggested:
Microsoft Azure Network Device ==> Microsoft Network Devices
Drop the default m
validated ==> supported
We'll also fix some warnings reported by "kernel test r
; netdev@vger.kernel.org; l...@kernel.org;
> and...@lunn.ch; be...@petrovitsch.priv.at; linux-ker...@vger.kernel.org;
> linux-hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
>
> On Thu, 8 Apr 2021 09:22:57 -0
On Thu, 8 Apr 2021 09:22:57 -0700
Randy Dunlap wrote:
> On 4/8/21 2:15 AM, Dexuan Cui wrote:
> > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > b/drivers/net/ethernet/microsoft/Kconfig
> > new file mode 100644
> > index ..12ef6b581566
> > --- /dev/null
> > +++ b/drivers/net/
; netdev@vger.kernel.org; l...@kernel.org;
> be...@petrovitsch.priv.at; linux-ker...@vger.kernel.org; linux-
> hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
>
> > > > diff --git a/drivers/net/ethernet/mi
> > > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > b/drivers/net/ethernet/microsoft/Kconfig
> > > new file mode 100644
> > > index ..12ef6b581566
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/microsoft/Kconfig
> > > @@ -0,0 +1,30 @@
> > > +#
> > > +# Microsoft Azure ne
el.org;
> and...@lunn.ch; be...@petrovitsch.priv.at
> Cc: linux-ker...@vger.kernel.org; linux-hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
>
> On 4/8/21 2:15 AM, Dexuan Cui wrote:
> > diff --
On 4/8/21 2:15 AM, Dexuan Cui wrote:
> diff --git a/drivers/net/ethernet/microsoft/Kconfig
> b/drivers/net/ethernet/microsoft/Kconfig
> new file mode 100644
> index ..12ef6b581566
> --- /dev/null
> +++ b/drivers/net/ethernet/microsoft/Kconfig
> @@ -0,0 +1,30 @@
> +#
> +# Microsoft Azur
Hi Dexuan,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Dexuan-Cui/net-mana-Add-a-driver-for-Microsoft-Azure-Network-Adapter-MANA/20210408-171836
base: https://git.kernel.org/pub/scm/linux/kernel/git/d
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 6 Apr 2021 09:32:50 +0800 you wrote:
> EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
> sequence and vice versa.
>
> Signed-off-by: Voon Weifeng
> ---
> Changes:
> v1 -> v2
> -change s
EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
sequence and vice versa.
Signed-off-by: Voon Weifeng
---
Changes:
v1 -> v2
-change subject from "net: intel" to "stmmac: intel"
---
drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 10 ++
drivers/net/ethernet/s
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sun, 4 Apr 2021 13:38:23 + you wrote:
> struct ip6_sf_socklist and ipv6_mc_socklist are per-socket MLD data.
> These data are protected by rtnl lock, socket lock, and RCU.
> So, when these are used, it verifies whet
struct ip6_sf_socklist and ipv6_mc_socklist are per-socket MLD data.
These data are protected by rtnl lock, socket lock, and RCU.
So, when these are used, it verifies whether rtnl lock is acquired or not.
ip6_mc_msfget() is called by do_ipv6_getsockopt().
But caller doesn't acquire rtnl lock.
So,
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 26 Mar 2021 01:39:11 +0800 you wrote:
> This patchset adds support for multi MSI interrupts in addition to
> current single common interrupt implementation. Each MSI interrupt is tied
> to a newly introduce interru
>+static int stmmac_config_multi_msi(struct pci_dev *pdev,
>+ struct plat_stmmacenet_data *plat,
>+ struct stmmac_resources *res)
>+{
For optimum RX & TX queue processing on the same IRQ, we should use
irq_set_affinity_hint() to set th
From: "Wong, Vee Khee"
For interrupt mode INTM=0, TX/RX transfer complete will trigger signal
not only on sbd_perch_[tx|rx]_intr_o (Transmit/Receive Per Channel) but
also on the sbd_intr_o (Common).
As for multi-MSI implementation, setting interrupt mode INTM=1 is more
efficient as each TX intr
From: Ong Boon Leong
Now we introduce MSI interrupt service routines and hook these routines
up if stmmac_open() sees valid irq line being requested:-
stmmac_mac_interrupt():- MAC (dev->irq), WOL (wol_irq), LPI (lpi_irq)
stmmac_safety_interrupt() :- Safety Feat Correctible Error (sfty_ce_irq
From: Ong Boon Leong
Intel mgbe controller supports multi-vector interrupts:
msi_rx_vec 0,2,4,6,8,10,12,14
msi_tx_vec 1,3,5,7,9,11,13,15
msi_sfty_ue_vec 26
msi_sfty_ce_vec 27
msi_lpi_vec 28
msi_mac_vec 29
During probe(), the driver will starts with request allocation for
multi-
From: Ong Boon Leong
Refactor stmmac_interrupt() by introducing stmmac_common_interrupt()
so that we prepare the ISR operation to be friendly to MSI later.
Signed-off-by: Ong Boon Leong
Signed-off-by: Voon Weifeng
---
Changes:
v1 -> v2
-Remove defensive check for invalid dev pointer
---
.../
From: Ong Boon Leong
In preparation to make stmmac support multi-vector MSI, we introduce the
interrupt status masking according to RX, TX or RXTX. Default to use RXTX
inside stmmac_dma_interrupt(), so there is no run-time logic difference
now.
Signed-off-by: Ong Boon Leong
Signed-off-by: Voon
This patchset adds support for multi MSI interrupts in addition to
current single common interrupt implementation. Each MSI interrupt is tied
to a newly introduce interrupt service routine(ISR). Hence, each interrupt
will only go through the corresponding ISR.
In order to increase the efficiency,
On Mon, Mar 22, 2021 at 04:04:01PM +0800, DENG Qingfang wrote:
> On Fri, Mar 19, 2021 at 6:49 PM Vladimir Oltean wrote:
> > Why would you even want to look at the source net device for forwarding?
> > I'd say that if dp->bridge_dev is NULL in the xmit function, you certainly
> > want to bypass add
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 22 Mar 2021 11:51:55 +0800 you wrote:
> This patchset refactor some functions and add some new features for
> flow director.
>
> patch 1~3: refactor large functions
> patch 4, 7: add traffic class and user-def fie
On Mon, Mar 22, 2021 at 05:30:52PM +0100, Tobias Waldekranz wrote:
> > ---
> > .../ethernet/freescale/dpaa2/dpaa2-switch.c | 4 +-
> > .../marvell/prestera/prestera_switchdev.c | 7 ++
> > .../mellanox/mlxsw/spectrum_switchdev.c | 4 +-
> > drivers/net/ethernet/mscc/ocelot_net.c
On Mon, Mar 22, 2021 at 06:07:51PM +0100, Tobias Waldekranz wrote:
> On Mon, Mar 22, 2021 at 18:19, Vladimir Oltean wrote:
> > On Mon, Mar 22, 2021 at 04:44:41PM +0100, Tobias Waldekranz wrote:
> >> I do not know if it is a problem or not, more of an observation: This is
> >> not guaranteed to be
On Mon, Mar 22, 2021 at 18:19, Vladimir Oltean wrote:
> On Mon, Mar 22, 2021 at 04:44:41PM +0100, Tobias Waldekranz wrote:
>> I do not know if it is a problem or not, more of an observation: This is
>> not guaranteed to be an exact replay of the events that the bridge port
>> (i.e. bond0 or whatev
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> On reception of an skb, the bridge checks if it was marked as 'already
> forwarded in hardware' (checks if skb->offload_fwd_mark == 1), and if it
> is, it puts a mark of its own on that skb, with the switchdev mark
On Mon, Mar 22, 2021 at 04:44:41PM +0100, Tobias Waldekranz wrote:
> I do not know if it is a problem or not, more of an observation: This is
> not guaranteed to be an exact replay of the events that the bridge port
> (i.e. bond0 or whatever) has received since, in fdb_insert, we exit
> early when
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> DSA has gained the recent ability to deal gracefully with upper
> interfaces it cannot offload, such as the bridge, bonding or team
> drivers. When such uppers exist, the ports are still in standalone mode
> as far as the
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The DSA core has a layered structure, and even though we end up
> returning 0 (success) to user space when setting a bonding/team upper
> that can't be offloaded, some parts of the framework actually need to
> know
On 3/20/2021 2:53 AM, Vladimir Oltean wrote:
> On Fri, Mar 19, 2021 at 03:20:38PM -0700, Florian Fainelli wrote:
>>
>>
>> On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
>>> From: Vladimir Oltean
>>>
>>> I have udhcpcd in my system and this is configured to bring interfaces
>>> up as soon as they
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The DSA core has a layered structure, and even though we end up
> returning 0 (success) to user space when setting a bonding/team upper
> that can't be offloaded, some parts of the framework actually need to
> know that w
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> When a DSA port joins a LAG that already had an FDB entry pointing to it:
>
> ip link set bond0 master br0
> bridge fdb add dev bond0 00:01:02:03:04:05 master static
> ip link set swp0 master bond0
>
> the DSA port
On Mon, Mar 22, 2021 at 12:17:33PM +0100, Tobias Waldekranz wrote:
> On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> > From: Vladimir Oltean
> >
> > Make sure that the multicast router setting of the bridge is picked up
> > correctly by DSA when joining, regardless of whether there are
>
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port creation time, so:
> (a) drivers ha
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Make sure that the multicast router setting of the bridge is picked up
> correctly by DSA when joining, regardless of whether there are
> sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port
> att
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> This is the same situation as for other switchdev port attributes: if we
> join an already-created bridge port, such as a bond master interface,
> then we can miss the initial switchdev notification emitted by the
>
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> It may happen that we have the following topology:
>
> ip link add br0 type bridge stp_state 1
> ip link add bond0 type bond
> ip link set bond0 master br0
> ip link set swp0 master bond0
> ip link set swp1 master b
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> This is a pretty noisy change that was broken out of the larger change
> for replaying switchdev attributes and objects at bridge join time,
> which is when these extack objects are actually used.
>
> Signed-off-by:
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> DSA can properly detect and offload this sequence of operations:
>
> ip link add br0 type bridge
> ip link add bond0 type bond
> ip link set swp0 master bond0
> ip link set bond0 master br0
>
> But not this one:
>
>
On Fri, Mar 19, 2021 at 6:49 PM Vladimir Oltean wrote:
> Why would you even want to look at the source net device for forwarding?
> I'd say that if dp->bridge_dev is NULL in the xmit function, you certainly
> want to bypass address learning if you can. Maybe also for link-local traffic.
Also for
From: Jian Shen
For DEVICE_VERSION_V3, the hardware supports to match specified
data in the specified offset of packet payload. Each layer can
have one offset, and can't be masked when configure flow director
rule by ethtool command. The layer is selected based on the
flow-type, ether for L2, ip4
From: Jian Shen
For only PF driver can configure flow director rule, it's
better to call hclge_del_all_fd_entries() directly in hclge
layer, rather than call hns3_del_all_fd_entries() in hns3
layer. Then the ae_algo->ops.del_all_fd_entries can be removed.
Signed-off-by: Jian Shen
Signed-off-by:
From: Jian Shen
Currently, there are too many branches for hclge_fd_convert_tuple().
And it may be more when add new tuples. Refactor it by sorting the
tuples according to their length. So it only needs several KEY_OPT
now, and being flexible to add new tuples.
Signed-off-by: Jian Shen
Signed-o
From: Jian Shen
The process of function hclge_add_fd_entry() is complex and
prolix. To make it more readable, extract the process of
fs->ring_cookie to a single function.
Signed-off-by: Jian Shen
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 67 +
This patchset refactor some functions and add some new features for
flow director.
patch 1~3: refactor large functions
patch 4, 7: add traffic class and user-def field support for ethtool
patch 5: refactor flow director configuration
patch 6: clean up for hns3_del_all_fd_entries()
change log:
V1-
From: Jian Shen
Currently, the flow director rule of aRFS is configured in
the IO path. It's time-consuming. So move out the configuration,
and configure it asynchronously. And keep ethtool and tc flower
rule using synchronous way, otherwise the application maybe
unable to know the rule is instal
From: Jian Shen
The process of function hclge_fd_get_tuple() is complex and
prolix. To make it more readable, extract the process of each
flow-type tuple to a single function.
Signed-off-by: Jian Shen
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 220 +++
From: Jian Shen
The hardware supports to parse and match the traffic class field
of IPv6 packet for flow director, uses the same tuple as ip tos.
So removes the limitation of configure 'tclass' by driver.
Signed-off-by: Jian Shen
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns
On 3/21/21 6:43 AM, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> Currently, MSG_CMSG_COMPAT is defined as '1 << 31'. However, 'msg_flags'
> is defined with type of 'int' somewhere, such as 'packet_recvmsg' and
> other recvmsg functions:
>
> static int packet_recvmsg(struct socket *s
On 3/21/21 6:43 AM, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> The bit mask for MSG_* seems a little confused here. Replace it
> with BIT() to make it clear to understand.
>
> Signed-off-by: Menglong Dong
With this patch sent as patch 1/2, any code trying to bisect
a compat rela
From: Menglong Dong
The bit mask for MSG_* seems a little confused here. Replace it
with BIT() to make it clear to understand.
Signed-off-by: Menglong Dong
---
include/linux/socket.h | 71 ++
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git
From: Menglong Dong
Currently, MSG_CMSG_COMPAT is defined as '1 << 31'. However, 'msg_flags'
is defined with type of 'int' somewhere, such as 'packet_recvmsg' and
other recvmsg functions:
static int packet_recvmsg(struct socket *sock, struct msghdr *msg,
size_t len,
From: Menglong Dong
In the first patch, I use BIT() for MSG_* to make the code tidier.
Directly use BIT() for MSG_* will be a bit problematic, because
'msg_flags' is defined as 'int' somewhere, and MSG_CMSG_COMPAT
will make it become negative, just like what Guenter Roeck
reported here:
https:/
On Fri, Mar 19, 2021 at 03:20:38PM -0700, Florian Fainelli wrote:
>
>
> On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> > From: Vladimir Oltean
> >
> > I have udhcpcd in my system and this is configured to bring interfaces
> > up as soon as they are created.
> >
> > I create a bridge as follows:
>
On Fri, Mar 19, 2021 at 03:08:46PM -0700, Florian Fainelli wrote:
>
>
> On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> > From: Vladimir Oltean
> >
> > DSA currently assumes that the bridge port starts off with this
> > constellation of bridge port flags:
> >
> > - learning on
> > - unicast flo
On Fri, Mar 19, 2021 at 03:13:03PM -0700, Florian Fainelli wrote:
> > diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
> > index 86b5e05d3f21..3dafb6143cff 100644
> > --- a/net/bridge/br_stp.c
> > +++ b/net/bridge/br_stp.c
> > @@ -639,6 +639,19 @@ int br_set_ageing_time(struct net_bridge *br,
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Currently this simple setup:
>
> ip link add br0 type bridge vlan_filtering 1
> ip link add bond0 type bond
> ip link set bond0 master br0
> ip link set swp0 master bond0
>
> will not work because the bridge has created
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> I have udhcpcd in my system and this is configured to bring interfaces
> up as soon as they are created.
>
> I create a bridge as follows:
>
> ip link add br0 type bridge
>
> As soon as I create the bridge and udhcpcd
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port creation time, so:
> (a) drivers had to
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Make sure that the multicast router setting of the bridge is picked up
> correctly by DSA when joining, regardless of whether there are
> sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port
> attribute
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> This is the same situation as for other switchdev port attributes: if we
> join an already-created bridge port, such as a bond master interface,
> then we can miss the initial switchdev notification emitted by the
> bridg
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> It may happen that we have the following topology:
>
> ip link add br0 type bridge stp_state 1
> ip link add bond0 type bond
> ip link set bond0 master br0
> ip link set swp0 master bond0
> ip link set swp1 master bond0
1 - 100 of 6510 matches
Mail list logo
