From: Vladimir Oltean
We'll need to read back the watermark thresholds and occupancy from
hardware (for devlink-sb integration), not only to write them as we did
so far in ocelot_port_set_maxlen. So introduce 2 new functions in struct
ocelot_ops, similar to wm_enc, and implement them for the 3 su
From: Vladimir Oltean
In some applications, it is important to create resource reservations in
the Ethernet switches, to prevent background traffic, or deliberate
attacks, from inducing denial of service into the high-priority traffic.
These patches give the user some knobs to turn. The ocelot s
From: Vladimir Oltean
Switches that care about QoS might have hardware support for reserving
buffer pools for individual ports or traffic classes, and configuring
their sizes and thresholds. Through devlink-sb (shared buffers), this is
all configurable, as well as their occupancy being viewable.
From: Vladimir Oltean
We should be moving anything that isn't DSA-specific or SoC-specific out
of the felix DSA driver, and into the common mscc_ocelot switch library.
The number of traffic classes is one of the aspects that is common
between all ocelot switches, so it belongs in the library.
T
From: Vladimir Oltean
This is meant to be a gentle introduction into the world of watermarks
on ocelot. The code is placed in ocelot_devlink.c because it will be
integrated with devlink, even if it isn't right now.
My first step was intended to be to replicate the default configuration
of the co
From: Vladimir Oltean
Add devlink integration into the mscc_ocelot switchdev driver. Only the
probed interfaces are registered with devlink, because for convenience,
struct devlink_port was included into struct ocelot_port_private, which
is only initialized for the ports that are used.
Since we
From: Vladimir Oltean
In general it is desirable that cleanup is the reverse process of setup.
In this case I am not seeing any particular issue, but with the
introduction of devlink-sb for felix, a non-obvious decision had to be
made as to where to put its cleanup method. When there's a conventi
From: Vladimir Oltean
This is a leftover of commit 69df578c5f4b ("net: mscc: ocelot: eliminate
confusion between CPU and NPI port") which renamed that function.
Signed-off-by: Vladimir Oltean
---
Changes in v3:
None.
Changes in v2:
None.
drivers/net/ethernet/mscc/ocelot.h | 4
1 file ch
From: Vladimir Oltean
The devlink function pointer names are super long, and they would break
the alignment. So reindent the existing ops now by adding one tab.
Signed-off-by: Vladimir Oltean
---
Changes in v3:
None.
Changes in v2:
None.
drivers/net/dsa/ocelot/felix.c | 78 +-
From: Vladimir Oltean
Using devlink-sb, we can configure 12/16 (the important 75%) of the
switch's controlling watermarks for congestion drops, and we can monitor
50% of the watermark occupancies (we can monitor the reservation
watermarks, but not the sharing watermarks, which are exposed as pool
On Fri, Jan 08, 2021 at 07:59:43PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Switches that care about QoS might have hardware support for reserving
> buffer pools for individual ports or traffic classes, and configuring
> their sizes and thresholds. Through devlink-sb (shared buff
Shannon Nelson wrote:
> On 1/6/21 1:55 PM, Jesse Brandeburg wrote:
> > When drivers call the various receive upcalls to receive an skb
> > to the stack, sometimes that stack can drop the packet. The good
> > news is that the return code is given to all the drivers of
> > NET_RX_DROP or GRO_DROP. T
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Instead of reading these values from the reference manual and writing
> them down into the driver, it appears that the hardware gives us the
> option of detecting them dynamically.
>
> The number of frame references corre
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> We'll need to read back the watermark thresholds and occupancy from
> hardware (for devlink-sb integration), not only to write them as we did
> so far in ocelot_port_set_maxlen. So introduce 2 new functions in struct
> oce
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Switches that care about QoS might have hardware support for reserving
> buffer pools for individual ports or traffic classes, and configuring
> their sizes and thresholds. Through devlink-sb (shared buffers), this is
> al
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The devlink function pointer names are super long, and they would break
> the alignment. So reindent the existing ops now by adding one tab.
>
> Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
--
Florian
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> We should be moving anything that isn't DSA-specific or SoC-specific out
> of the felix DSA driver, and into the common mscc_ocelot switch library.
>
> The number of traffic classes is one of the aspects that is common
>
Eric Dumazet wrote:
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6071,6 +6071,7 @@ static gro_result_t napi_skb_finish(struct
> > napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> >
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> This is a leftover of commit 69df578c5f4b ("net: mscc: ocelot: eliminate
> confusion between CPU and NPI port") which renamed that function.
>
> Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
--
Florian
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> In general it is desirable that cleanup is the reverse process of setup.
> In this case I am not seeing any particular issue, but with the
> introduction of devlink-sb for felix, a non-obvious decision had to be
> made as
On 1/8/2021 9:59 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Add devlink integration into the mscc_ocelot switchdev driver. Only the
> probed interfaces are registered with devlink, because for convenience,
> struct devlink_port was included into struct ocelot_port_private, which
>
Quoting Alexander Duyck (2021-01-08 17:33:01)
> On Fri, Jan 8, 2021 at 1:07 AM Antoine Tenart wrote:
> >
> > Quoting Alexander Duyck (2021-01-07 17:38:35)
> > > On Thu, Jan 7, 2021 at 12:54 AM Antoine Tenart wrote:
> > > >
> > > > Quoting Alexander Duyck (2021-01-06 20:54:11)
> > > > > On Wed, Ja
On 1/8/21 10:26 AM, Jesse Brandeburg wrote:
Shannon Nelson wrote:
On 1/6/21 1:55 PM, Jesse Brandeburg wrote:
When drivers call the various receive upcalls to receive an skb
to the stack, sometimes that stack can drop the packet. The good
news is that the return code is given to all the drivers
On Fri, 2021-01-08 at 10:57 +0200, Vladimir Oltean wrote:
> On Thu, Jan 07, 2021 at 07:59:37PM -0800, Saeed Mahameed wrote:
> > On Thu, 2021-01-07 at 13:58 +0100, Eric Dumazet wrote:
> > > On Thu, Jan 7, 2021 at 12:33 PM Vladimir Oltean <
> > > olte...@gmail.com>
> > > wrote:
...
> > >
> > > > T
On Fri, 2021-01-08 at 10:14 +0100, Eric Dumazet wrote:
> On Fri, Jan 8, 2021 at 4:59 AM Saeed Mahameed
> wrote:
> > Eric, about two years ago you were totally against sleeping in
> > ndo_get_stats, what happened ? :)
> > https://lore.kernel.org/netdev/4cc44e85-cb5e-502c-30f3-c6ea564fe...@gmail.com
Eric Dumazet wrote:
> From: Eric Dumazet
>
> napi_gro_receive() can never return GRO_DROP
>
> GRO_DROP can only be returned from napi_gro_frags()
> which is the other NAPI GRO entry point.
>
> Followup patch will remove GRO_DROP, because drivers
> are not supposed to call napi_gro_frags() if p
On Fri, 2021-01-08 at 10:27 +0100, Eric Dumazet wrote:
> On Fri, Jan 8, 2021 at 10:21 AM Vladimir Oltean
> wrote:
> > On Fri, Jan 08, 2021 at 10:14:01AM +0100, Eric Dumazet wrote:
> > > If you disagree, repost a rebased patch series so that we can
> > > test/compare and choose the best solution.
>
ately
Signed-off-by: Aditya Srivastava
---
- The changes made are compile tested
- Applies perfecly on next-20210108
drivers/net/wireless/realtek/rtlwifi/ps.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 8
drivers/net/wireless/realtek/rtlwifi/rtl8
Add comments clarifying that USER variants of CO-RE reading macro are still
only going to work with kernel types, defined in kernel or kernel module BTF.
This should help preventing invalid use of those macro to read user-defined
types (which doesn't work with CO-RE).
Signed-off-by: Andrii Nakryik
KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
power saving mode (backup mode) that cuts the power for almost all
parts of the SoC. The rail powering the ethernet PHY is also cut off.
When resuming, in case the PHY has been configured on probe with
slew rate or DLL settings thes
On 1/7/21 8:38 PM, Jakub Kicinski wrote:
On Thu, 7 Jan 2021 15:43:25 -0600 Alex Elder wrote:
@@ -743,21 +743,21 @@ static void gsi_channel_freeze(struct gsi_channel
*channel)
set_bit(GSI_CHANNEL_FLAG_STOPPING, channel->flags);
smp_mb__after_atomic(); /* Ensure gsi_channel_poll(
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Tue, 5 Jan 2021 07:20:47 -0800 you wrote:
> From: Menglong Dong
>
> 'unistd.h' included in 'selftests/bpf/prog_tests/test_lsm.c' is
> duplicated.
>
> Signed-off-by: Menglong Dong
>
> [...]
Here is the summary with li
On Fri, Jan 08, 2021 at 11:38:57AM -0800, Saeed Mahameed wrote:
> Let me take a look at the current series, and if I see that the
> rcu/dev_hold approach is more lightweight then i will suggest it to
> Vladimir and he can make the final decision.
The last version does use temporary RCU protection.
On Fri, 2021-01-08 at 11:21 -0800, Shannon Nelson wrote:
> On 1/8/21 10:26 AM, Jesse Brandeburg wrote:
> > Shannon Nelson wrote:
> >
> > > On 1/6/21 1:55 PM, Jesse Brandeburg wrote:
> > > > When drivers call the various receive upcalls to receive an skb
> > > > to the stack, sometimes that stack c
The pull request you sent on Thu, 7 Jan 2021 21:00:59 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> tags/net-5.11-rc3-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6279d812eab67a6df6b22fa495201db6f2305924
Thank you!
--
Deet-doot-dot, I
Hi,
this patch resolves an issue with my Lenovo USB-C Hub with an
integrated Realtek USB Ethernet controller.
When suspending my host system, along with an active Ethernet link
using the Realtek USB Ethernet adapter on a somewhat busy network,
after a few minutes the NIC would start to constantly
This USB-C Hub (17ef:721e) based on the Realtek RTL8153B chip used to
work with the cdc_ether driver. However, using this driver, with the
system suspended the device sends pause-frames as soon as the receive
buffer fills up. This produced substantial network load, up to the
point where some Ethern
On Fri, Jan 08, 2021 at 10:33:19AM +0100, Dmitry Vyukov wrote:
> On Thu, Jan 7, 2021 at 8:06 PM Jeffrey Walton wrote:
> >
> > On Thu, Jan 7, 2021 at 2:03 PM Jason A. Donenfeld wrote:
> > >
> > > On Thu, Jan 7, 2021 at 1:22 PM Dmitry Vyukov wrote:
> > > >
> > > > On Mon, Dec 21, 2020 at 12:23 PM
On Thu, Jan 07, 2021 at 06:13:15PM +, Tom Parkin wrote:
> When setting up a channel bridge, ppp_bridge_channels sets the
> pch->bridge field before taking the associated reference on the bridge
> file instance.
>
> This opens up a refcount underflow bug if ppp_bridge_channels called
> via. iot
On Fri, Jan 08, 2021 at 03:02:52PM -0500, Brian Silverman wrote:
> Thanks for the responses - I now have a more clear picture of what's going on.
> (Note: I'm using Xilinx's 2019.2 kernel (based off 4.19). I believe it would
> be similar to latest kernels, but I could be wrong.)
Hi Brian
macb_m
On Thu, Jan 07, 2021 at 10:54:38PM -0500, Don Dutile wrote:
> On 1/7/21 7:57 PM, Bjorn Helgaas wrote:
> > On Sun, Jan 03, 2021 at 10:24:37AM +0200, Leon Romanovsky wrote:
> > > + **/
> > > +int pci_set_msix_vec_count(struct pci_dev *dev, int numb)
> > > +{
> > > + struct pci_dev *pdev = pci_physfn
On Fri, Jan 8, 2021 at 4:41 PM Eric Dumazet wrote:
>
> On Fri, Jan 8, 2021 at 2:51 PM Sedat Dilek wrote:
> >
> > On Fri, Jan 8, 2021 at 2:08 PM Sedat Dilek wrote:
> > >
> > > On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
> > >
> > > > > Also, I tried the diff for tcp_conn_request...
> > >
Hi,
On Thu, Jan 07, 2021 at 09:30:47PM -0800, Saeed Mahameed wrote:
> From: Roi Dayan
>
> Connection tracking associates the connection state per packet. The
> first packet of a connection is assigned with the +trk+new state. The
> connection enters the established state once a packet is seen on
TLS selftests where broken because of wrong variable types used.
Fix it by changing u16 -> uint16_t
Fixes: 4f336e88a870 ("selftests/tls: add CHACHA20-POLY1305 to tls selftests")
Reported-by: kernel test robot
Signed-off-by: Vadim Fedorenko
---
tools/testing/selftests/net/tls.c | 4 ++--
1 file
From: Marc Kleine-Budde
> Sent: 07 January 2021 21:17
>
> On 1/7/21 8:06 PM, Jakub Kicinski wrote:
> > On Thu, 7 Jan 2021 11:00:35 -0800 Jakub Kicinski wrote:
> >> On Thu, 7 Jan 2021 10:48:56 +0100 Marc Kleine-Budde wrote:
> >>> +struct __packed tcan4x5x_map_buf {
> >>> + struct tcan4x5x_buf_cmd
On Thu, Jan 7, 2021 at 5:23 AM Song Liu wrote:
>
> task_file and task_vma iter programs have access to file->f_path. Enable
> bpf_d_path to print paths of these file.
>
> bpf_iter programs are generally called in sleepable context. However, it
> is still necessary to diffientiate sleepable and non
Hi,
On Thu, Jan 07, 2021 at 09:30:48PM -0800, Saeed Mahameed wrote:
> @@ -1429,6 +1600,14 @@ mlx5_tc_ct_add_ft_cb(struct mlx5_tc_ct_priv *ct_priv,
> u16 zone,
> if (err)
> goto err_insert;
>
> + nf_ct_zone_init(&ctzone, zone, NF_CT_DEFAULT_ZONE_DIR, 0);
> + ft->tmpl
On Fri, Jan 8, 2021 at 10:58 AM Antoine Tenart wrote:
>
> Quoting Alexander Duyck (2021-01-08 17:33:01)
> > On Fri, Jan 8, 2021 at 1:07 AM Antoine Tenart wrote:
> > >
> > > Quoting Alexander Duyck (2021-01-07 17:38:35)
> > > > On Thu, Jan 7, 2021 at 12:54 AM Antoine Tenart
> > > > wrote:
> > >
Add support for using kernel module global variables (__ksym externs in BPF
program). BPF verifier will now support ldimm64 with src_reg=BPF_PSEUDO_BTF_ID
and non-zero insn[1].imm field, specifying module BTF's FD. In such case,
module BTF object, similarly to BPF maps referenced from ldimm64 with
__bpf_free_used_maps() is always defined in kernel/bpf/core.c, while
include/linux/bpf.h is guarding it behind CONFIG_BPF_SYSCALL. Move it out of
that guard region and fix compiler warning.
Reported-by: kernel test robot
Fixes: a2ea07465c8d ("bpf: Fix missing prog untrack in release_maps")
Signed
BPF interpreter uses extra input argument, so re-casts __bpf_call_base into
__bpf_call_base_args. Avoid compiler warning about incompatible function
prototypes by casting to void * first.
Reported-by: kernel test robot
Fixes: 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
Signed-of
If some of the subtests use module BTFs through ksyms, they will cause
bpf_prog to take a refcount on bpf_testmod module, which will prevent it from
successfully unloading. Module's refcnt is decremented when bpf_prog is freed,
which generally happens in RCU callback. So we need to trigger
syncroni
Add support for directly accessing kernel module variables from BPF programs
using special ldimm64 instructions. This functionality builds upon vmlinux
ksym support, but extends ldimm64 with src_reg=BPF_PSEUDO_BTF_ID to allow
specifying kernel module BTF's FD in insn[1].imm field.
During BPF progr
Add support for searching for ksym externs not just in vmlinux BTF, but across
all module BTFs, similarly to how it's done for CO-RE relocations. Kernels
that expose module BTFs through sysfs are assumed to support new ldimm64
instruction extension with BTF FD provided in insn[1].imm field, so no e
Add per-CPU variable to bpf_testmod.ko and use those from new selftest to
validate it works end-to-end.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/bpf_testmod/bpf_testmod.c | 3 ++
.../selftests/bpf/prog_tests/ksyms_module.c | 33 +++
.../selftests/bpf/progs/test_k
Add bpf_patch_call_args() prototype. This function is called from BPF verifier
and only if CONFIG_BPF_JIT_ALWAYS_ON is not defined. This fixes compiler
warning about missing prototype in some kernel configurations.
Reported-by: kernel test robot
Fixes: 1ea47e01ad6e ("bpf: add support for bpf_call
On 1/8/2021 1:04 PM, Andrew Lunn wrote:
> On Fri, Jan 08, 2021 at 03:02:52PM -0500, Brian Silverman wrote:
>> Thanks for the responses - I now have a more clear picture of what's going
>> on.
>> (Note: I'm using Xilinx's 2019.2 kernel (based off 4.19). I believe it
>> would
>> be similar to
On 1/7/2021 10:00 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> UniMAC is integrated into multiple Broadcom's Ethernet controllers so
> use a shared header file for it and avoid some code duplication.
>
> Signed-off-by: Rafał Miłecki
> Acked-by: Florian Fainelli
> ---
> V2: Open code (n <
On 1/7/21 3:16 AM, Gary Lin wrote:
The x64 bpf jit expects bpf images converge within the given passes, but
it could fail to do so with some corner cases. For example:
l0: ja 40
l1: ja 40
[... repeated ja 40 ]
l39:ja 40
l40:ret #0
This bpf
Thanks - I will have to keep a local patch to fix this for my needs
for the time being.
If in the future if I'm able to do something better (e.g. with a
better fw_devlink, which looks interesting), I'll post a patch. But I
generally lag the latest kernels by a couple years, so... not any
time so
Quoting Alexander Duyck (2021-01-08 23:04:57)
> On Fri, Jan 8, 2021 at 10:58 AM Antoine Tenart wrote:
> >
> > Quoting Alexander Duyck (2021-01-08 17:33:01)
> > > On Fri, Jan 8, 2021 at 1:07 AM Antoine Tenart wrote:
> > > >
> > > > Quoting Alexander Duyck (2021-01-07 17:38:35)
> > > > > On Thu, Ja
From: Vladimir Oltean
Introduced in commit 37b8da1a3c68 ("net: dsa: Move FDB add/del
implementation inside DSA") in net/dsa/legacy.c, these functions were
moved again to slave.c as part of commit 2a93c1a3651f ("net: dsa: Allow
compiling out legacy support"), before actually deleting net/dsa/slave
On Fri, Jan 8, 2021 at 12:11 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> skb_seq_read iterates over an skb, returning pointer and length of
> the next data range with each call.
>
> It relies on kmap_atomic to access highmem pages when needed.
>
> An skb frag may be backed by a comp
From: Vladimir Oltean
Changes in v4:
- Fixed build error in dsa_loop and build warning in hellcreek driver.
- Scheduling the mlxsw SPAN work item regardless of the VLAN add return
code, as per Ido's and Petr's request.
Changes in v3:
- Resolved a build warning in mv88e6xxx and tested that it a
From: Vladimir Oltean
Since the introduction of the switchdev API, port objects were
transmitted to drivers for offloading using a two-step transactional
model, with a prepare phase that was supposed to catch all errors, and a
commit phase that was supposed to never fail.
Some classes of failure
From: Vladimir Oltean
mv88e6xxx apparently has a problem offloading VID 0, which the 8021q
module tries to install as part of commit ad1afb003939 ("vlan_dev: VLAN
0 should be treated as "no vlan tag" (802.1p packet)"). That mv88e6xxx
restriction seems to have been introduced by the "VTU GetNext V
From: Vladimir Oltean
Remove the shim introduced in DSA for offloading the bridge ageing time
from switchdev, by first checking whether the ageing time is within the
range limits requested by the driver.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Acked-by: Linus Walleij
Acke
From: Vladimir Oltean
After the removal of the transactional model inside
switchdev_port_obj_add_now, it has no added value and we can just call
switchdev_port_obj_notify directly, bypassing this function. Let's
delete it.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Reviewed-b
From: Vladimir Oltean
For many drivers, the .port_mdb_prepare callback was not a good opportunity
to avoid any error condition, and they would suppress errors found during
the actual commit phase.
Where a logical separation between the prepare and the commit phase
existed, the function that used
From: Vladimir Oltean
Since the introduction of the switchdev API, port attributes were
transmitted to drivers for offloading using a two-step transactional
model, with a prepare phase that was supposed to catch all errors, and a
commit phase that was supposed to never fail.
Some classes of fail
From: Vladimir Oltean
Now that all port object notifiers were converted to be non-transactional,
we can remove the comments that say otherwise.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Acked-by: Linus Walleij
Acked-by: Jiri Pirko
---
Changes in v4:
None.
Changes in v3:
N
From: Vladimir Oltean
Now that all users of struct switchdev_trans have been modified to do
without it, we can remove this structure and the two helpers to determine
the phase.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Reviewed-by: Ido Schimmel
Acked-by: Linus Walleij
Acke
From: Vladimir Oltean
It should be the driver's business to logically separate its VLAN
offloading into a preparation and a commit phase, and some drivers don't
need / can't do this.
So remove the transactional shim from DSA and let drivers propagate
errors directly from the .port_vlan_add callb
From: Vladimir Oltean
As of commit 457e20d65924 ("mlxsw: spectrum_switchdev: Avoid returning
errors in commit phase"), the mlxsw driver performs the VLAN object
offloading during the prepare phase. So conversion just seems to be a
matter of removing the code that was running in the commit phase.
From: Vladimir Oltean
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| |br_afspec |
| || |
| |
On Fri, Jan 08, 2021 at 06:32:28AM +0100, Oleksij Rempel wrote:
> May be the "net: dsa: add optional stats64 support" can already be
> taken?
I'm not sure that I see the point. David and Jakub won't cherry-pick
partial series, and if you resend just patch 1/2, they won't accept new
code that doesn
On Fri, Jan 08, 2021 at 02:11:31PM -0800, Florian Fainelli wrote:
>
>
> On 1/8/2021 1:04 PM, Andrew Lunn wrote:
> > On Fri, Jan 08, 2021 at 03:02:52PM -0500, Brian Silverman wrote:
> >> Thanks for the responses - I now have a more clear picture of what's going
> >> on.
> >> (Note: I'm using Xil
On Sat, Jan 09, 2021 at 01:30:54AM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Introduced in commit 37b8da1a3c68 ("net: dsa: Move FDB add/del
> implementation inside DSA") in net/dsa/legacy.c, these functions were
> moved again to slave.c as part of commit 2a93c1a3651f ("net: dsa: A
On Fri, Jan 08, 2021 at 02:11:31PM -0800, Florian Fainelli wrote:
> On 1/8/2021 1:04 PM, Andrew Lunn wrote:
> > On Fri, Jan 08, 2021 at 03:02:52PM -0500, Brian Silverman wrote:
> >> Thanks for the responses - I now have a more clear picture of what's going
> >> on.
> >> (Note: I'm using Xilinx's
From: Geliang Tang
This patch added the set_flags command in pm_nl_ctl, currently we can only
set two flags: backup and nobackup. The set_flags command can be used like
this:
# pm_nl_ctl set 10.0.0.1 flags backup
# pm_nl_ctl set 10.0.0.1 flags nobackup
Signed-off-by: Geliang Tang
Signed-off-
From: Geliang Tang
This patch added the mibs for MP_PRIO, MPTCP_MIB_MPPRIOTX for transmitting
of the MP_PRIO suboption, and MPTCP_MIB_MPPRIORX for receiving of it.
Signed-off-by: Geliang Tang
Signed-off-by: Mat Martineau
---
net/mptcp/mib.c| 2 ++
net/mptcp/mib.h| 2 ++
net/mp
From: Geliang Tang
This patch added the incoming MP_PRIO logic:
Added a flag named mp_prio in struct mptcp_options_received, to mark the
MP_PRIO is received, and save the priority value to struct
mptcp_options_received's backup member. Then invoke
mptcp_pm_mp_prio_received with the receiving sub
Here are some patches we've merged in the MPTCP tree that are ready for
net-next.
Patches 1 and 2 rework the assignment of local address IDs to allow them
to be assigned by a userspace path manager, and add corresponding self
tests.
Patches 2-8 add the ability to change subflow priority after a s
From: Geliang Tang
Currently the address ID set by the netlink PM from user-space is
overridden by the kernel. This patch added the address ID assignment
bitmap to allow user-space to set the address ID.
Use a per netns bitmask id_bitmap (256 bits) to keep track of in-use IDs.
And use next_id to
From: Geliang Tang
This patch added the outgoing MP_PRIO logic:
In mptcp_pm_nl_mp_prio_send_ack, find the related subflow and subsocket
according to the input parameter addr. Save the input priority value to
suflow's backup, then set subflow's send_mp_prio flag to true, and save
the input priori
From: Geliang Tang
This patch added the MP_PRIO testcases:
Add a new argument bkup for run_tests and do_transfer, it can be set as
"backup" or "nobackup", the default value is "".
Add a new function chk_prio_nr to check the MP_PRIO related MIB counters.
The output looks like this:
29 single s
From: Geliang Tang
This patch added a new command MPTCP_PM_CMD_SET_FLAGS in PM netlink:
In mptcp_nl_cmd_set_flags, parse the input address, get the backup value
according to whether the address's FLAG_BACKUP flag is set from the
user-space. Then check whether this address had been added in the l
From: Geliang Tang
Since the address ID can be set from user-space, some of the tests in
pm_netlink.sh will fail. This patch fixed the failures, and add the
testcases for setting the address ID.
Signed-off-by: Geliang Tang
Signed-off-by: Mat Martineau
---
.../testing/selftests/net/mptcp/pm_ne
From: Long Li
This patch set fixes issues with packet loss on VF add/remove.
Long Li (3):
hv_netvsc: Check VF datapath when sending traffic to VF
hv_netvsc: Wait for completion on request SWITCH_DATA_PATH
hv_netvsc: Process NETDEV_GOING_DOWN on VF hot remove
drivers/net/hyperv/netvsc.c
From: Long Li
The driver needs to check if the datapath has been switched to VF before
sending traffic to VF.
Signed-off-by: Long Li
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/netvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_d
From: Long Li
On VF hot remove, NETDEV_GOING_DOWN is sent to notify the VF is about to
go down. At this time, the VF is still sending/receiving traffic and we
request the VSP to switch datapath.
On completion, the datapath is switched to synthetic and we can proceed
with VF hot remove.
Signed-o
From: Long Li
The completion indicates if NVSP_MSG4_TYPE_SWITCH_DATA_PATH has been
processed by the VSP. The traffic is steered to VF or synthetic after we
receive this completion.
Signed-off-by: Long Li
Reported-by: kernel test robot
---
Change from v1:
Fixed warnings from kernel test robot.
On 1/6/2021 5:45 AM, Vladimir Oltean wrote:
> On Tue, Jan 05, 2021 at 08:58:50PM +0200, Vladimir Oltean wrote:
>> This is marked as Request For Comments for a reason.
>
> If nobody has any objections, I will remove the memory leaks I
> introduced to check if anybody is paying attention, and I w
On Fri, Jan 08, 2021 at 01:02:21PM -0800, Stanislav Fomichev wrote:
> Add custom implementation of getsockopt hook for TCP_ZEROCOPY_RECEIVE.
> We skip generic hooks for TCP_ZEROCOPY_RECEIVE and have a custom
> call in do_tcp_getsockopt using the on-stack data. This removes
> 3% overhead for locking
Sparse says that you...
On Fri, 8 Jan 2021 18:31:58 +0200 Vladimir Oltean wrote:
> + rcu_read_lock();
> +
> + bond_for_each_slave_rcu(bond, slave, iter) {
> + struct bonding_slave_dev *s;
> +
> + s = kzalloc(sizeof(*s), GFP_ATOMIC);
> + if (!s) {
> +
On 1/8/2021 3:30 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Introduced in commit 37b8da1a3c68 ("net: dsa: Move FDB add/del
> implementation inside DSA") in net/dsa/legacy.c, these functions were
> moved again to slave.c as part of commit 2a93c1a3651f ("net: dsa: Allow
> compiling o
On 1/8/2021 4:01 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> As of commit 457e20d65924 ("mlxsw: spectrum_switchdev: Avoid returning
> errors in commit phase"), the mlxsw driver performs the VLAN object
> offloading during the prepare phase. So conversion just seems to be a
> matter
On 1/8/2021 4:01 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Since the introduction of the switchdev API, port attributes were
> transmitted to drivers for offloading using a two-step transactional
> model, with a prepare phase that was supposed to catch all errors, and a
> commit p
On Fri, Jan 08, 2021 at 01:02:22PM -0800, Stanislav Fomichev wrote:
> When we attach a bpf program to cgroup/getsockopt any other getsockopt()
> syscall starts incurring kzalloc/kfree cost.
>
> Let add a small buffer on the stack and use it for small (majority)
> {s,g}etsockopt values. The buffer
On Fri, 8 Jan 2021 23:29:14 +0530 Ayush Sawal wrote:
> +void chtls_set_quiesce_ctrl(struct sock *sk, int val)
> +{
> + struct chtls_sock *csk;
> + struct sk_buff *skb;
> + unsigned int wrlen;
> + unsigned int len;
> + int ret;
> +
> + wrlen = sizeof(struct cpl_set_tcb_field
101 - 200 of 224 matches
Mail list logo
