* [PATCH v4 3/3] Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
From: Matthias Kaehlcke @ 2019-02-19 20:05 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, linux-kernel, netdev, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <20190219200559.13079-1-mka@chromium.org>
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
---
Changes in v4:
-none
Changes in v3:
- none
Changes in v2:
- patch added to the series
---
drivers/bluetooth/hci_qca.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 5e03504c4e0ca..26efc2ef98d9a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1192,6 +1192,7 @@ static int qca_setup(struct hci_uart *hu)
* setup for every hci up.
*/
set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks);
+ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
hu->hdev->shutdown = qca_power_off;
ret = qca_wcn3990_init(hu);
if (ret)
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Vivien Didelot @ 2019-02-19 19:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
netdev
In-Reply-To: <20190219191016.u65vvw5y3iydt5zx@shell.armlinux.org.uk>
Hi Russell,
On Tue, 19 Feb 2019 19:10:16 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> > True, let's stick with ops->port_egress_flood(ds, port, bool uc, bool mc).
> > I do not think that it is necessary to add support for BR_BCAST_FLOOD yet,
> > we can extend this routine later if we need to.
> >
> > Your dsa_port_bridge_flags() core function can notify the understood
> > features. This will allow us to scope the support of the bridge flags in
> > the core, and preventing the drivers to do that themselves.
>
> So, if we have ops->port_egress_flood, then we tell bridge that
> we support BR_FLOOD | BR_MCAST_FLOOD, irrespective of whether the
> bridge actually supports both?
I would say so yes. If a driver implements port_egress_flood(), this means
its switch device supports both BR_FLOOD | BR_MCAST_FLOOD.
I have one concern though. The documentation of mcast_flood for bridge(8)
says that this flag "controls whether a given port will *be flooded* with
[unknown] multicast traffic". From this I understand allowing this port to
*receive* frames with unknown destination addresses. But with mv88e6xxx, we
program whether the port is allowed to egress a frame that has an unknown
destination address. Otherwise, it will not go out this port.
Am I mistaken? If I understood correctly, is it safe to assume it is the
same thing we are implementing here?
Thanks,
Vivien
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-19 19:41 UTC (permalink / raw)
To: Jose Abreu, Martin Blumenstingl
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <fa35fb4a-b9d5-9bbb-437d-47e8819d0f27@synopsys.com>
Am 19.02.2019 um 09:47 schrieb Jose Abreu:
> Hi Simon,
>
> On 2/18/2019 6:05 PM, Simon Huelck wrote:
>> disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ),
>> the results are the same. I can confirm the LPI counters are zero or one
>> only after the test.....
> It's interesting to see that you have a lot of RX packets but few
> RX interrupts. This can either be due to mis-configuration of
> interrupt flags or RX Watchdog.
>
> 1. For interrupt flags you should be using LEVEL triggered IRQ.
> 2. For RX Watchdog you can try disabling it by adding the
> following in your platform wrapper driver (which will be
> "dwmac-meson8b.c", at probe):
> "plat_data->force_sf_dma_mode = 1;" and
> "plat_data->riwt_off = 1;"
>
> Thanks,
> Jose Miguel Abreu
Hi,
are you aware that odroid c2 dts is using level irq ?
at which numbers do you estimage that RX irqs are low in numbers ?
regards,
Simon
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Florian Fainelli @ 2019-02-19 19:37 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Vivien Didelot
Cc: Andrew Lunn, Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <20190219191016.u65vvw5y3iydt5zx@shell.armlinux.org.uk>
On 2/19/19 11:10 AM, Russell King - ARM Linux admin wrote:
> On Tue, Feb 19, 2019 at 02:04:44PM -0500, Vivien Didelot wrote:
>> Hi Russell,
>>
>> On Tue, 19 Feb 2019 18:08:11 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
>>> Having these as separate functions means that we would then need
>>> additional complexity in mv88e6xxx to store the per-port flooding state,
>>> so we can do this:
>>>
>>> reg &= ~MV88E6352_PORT_CTL0_EGRESS_FLOODS_MASK;
>>>
>>> if (unicast && multicast)
>>> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_ALL_UNKNOWN_DA;
>>> else if (unicast)
>>> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_MC_DA;
>>> else if (multicast)
>>> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_UC_DA;
>>> else
>>> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_DA;
>>>
>>> for some of the switches. It looks to me like mv88e6xxx would prefer
>>> having at least both the unicast and multicast flags together.
>>>
>>> Even without that, it means more code in mv88e6xxx to wrap each of
>>> these calls between the DSA ops and the chip specific ops...
>>
>> True, let's stick with ops->port_egress_flood(ds, port, bool uc, bool mc).
>> I do not think that it is necessary to add support for BR_BCAST_FLOOD yet,
>> we can extend this routine later if we need to.
>>
>> Your dsa_port_bridge_flags() core function can notify the understood
>> features. This will allow us to scope the support of the bridge flags in
>> the core, and preventing the drivers to do that themselves.
>
> So, if we have ops->port_egress_flood, then we tell bridge that
> we support BR_FLOOD | BR_MCAST_FLOOD, irrespective of whether the
> bridge actually supports both?
I have a patch series which removes the need for BRIDGE_FLAGS_SUPPORT
and requires you to implement an attribute setter for PRE_BRIDGE_FLAGS,
there, you can map that to the same DSA switch operations and check the
flags and deny one or both that the driver does not support.
Should I re-send it and you submit on top, or the other way around?
Either way is fine, just tell me.
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: add skb->queue_mapping write access from tc clsact
From: Jesper Dangaard Brouer @ 2019-02-19 19:36 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, Daniel Borkmann, Alexei Starovoitov, brouer
In-Reply-To: <df9f511a-6b91-2808-4f71-5342918afa33@iogearbox.net>
On Tue, 19 Feb 2019 17:18:30 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Untested / uncompiled, but should be:
>
> case offsetof(struct __sk_buff, queue_mapping):
> if (type == BPF_WRITE) {
> *insn++ = BPF_JMP_IMM(BPF_JGE, si->src_reg, NO_QUEUE_MAPPING, 1);
> *insn++ = BPF_STX_MEM(BPF_H, si->dst_reg, si->src_reg,
> bpf_target_off(struct sk_buff, queue_mapping, 2,
> target_size));
> } else {
> *insn++ = BPF_LDX_MEM(BPF_H, si->dst_reg, si->src_reg,
> bpf_target_off(struct sk_buff, queue_mapping, 2,
> target_size));
> }
> break;
In-cooperated in V2 and tested.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Russell King - ARM Linux admin @ 2019-02-19 19:10 UTC (permalink / raw)
To: Vivien Didelot
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
netdev
In-Reply-To: <20190219140444.GD16594@t480s.localdomain>
On Tue, Feb 19, 2019 at 02:04:44PM -0500, Vivien Didelot wrote:
> Hi Russell,
>
> On Tue, 19 Feb 2019 18:08:11 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> > Having these as separate functions means that we would then need
> > additional complexity in mv88e6xxx to store the per-port flooding state,
> > so we can do this:
> >
> > reg &= ~MV88E6352_PORT_CTL0_EGRESS_FLOODS_MASK;
> >
> > if (unicast && multicast)
> > reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_ALL_UNKNOWN_DA;
> > else if (unicast)
> > reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_MC_DA;
> > else if (multicast)
> > reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_UC_DA;
> > else
> > reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_DA;
> >
> > for some of the switches. It looks to me like mv88e6xxx would prefer
> > having at least both the unicast and multicast flags together.
> >
> > Even without that, it means more code in mv88e6xxx to wrap each of
> > these calls between the DSA ops and the chip specific ops...
>
> True, let's stick with ops->port_egress_flood(ds, port, bool uc, bool mc).
> I do not think that it is necessary to add support for BR_BCAST_FLOOD yet,
> we can extend this routine later if we need to.
>
> Your dsa_port_bridge_flags() core function can notify the understood
> features. This will allow us to scope the support of the bridge flags in
> the core, and preventing the drivers to do that themselves.
So, if we have ops->port_egress_flood, then we tell bridge that
we support BR_FLOOD | BR_MCAST_FLOOD, irrespective of whether the
bridge actually supports both?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH RESEND 0/3] Add quirk for reading BD_ADDR from fwnode property
From: Matthias Kaehlcke @ 2019-02-19 19:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Johan Hedberg, David S. Miller, Loic Poulain, linux-bluetooth,
linux-kernel, netdev, Balakrishna Godavarthi
In-Reply-To: <D45CF782-148F-4076-911B-50AC28718701@holtmann.org>
Hi Marcel,
On Mon, Feb 18, 2019 at 11:48:21AM +0100, Marcel Holtmann wrote:
> Hi Matthias,
>
> > [initial post: https://lore.kernel.org/patchwork/cover/1028184/]
> >
> > On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
> > on the Bluetooth chip itself. One way to configure the address is
> > through the device tree (patched in by the bootloader). The btqcomsmd
> > driver is an example, it can read the address from the DT property
> > 'local-bd-address'.
> >
> > To avoid redundant open-coded reading of 'local-bd-address' and error
> > handling this series adds the quirk HCI_QUIRK_USE_BDADDR_PROPERTY to
> > retrieve the BD address of a device from the DT and adapts the
> > btqcomsmd and hci_qca drivers to use this quirk.
> >
> > Matthias Kaehlcke (3):
> > Bluetooth: Add quirk for reading BD_ADDR from fwnode property
> > Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
> > Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
> >
> > drivers/bluetooth/btqcomsmd.c | 29 +++--------------------
> > drivers/bluetooth/hci_qca.c | 1 +
> > include/net/bluetooth/hci.h | 12 ++++++++++
> > net/bluetooth/hci_core.c | 43 +++++++++++++++++++++++++++++++++++
> > net/bluetooth/mgmt.c | 6 +++--
> > 5 files changed, 63 insertions(+), 28 deletions(-)
>
> I am getting compiler warnings when trying to apply this set:
>
> CC drivers/bluetooth/btqcomsmd.o
> drivers/bluetooth/btqcomsmd.c: In function ‘btqcomsmd_setup’:
> drivers/bluetooth/btqcomsmd.c:120:6: warning: unused variable ‘err’ [-Wunused-variable]
> int err;
> ^~~
> drivers/bluetooth/btqcomsmd.c:118:20: warning: unused variable ‘btq’ [-Wunused-variable]
> struct btqcomsmd *btq = hci_get_drvdata(hdev);
> ^~~
Sorry, I missed that the variables aren't used anymore. I'll send a
new version soon.
Thanks
Matthias
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: Use div64_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Nick Desaulniers @ 2019-02-19 19:05 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, linux-wireless, netdev, LKML
In-Reply-To: <20190219182105.19933-1-natechancellor@gmail.com>
On Tue, Feb 19, 2019 at 10:21 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Clang warns:
>
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning:
> comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long
> long *') and 'uint64_t *' (aka 'unsigned long long *'))
> [-Wcompare-distinct-pointer-types]
> do_div(rtt_avg, 6666);
> ^~~~~~~~~~~~~~~~~~~~~
> include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
> 1 warning generated.
>
> do_div expects an unsigned dividend. Use div64_s64, which expects a
> signed dividend.
Eh, IIRC, signed vs unsigned division has implications for rounding
towards zero or not, but I doubt that the round trip time average (RTT
avg) should ever be negative. General rule of thumb for C is to keep
arithmetic signed (even when working with non zero values), so rather
than make the literal (6666) a unsigned long, I agree with your change
to keep the division signed as well. Thanks for the fix.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
> Link: https://github.com/ClangBuiltLinux/linux/issues/372
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> index e9822a3ec373..92b22250eb7d 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> @@ -462,7 +462,7 @@ static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm, u8 index,
> {
> s64 rtt_avg = res->ftm.rtt_avg * 100;
>
> - do_div(rtt_avg, 6666);
> + div64_s64(rtt_avg, 6666);
>
> IWL_DEBUG_INFO(mvm, "entry %d\n", index);
> IWL_DEBUG_INFO(mvm, "\tstatus: %d\n", res->status);
> --
> 2.21.0.rc1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Vivien Didelot @ 2019-02-19 19:04 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
netdev
In-Reply-To: <20190219180811.qxsu2ss3g7jwhgfb@shell.armlinux.org.uk>
Hi Russell,
On Tue, 19 Feb 2019 18:08:11 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> Having these as separate functions means that we would then need
> additional complexity in mv88e6xxx to store the per-port flooding state,
> so we can do this:
>
> reg &= ~MV88E6352_PORT_CTL0_EGRESS_FLOODS_MASK;
>
> if (unicast && multicast)
> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_ALL_UNKNOWN_DA;
> else if (unicast)
> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_MC_DA;
> else if (multicast)
> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_UC_DA;
> else
> reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_DA;
>
> for some of the switches. It looks to me like mv88e6xxx would prefer
> having at least both the unicast and multicast flags together.
>
> Even without that, it means more code in mv88e6xxx to wrap each of
> these calls between the DSA ops and the chip specific ops...
True, let's stick with ops->port_egress_flood(ds, port, bool uc, bool mc).
I do not think that it is necessary to add support for BR_BCAST_FLOOD yet,
we can extend this routine later if we need to.
Your dsa_port_bridge_flags() core function can notify the understood
features. This will allow us to scope the support of the bridge flags in
the core, and preventing the drivers to do that themselves.
Thanks,
Vivien
^ permalink raw reply
* [PATCH bpf-next] bpf/test_run: fix unkillable BPF_PROG_TEST_RUN for flow dissector
From: Stanislav Fomichev @ 2019-02-19 18:54 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev, syzbot
Syzbot found out that running BPF_PROG_TEST_RUN with repeat=0xffffffff
makes process unkillable. The problem is that when CONFIG_PREEMPT is
enabled, we never see need_resched() return true. This is due to the
fact that preempt_enable() (which we do in bpf_test_run_one on each
iteration) now handles resched if it's needed.
Let's disable preemption for the whole run, not per test. In this case
we can properly see whether resched is needed.
Let's also properly return -EINTR to the userspace in case of a signal
interrupt.
This is a follow up for a recently fixed issue in bpf_test_run, see
commit df1a2cb7c74b ("bpf/test_run: fix unkillable
BPF_PROG_TEST_RUN").
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
net/bpf/test_run.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index 2c5172b33209..619655db8d9e 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -293,31 +293,45 @@ int bpf_prog_test_run_flow_dissector(struct bpf_prog *prog,
if (!repeat)
repeat = 1;
+ rcu_read_lock();
+ preempt_disable();
time_start = ktime_get_ns();
for (i = 0; i < repeat; i++) {
- preempt_disable();
- rcu_read_lock();
retval = __skb_flow_bpf_dissect(prog, skb,
&flow_keys_dissector,
&flow_keys);
- rcu_read_unlock();
- preempt_enable();
+
+ if (signal_pending(current)) {
+ preempt_enable();
+ rcu_read_unlock();
+
+ ret = -EINTR;
+ goto out;
+ }
if (need_resched()) {
- if (signal_pending(current))
- break;
time_spent += ktime_get_ns() - time_start;
+ preempt_enable();
+ rcu_read_unlock();
+
cond_resched();
+
+ rcu_read_lock();
+ preempt_disable();
time_start = ktime_get_ns();
}
}
time_spent += ktime_get_ns() - time_start;
+ preempt_enable();
+ rcu_read_unlock();
+
do_div(time_spent, repeat);
duration = time_spent > U32_MAX ? U32_MAX : (u32)time_spent;
ret = bpf_test_finish(kattr, uattr, &flow_keys, sizeof(flow_keys),
retval, duration);
+out:
kfree_skb(skb);
kfree(sk);
return ret;
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* [PATCH bpf-next V2] bpf: add skb->queue_mapping write access from tc clsact
From: Jesper Dangaard Brouer @ 2019-02-19 18:53 UTC (permalink / raw)
To: netdev, Daniel Borkmann, Alexei Starovoitov; +Cc: Jesper Dangaard Brouer
The skb->queue_mapping already have read access, via __sk_buff->queue_mapping.
This patch allow BPF tc qdisc clsact write access to the queue_mapping via
tc_cls_act_is_valid_access. Also handle that the value NO_QUEUE_MAPPING
is not allowed.
It is already possible to change this via TC filter action skbedit
tc-skbedit(8). Due to the lack of TC examples, lets show one:
# tc qdisc add dev ixgbe1 clsact
# tc filter add dev ixgbe1 ingress matchall action skbedit queue_mapping 5
# tc filter list dev ixgbe1 ingress
The most common mistake is that XPS (Transmit Packet Steering) takes
precedence over setting skb->queue_mapping. XPS is configured per DEVICE
via /sys/class/net/DEVICE/queues/tx-*/xps_cpus via a CPU hex mask. To
disable set mask=00.
The purpose of changing skb->queue_mapping is to influence the selection of
the net_device "txq" (struct netdev_queue), which influence selection of
the qdisc "root_lock" (via txq->qdisc->q.lock) and txq->_xmit_lock. When
using the MQ qdisc the txq->qdisc points to different qdiscs and associated
locks, and HARD_TX_LOCK (txq->_xmit_lock), allowing for CPU scalability.
Due to lack of TC examples, lets show howto attach clsact BPF programs:
# tc qdisc add dev ixgbe2 clsact
# tc filter add dev ixgbe2 egress bpf da obj XXX_kern.o sec tc_qmap2cpu
# tc filter list dev ixgbe2 egress
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/filter.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 353735575204..8b80cdf96595 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6238,6 +6238,7 @@ static bool tc_cls_act_is_valid_access(int off, int size,
case bpf_ctx_range(struct __sk_buff, tc_classid):
case bpf_ctx_range_till(struct __sk_buff, cb[0], cb[4]):
case bpf_ctx_range(struct __sk_buff, tstamp):
+ case bpf_ctx_range(struct __sk_buff, queue_mapping):
break;
default:
return false;
@@ -6642,9 +6643,18 @@ static u32 bpf_convert_ctx_access(enum bpf_access_type type,
break;
case offsetof(struct __sk_buff, queue_mapping):
- *insn++ = BPF_LDX_MEM(BPF_H, si->dst_reg, si->src_reg,
- bpf_target_off(struct sk_buff, queue_mapping, 2,
- target_size));
+ if (type == BPF_WRITE) {
+ *insn++ = BPF_JMP_IMM(BPF_JGE, si->src_reg, NO_QUEUE_MAPPING, 1);
+ *insn++ = BPF_STX_MEM(BPF_H, si->dst_reg, si->src_reg,
+ bpf_target_off(struct sk_buff,
+ queue_mapping,
+ 2, target_size));
+ } else {
+ *insn++ = BPF_LDX_MEM(BPF_H, si->dst_reg, si->src_reg,
+ bpf_target_off(struct sk_buff,
+ queue_mapping,
+ 2, target_size));
+ }
break;
case offsetof(struct __sk_buff, vlan_present):
^ permalink raw reply related
* Re: [PATCH net-next 0/5] bnxt_en: Update for net-next.
From: David Miller @ 2019-02-19 18:45 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1550572276-14711-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 19 Feb 2019 05:31:11 -0500
> This series includes the usual firmware spec. update, a PCI ID addition,
> enhancements for VF trust, MDIO read/write for external PHY, and
> fixing the return code when TC flow offload fails.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] mlxsw: __mlxsw_sp_port_headroom_set(): Fix a use of local variable
From: David Miller @ 2019-02-19 18:33 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20190219093029.GA10647@splinter>
From: Ido Schimmel <idosch@mellanox.com>
Date: Tue, 19 Feb 2019 09:30:31 +0000
> We have a series for net-next that adds support for Spectrum-2 shared
> buffers and it depends on this patch. I was wondering if you could merge
> net into net-next today or later this week, so that we could submit it.
>
> Normally I would just wait for the merge to happen, but it looks like
> this is going to be the last week to submit changes and I prefer not to
> miss the window while waiting for the inevitable merge.
>
> Thanks and sorry about the noise.
Ido, I will send Linus a pull request today and he should pull it in and
I should therefore be able to get net-next sync'd with it by the end of
tomorrow.
^ permalink raw reply
* Re: [PATCH bpf-next 1/9] bpf: Add bpf helper bpf_tcp_enter_cwr
From: Eric Dumazet @ 2019-02-19 18:30 UTC (permalink / raw)
To: brakmo, netdev; +Cc: Martin Lau, Alexei Starovoitov
In-Reply-To: <20190219053830.2086578-1-brakmo@fb.com>
On 02/18/2019 09:38 PM, brakmo wrote:
> This patch adds a new bpf helper BPF_FUNC_tcp_enter_cwr
> "int bpf_tcp_enter_cwr(struct bpf_tcp_sock *tp)".
> It is added to BPF_PROG_TYPE_CGROUP_SKB typed bpf_prog
> which currently can be attached to the ingress and egress
> path.
>
Do we have the guarantee socket is a tcp one, and that the caller
owns the socket lock ?
Please describe the exact context for this helper being used.
^ permalink raw reply
* Re: [PATCH bpf-next 3/9] bpf: add bpf helper bpf_skb_set_ecn
From: Eric Dumazet @ 2019-02-19 18:30 UTC (permalink / raw)
To: brakmo, netdev; +Cc: Martin Lau, Alexei Starovoitov
In-Reply-To: <20190219053832.2086706-1-brakmo@fb.com>
On 02/18/2019 09:38 PM, brakmo wrote:
> This patch adds a new bpf helper BPF_FUNC_skb_set_ecn
> "int bpf_skb_set_Ecn(struct sk_buff *skb)". It is added to
> BPF_PROG_TYPE_CGROUP_SKB typed bpf_prog which currently can
> be attached to the ingress and egress path. This type of
> bpf_prog cannot modify the skb directly.
>
> This helper is used to set the ECN bits (2) of the IPv6 or IPv4
> header in skb. It can be used by a bpf_prog to manage egress
> network bandwdith limit per cgroupv2 by inducing an ECN
> response in the TCP sender (when the packet is ECN enabled).
> This works best when using DCTCP.
> +
> +BPF_CALL_2(bpf_skb_set_ecn, struct sk_buff *, skb, u32, val)
> +{
> + struct ipv6hdr *ip6h = ipv6_hdr(skb);
> +
> + if ((val & ~0x3) != 0)
> + return -EINVAL;
> +
> + if (ip6h->version == 6) {
> + ip6h->flow_lbl[0] = (ip6h->flow_lbl[0] & ~0x30) | (val << 4);
> + return 0;
> + } else if (ip6h->version == 4) {
> + struct iphdr *ip4h = (struct iphdr *)ip6h;
> +
> + ip4h->tos = (ip4h->tos & ~0x3) | val;
Why is not the IPv4 checksum recomputed here ?
If you leave this task to the caller, this should be documented.
These hard coded constants are not really nice.
Why not simply using INET_ECN_set_ce() which is IPv4/IPv6 ready ?
Do you really need to set anything else than CE ?
^ permalink raw reply
* Re: [PATCH bpf-next 7/9] bpf: Sample NRM BPF program to limit egress bw
From: Eric Dumazet @ 2019-02-19 18:29 UTC (permalink / raw)
To: brakmo, netdev; +Cc: Martin Lau, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190219053837.2086945-1-brakmo@fb.com>
On 02/18/2019 09:38 PM, brakmo wrote:
> +
> +static __always_inline void get_nrm_pkt_info(struct bpf_sock *sk,
> + struct nrm_pkt_info *pkti)
> +{
> + if (sk->family == AF_INET6 || sk->family == AF_INET) {
> + pkti->is_ip = true;
> + pkti->is_tcp = (sk->protocol == IPPROTO_TCP);
> + if (pkti->is_tcp) {
> + struct bpf_tcp_sock *tp;
> +
> + tp = bpf_tcp_sock(sk);
> + if (tp)
> + pkti->ecn = tp->ecn_flags & TCP_ECN_OK;
> + else
> + pkti->ecn = 0;
> + } else {
> + pkti->ecn = 0;
> + }
> + } else {
> + pkti->is_ip = false;
> + pkti->is_tcp = false;
> + pkti->ecn = 0;
> + }
> +}
>
This looks very strange.
ECN capability is per packet, and does not need access to the original
TCP socket really.
We definitely can use ECN with UDP packets.
IMO this sample looks like a work in progress.
EDT model allows to implement full shaping (not only virtual one)
by twaking/advancing skb->tstamp
(see commit f11216b24219a bpf: add skb->tstamp r/w access from tc clsact and cg skb progs)
Implementing shaping with the need of accessing TCP sockets seems a layering violation,
a lot of things can go wrong with this model.
For instance, you wont be able to offload this.
^ permalink raw reply
* [PATCH] iwlwifi: mvm: Use div64_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Nathan Chancellor @ 2019-02-19 18:21 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Nick Desaulniers,
Nathan Chancellor
Clang warns:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning:
comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long
long *') and 'uint64_t *' (aka 'unsigned long long *'))
[-Wcompare-distinct-pointer-types]
do_div(rtt_avg, 6666);
^~~~~~~~~~~~~~~~~~~~~
include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
1 warning generated.
do_div expects an unsigned dividend. Use div64_s64, which expects a
signed dividend.
Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
Link: https://github.com/ClangBuiltLinux/linux/issues/372
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
index e9822a3ec373..92b22250eb7d 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
@@ -462,7 +462,7 @@ static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm, u8 index,
{
s64 rtt_avg = res->ftm.rtt_avg * 100;
- do_div(rtt_avg, 6666);
+ div64_s64(rtt_avg, 6666);
IWL_DEBUG_INFO(mvm, "entry %d\n", index);
IWL_DEBUG_INFO(mvm, "\tstatus: %d\n", res->status);
--
2.21.0.rc1
^ permalink raw reply related
* Re: [PATCH iproute2] ip-rule/trivial: add comment about json key "to_tbl" for unspecific rule action
From: Stephen Hemminger @ 2019-02-19 18:19 UTC (permalink / raw)
To: Thomas Haller; +Cc: netdev
In-Reply-To: <20190219140331.16630-1-thaller@redhat.com>
On Tue, 19 Feb 2019 15:03:31 +0100
Thomas Haller <thaller@redhat.com> wrote:
> The key should not be called "to_tbl" because it is exactly
> not a FR_ACT_TO_TBL action.
>
> # ip rule add blackhole
> # ip -j rule | python -m json.tool
> ...
> {
> "priority": 0,
> "src": "all",
> "to_tbl": "blackhole"
> },
>
> Still, as this is already released API from v4.17.0, stick to it.
> Only add a comment for this oddity.
>
> Related: 0dd4ccc56c0e ("iprule: add json support")
>
> Signed-off-by: Thomas Haller <thaller@redhat.com>
> ---
> If it is still permissible to change the API, I can also send a patch to
> rename "to_tbl" key to "action".
>
> ip/iprule.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/ip/iprule.c b/ip/iprule.c
> index 2f58d8c2..aea175aa 100644
> --- a/ip/iprule.c
> +++ b/ip/iprule.c
> @@ -459,6 +459,8 @@ int print_rule(struct nlmsghdr *n, void *arg)
> } else if (frh->action == FR_ACT_NOP) {
> print_null(PRINT_ANY, "nop", "nop", NULL);
> } else if (frh->action != FR_ACT_TO_TBL) {
> + /* The action is not(!) to-tbl, however for historic
> + * reasons, this JSON key is called "to_tbl". */
> print_string(PRINT_ANY, "to_tbl", "%s",
> rtnl_rtntype_n2a(frh->action, b1, sizeof(b1)));
> }
Just fix it and add fixes tag. JSON has been only added for a short time.
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Vivien Didelot @ 2019-02-19 18:20 UTC (permalink / raw)
To: Florian Fainelli
Cc: Russell King - ARM Linux admin, Andrew Lunn, Heiner Kallweit,
David S. Miller, netdev
In-Reply-To: <a93298cc-7acd-6357-fcee-fe238487c143@gmail.com>
Hi Florian,
On Tue, 19 Feb 2019 09:44:32 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > OK, thanks for the details. The programming of the broadcast MAC address
> > must be handled in the core then, I will move this from mv88e6xxx up to the
> > DSA layer later, but that's totally orthogonal here.
>
> I am not sure if it makes sense for us to work hard on supporting
> BR_BCAST_FLOOD, for instance, on Broadcom switches, there does not
> appear to be an easy way to specify whether broadcast traffic will be
> flooded or not, it will be. The only way to tsolve that is to create a
> MDB/FDB entry with negative logic (e.g.: forward to a
> non-existing/connected port). Every other bridge flag typically maps 1:1
> with a corresponding hardware feature, so we should support them.
I think it's best to keep away from driver-specific hacks :-)
Since broadcom floods multicast and BR_BCAST_FLOOD is set by default,
this would simply translate as not implementing a port_flood_bc ops in the
broadcom driver.
But I agree that it doesn't seem necessary to implement support for this yet.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next 0/2] Fix W=1 compilation warnings
From: Saeed Mahameed @ 2019-02-19 18:13 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: netdev@vger.kernel.org, Leon Romanovsky,
linux-rdma@vger.kernel.org, Eyal Davidovich
In-Reply-To: <20190217132128.9709-1-leon@kernel.org>
On Sun, 2019-02-17 at 15:21 +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Hi Saeed,
>
> This short series fixes two small compilation warnings which are
> visible
> while compiling with W=1.
>
> Thanks
>
> Leon Romanovsky (2):
> net/mlx5e: Add missing static function annotation
> net/mlx5: Delete unused FPGA QPN variable
>
> drivers/net/ethernet/mellanox/mlx5/core/en/monitor_stats.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> --
> 2.19.1
>
Series applied to net-next-mlx5
Thanks Leon!
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/mlx5e: Remove 'parse_attr' argument in mlx5e_tc_add_fdb_flow()
From: Saeed Mahameed @ 2019-02-19 18:09 UTC (permalink / raw)
To: xiangxia.m.yue@gmail.com, gerlitz.or@gmail.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <1549942783-56833-2-git-send-email-xiangxia.m.yue@gmail.com>
On Mon, 2019-02-11 at 19:39 -0800, xiangxia.m.yue@gmail.com wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> This patch is a little improvement. Simplify the
> mlx5e_tc_add_fdb_flow().
>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> ---
LGTM
Applied to net-next-mlx5
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 1/2] net/mlx5e: Introduce mlx5e_flow_esw_attr_init() helper
From: Saeed Mahameed @ 2019-02-19 18:09 UTC (permalink / raw)
To: xiangxia.m.yue@gmail.com, gerlitz.or@gmail.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <1549942783-56833-1-git-send-email-xiangxia.m.yue@gmail.com>
On Mon, 2019-02-11 at 19:39 -0800, xiangxia.m.yue@gmail.com wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> Introduce the mlx5e_flow_esw_attr_init() helper
> for simplifying codes.
>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> ---
Applied to net-next-mlx5
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags
From: Russell King - ARM Linux admin @ 2019-02-19 18:08 UTC (permalink / raw)
To: Vivien Didelot
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
netdev
In-Reply-To: <20190219123828.GD10959@t480s.localdomain>
On Tue, Feb 19, 2019 at 12:38:28PM -0500, Vivien Didelot wrote:
> Hi Russell,
>
> On Tue, 19 Feb 2019 17:14:14 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> > > > > > +static unsigned long mv88e6xxx_bridge_flags_support(struct dsa_switch *ds)
> > > > > > +{
> > > > > > + struct mv88e6xxx_chip *chip = ds->priv;
> > > > > > + unsigned long support = 0;
> > > > > > +
> > > > > > + if (chip->info->ops->port_set_egress_floods)
> > > > > > + support |= BR_FLOOD | BR_MCAST_FLOOD;
> > > > > > +
> > > > > > + return support;
> > > > > > +}
> > > > >
> > > > > I think that it isn't necessary to propagate the notion of bridge flags down
> > > > > to the DSA drivers. It might be just enough to add:
> > > > >
> > > > > port_egress_flood(dsa_switch *ds, int port, bool uc, bool mc)
> > > > >
> > > > > to dsa_switch_ops and set BR_FLOOD | BR_MCAST_FLOOD from the DSA core,
> > > > > if the targeted driver has ds->ops->port_set_egress_flood. What do you think?
> > > >
> > > > There are two other flags that I haven't covered which the bridge code
> > > > expects to be offloaded, and those are the broadcast flood flag and
> > > > the learning flag.
> > >
> > > I see. What does the bridge code do if these flags are set? Does it expect
> > > the underlying devices to handle ff:ff:ff:ff:ff:ff magically or does it
> > > program this entry into the bridged ports?
> >
> > The bridge code defaults to all four flags set. See new_nbp() in
> > net/bridge/br_if.c:
> >
> > p->flags = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
> >
> > bridge(8) doesn't touch BR_BCAST_FLOOD, but it is made available to
> > userspace via netlink and IFLA_BRPORT_BCAST_FLOOD. Hence, there's
> > no man page documentation for that flag.
> >
> > According to br_flood() in net/bridge/br_forward.c, it controls
> > whether broadcast frames are flooded to all ports or not. Changing
> > this flag is merely handled just like the multicast/unicast flooding
> > flags - a call is made to set the offloaded flags, and if it isn't
> > returned as being supported, a warning is printed. No attempt is
> > made to create or change a forwarding entry for the broadcast MAC
> > address.
>
> OK, thanks for the details. The programming of the broadcast MAC address
> must be handled in the core then, I will move this from mv88e6xxx up to the
> DSA layer later, but that's totally orthogonal here.
>
> >
> > bridge(8) does document BR_LEARNING via IFLA_BRPORT_LEARNING:
> >
> > learning on or learning off
> > Controls whether a given port will learn MAC addresses from
> > received traffic or not. If learning if off, the bridge will end
> > up flooding any traffic for which it has no FDB entry. By
> > default this flag is on.
> >
> > > In the latter case we have almost nothing to do. In the former case, we can
> > > make the core call dsa_port_mdb_add on setup and when a VLAN is added.
> > >
> > > mv88e6xxx tries to be smart and is already doing that and I'm really not a fan.
> > >
> > > If tomorrow there's a switch capable of simply toggling a bit to do that,
> > > we can add a new ops and skip the port_mdb_add call in the core.
> > >
> > > > I know that the Marvell switches don't have a bit to control the
> > > > broadcast flooding, that appears to be controlled via a static entry
> > > > in the ATU which would have to be modified as the broadcast flood flag
> > > > is manipulated. I don't know how that is handled in other bridges.
> > > >
> > > > Do we want to include the broadcast flood in the above prototype?
> > > > If we go for this, how do we detect which options a switch supports?
> > >
> > > If the necessary dsa_switch_ops routine is correctly prototyped, having it
> > > implemented by a driver or not should be enough to inform the core that the
> > > related feature(s) is/are supported by the switch.
> > >
> > > I'll try to give a bit more context on why I'd prefer this approach, hoping
> > > it makes sense: a switch driver does not need to understand bridge flags
> > > per-se, the core should give enough abstraction to this layer (and any other
> > > net-specifics). The core just needs to know if a driver can program this or
> > > that. More importantly, it can easily become messy to maintain switch-cases
> > > of arbitrary flags in all drivers and the core.
> >
> > So, should we go the other way and have:
> >
> > int (*port_learning)(struct dsa_switch *ds, int port, bool enable);
> > int (*port_egress_flood_uc)(struct dsa_switch *ds, int port, bool enable);
> > int (*port_egress_flood_mc)(struct dsa_switch *ds, int port, bool enable);
> > int (*port_egress_flood_bc)(struct dsa_switch *ds, int port, bool enable);
> >
> > rather than trying to combine uc/mc into one? It would mean that we'd
> > be performing more bus reads/writes, but I guess that doesn't matter
> > for these configuration parameters.
>
> I like this very much. As long as these flags can be programmed in switch
> devices, these ops totally make sense.
Having these as separate functions means that we would then need
additional complexity in mv88e6xxx to store the per-port flooding state,
so we can do this:
reg &= ~MV88E6352_PORT_CTL0_EGRESS_FLOODS_MASK;
if (unicast && multicast)
reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_ALL_UNKNOWN_DA;
else if (unicast)
reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_MC_DA;
else if (multicast)
reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_UC_DA;
else
reg |= MV88E6352_PORT_CTL0_EGRESS_FLOODS_NO_UNKNOWN_DA;
for some of the switches. It looks to me like mv88e6xxx would prefer
having at least both the unicast and multicast flags together.
Even without that, it means more code in mv88e6xxx to wrap each of
these calls between the DSA ops and the chip specific ops...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH net] team: use operstate consistently for linkup
From: George Wilkie @ 2019-02-19 15:57 UTC (permalink / raw)
To: Jiri Pirko, David S. Miller; +Cc: netdev
When a port is added to a team, its initial state is derived
from netif_carrier_ok rather than netif_oper_up.
If it is carrier up but operationally down at the time of being
added, the port state.linkup will be set prematurely.
port state.linkup should be set consistently using
netif_oper_up rather than netif_carrier_ok.
Fixes: f1d22a1e0595 ("team: account for oper state")
Signed-off-by: George Wilkie <gwilkie@vyatta.att-mail.com>
---
drivers/net/team/team.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 958f1cf67282..6ce3f666d142 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1256,7 +1256,7 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
list_add_tail_rcu(&port->list, &team->port_list);
team_port_enable(team, port);
__team_compute_features(team);
- __team_port_change_port_added(port, !!netif_carrier_ok(port_dev));
+ __team_port_change_port_added(port, !!netif_oper_up(port_dev));
__team_options_change_check(team);
netdev_info(dev, "Port device %s added\n", portname);
@@ -2915,7 +2915,7 @@ static int team_device_event(struct notifier_block *unused,
switch (event) {
case NETDEV_UP:
- if (netif_carrier_ok(dev))
+ if (netif_oper_up(dev))
team_port_change_check(port, true);
break;
case NETDEV_DOWN:
--
2.11.0
^ permalink raw reply related
* Re: L2TPv3 offset
From: Guillaume Nault @ 2019-02-19 17:54 UTC (permalink / raw)
To: James Chapman; +Cc: t.martitz, davem, netdev
In-Reply-To: <e685d22c-e28e-8318-f612-07e2d1cd03ab@katalix.com>
On Tue, Feb 19, 2019 at 04:36:55PM +0000, James Chapman wrote:
> On 19/02/2019 13:09, t.martitz@avm.de wrote:
> >
> > Because everytime a LCCE decapsulates such traffic it'll suffer from
> > unaligned access to the inner IP header (likewise for the outer IP
> > header when encapsulating). It's a fundamental assumption that the IP
> > header is word-aligned in Linux so I'm surprised this isn't solved
> > already. And now the only way "fix" without patching the kernel is
> > being removed.
> >
IIUC, you'd be perfectly fine running without offset if the stack was
properly handling the alignment problems created by the encapsulated
ethernet header.
Unaligned headers is a fundamental problem when tunneling ethernet
frames. I'd expect other encapsulation modules (vxlan, geneve,
gretap...) to have the same issues (but I'd be happy to be proven
wrong).
The topic has been discussed a few years ago:
https://lore.kernel.org/netdev/20160922.015242.735026657310158125.davem@davemloft.net/
I might very well have missed some discussions, but I don't remember
any patch aimed at tackling this problem so far.
^ 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