Re: [PATCH iproute2 net-next] bridge: add support for backup port
On 10/12/18 5:42 AM, Nikolay Aleksandrov wrote: > This patch adds support for the new backup port option that can be set > on a bridge port. If the port's carrier goes down all of the traffic > gets redirected to the configured backup port. We add the following new > arguments: > $ ip link set dev brport type bridge_slave backup_port brport2 > $ ip link set dev brport type bridge_slave nobackup_port > > $ bridge link set dev brport backup_port brport2 > $ bridge link set dev brport nobackup_port > > The man pages are updated respectively. > Also 2 minor style adjustments: > - add missing space to bridge man page's state argument > - use lower starting case for vlan_tunnel in ip-link man page (to be > consistent with the rest) > > Signed-off-by: Nikolay Aleksandrov > --- > bridge/link.c| 26 ++ > ip/iplink_bridge_slave.c | 18 ++ > man/man8/bridge.8| 13 - > man/man8/ip-link.8.in| 14 -- > 4 files changed, 68 insertions(+), 3 deletions(-) > applied to iproute2-next. Thanks
Re: [PATCH iproute2 net-next] ipneigh: support for NTF_EXT_LEARNED flag on neigh entries
On 10/11/18 2:45 PM, Roopa Prabhu wrote: > From: Roopa Prabhu > > Adds new option extern_learn to set NTF_EXT_LEARNED flag > on neigh entries. > > Signed-off-by: Roopa Prabhu > --- > ip/ipneigh.c| 7 ++- > man/man8/ip-neighbour.8 | 9 - > 2 files changed, 14 insertions(+), 2 deletions(-) > applied to iproute2-next. Thanks
Urgent,
Hello i need your help to invest in your region, please can you assist me?
Re: [PATCH net] net/sched: properly init chain in case of multiple control actions
On Fri, 2018-10-12 at 13:57 -0700, Cong Wang wrote: > Why not just validate the fallback action in each action init()? > For example, checking tcfg_paction in tcf_gact_init(). > > I don't see the need of making it generic. hello Cong, once again thanks for looking at this. what you say is doable, and I evaluated doing it before proposing this patch. But I felt unconfortable, because I needed to pass struct tcf_proto *tp in tcf_gact_init() to initialize a->goto_chain with the chain_idx encoded in the fallback action. So, I would have changed all the init() functions in all TC actions, just to fix two of them. A (legal?) trick is to let tcf_action store the fallback action when it contains a 'goto chain' command, I just posted a proposal for gact. If you think it's ok, I will test and post the same for act_police. regards, -- davide
[PATCH net] net/sched: act_gact: properly init 'goto chain'
the following script:
# tc f a dev v0 egress chain 4 matchall action simple sdata "A triumph!"
# tc f a dev v0 egress matchall action pass random determ goto chain 4 5
produces the following crash:
BUG: unable to handle kernel NULL pointer dereference at
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 9 PID: 0 Comm: swapper/9 Not tainted 4.19.0-rc6.chainfix + #472
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0
07/26/2013
RIP: 0010:tcf_action_exec+0xb8/0x100
Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10
5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48
83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
RSP: 0018:9af96f843bf8 EFLAGS: 00010246
RAX: 202a RBX: 9af9679cf200 RCX: 005a
RDX: RSI: 0001 RDI: 9af585e006c0
RBP: 9af96f843ca0 R08: 1600 R09:
R10: R11: R12: 9af968db4400
R13: 9af968db4408 R14: 0001 R15: 9af585e006c0
FS: () GS:9af96f84() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00025980a001 CR4: 001606e0
Call Trace:
tcf_classify+0x89/0x140
__dev_queue_xmit+0x413/0x8a0
? ip6_finish_output2+0x336/0x520
ip6_finish_output2+0x336/0x520
? ip6_output+0x68/0x110
ip6_output+0x68/0x110
? ip6_fragment+0x9e0/0x9e0
mld_sendpack+0x175/0x220
? mld_gq_timer_expire+0x40/0x40
mld_dad_timer_expire+0x25/0x80
call_timer_fn+0x2b/0x120
run_timer_softirq+0x3e8/0x440
? tick_sched_timer+0x37/0x70
? __hrtimer_run_queues+0x118/0x290
__do_softirq+0xe3/0x2bd
irq_exit+0xe3/0xf0
smp_apic_timer_interrupt+0x74/0x130
apic_timer_interrupt+0xf/0x20
RIP: 0010:cpuidle_enter_state+0xa5/0x320
Code: 71 82 5f 7e e8 bc 25 ab ff 48 89 c3 0f 1f 44 00 00 31 ff e8 3d 36 ab ff
80 7c 24 07 00 0f 85 28 02 00 00 fb 66 0f 1f 44 00 00 <4c> 29 f3 48 ba cf f7 53
e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7
RSP: 0018:afa1832cbe90 EFLAGS: 0246 ORIG_RAX: ff13
RAX: 9af96f862600 RBX: 003ede349ac5 RCX: 001f
RDX: 003ede349ac5 RSI: 313b14ef RDI:
RBP: cfa17fa40a00 R08: 9af96f85cdc0 R09: afc8
R10: afa1832cbe70 R11: afc8 R12: 0004
R13: 82578bd8 R14: 003ec085dc50 R15:
do_idle+0x200/0x280
cpu_startup_entry+0x6f/0x80
start_secondary+0x1a7/0x200
secondary_startup_64+0xa4/0xb0
Modules linked in: act_gact act_simple cls_matchall sch_ingress veth
intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
irqbypass crct10dif_pclmul crc32_pclmul ipmi_ssif ghash_clmulni_intel pcbc
aesni_intel ipmi_si iTCO_wdt crypto_simd iTCO_vendor_support cryptd mei_me
ipmi_devintf glue_helper mei joydev ipmi_msghandler pcc_cpufreq sg lpc_ich
pcspkr i2c_i801 ioatdma wmi ip_tables xfs libcrc32c mlx4_en sd_mod mgag200
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm isci drm
libsas igb ahci libahci scsi_transport_sas mlx4_core be2net crc32c_intel dca
libata i2c_algo_bit i2c_core megaraid_sas devlink dm_mirror dm_region_hash
dm_log dm_mod
CR2:
when CONFIG_GACT_PROB is enabled, gact allows users to specify a fallback
control action, that is stored in the action private data. 'goto chain x'
never worked for that case, since goto_chain was never initialized. There
is only one goto_chain handle per action: ensure that gact never contains
more than one 'goto chain' in a rule. If the fallback control action is a
'goto chain', copy it to tcf_action to ensure that goto_chain is properly
initialized.
Fixes: db50514f9a9c ("net: sched: add termination action to allow goto chain")
Signed-off-by: Davide Caratti
---
include/net/tc_act/tc_gact.h | 11 +--
net/sched/act_gact.c | 16 +++-
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/include/net/tc_act/tc_gact.h b/include/net/tc_act/tc_gact.h
index ef8dd0db70ce..0cbeb77349bc 100644
--- a/include/net/tc_act/tc_gact.h
+++ b/include/net/tc_act/tc_gact.h
@@ -10,12 +10,19 @@ struct tcf_gact {
#ifdef CONFIG_GACT_PROB
u16 tcfg_ptype;
u16 tcfg_pval;
+ int tcfg_caction;
int tcfg_paction;
atomic_tpackets;
#endif
};
#define to_gact(a) ((struct tcf_gact *)a)
+#ifdef CONFIG_GACT_PROB
+#define GACT_PRIMARY_ACTION(g) ((g)->tcfg_caction)
+#else
+#define GACT_PRIMARY_ACTION(g) ((g)->tcf_action)
+#endif
+
static inline bool __is_tcf_gact_act(const struct tc_action *a, int act,
bool is_ext)
{
@@ -26,8 +33,8 @@ static inline bool __is_tcf_gact_act(const struct tc_action
*a, int act,
return false;
gact =
[PATCH net-next v2] net: dsa: mv88e6xxx: Fix 88E6141/6341 2500mbps SERDES speed
This is a fix for the port_set_speed method for the Topaz family.
Currently the same method is used as for the Peridot family, but
this is wrong for the SERDES port.
On Topaz, the SERDES port is port 5, not 9 and 10 as in Peridot.
Moreover setting alt_bit on Topaz only makes sense for port 0 (for
(differentiating 100mbps vs 200mbps). The SERDES port does not
support more than 2500mbps, so alt_bit does not make any difference.
Signed-off-by: Marek Behún
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++--
drivers/net/dsa/mv88e6xxx/port.c | 25 +++--
drivers/net/dsa/mv88e6xxx/port.h | 1 +
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 78ce820b5257..e05d4eddc935 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2907,7 +2907,7 @@ static const struct mv88e6xxx_ops mv88e6141_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
- .port_set_speed = mv88e6390_port_set_speed,
+ .port_set_speed = mv88e6341_port_set_speed,
.port_tag_remap = mv88e6095_port_tag_remap,
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
.port_set_egress_floods = mv88e6352_port_set_egress_floods,
@@ -3528,7 +3528,7 @@ static const struct mv88e6xxx_ops mv88e6341_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
- .port_set_speed = mv88e6390_port_set_speed,
+ .port_set_speed = mv88e6341_port_set_speed,
.port_tag_remap = mv88e6095_port_tag_remap,
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
.port_set_egress_floods = mv88e6352_port_set_egress_floods,
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 92945841c8e8..cd7db60a508b 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -228,8 +228,11 @@ static int mv88e6xxx_port_set_speed(struct mv88e6xxx_chip
*chip, int port,
ctrl = MV88E6XXX_PORT_MAC_CTL_SPEED_1000;
break;
case 2500:
- ctrl = MV88E6390_PORT_MAC_CTL_SPEED_1 |
- MV88E6390_PORT_MAC_CTL_ALTSPEED;
+ if (alt_bit)
+ ctrl = MV88E6390_PORT_MAC_CTL_SPEED_1 |
+ MV88E6390_PORT_MAC_CTL_ALTSPEED;
+ else
+ ctrl = MV88E6390_PORT_MAC_CTL_SPEED_1;
break;
case 1:
/* all bits set, fall through... */
@@ -291,6 +294,24 @@ int mv88e6185_port_set_speed(struct mv88e6xxx_chip *chip,
int port, int speed)
return mv88e6xxx_port_set_speed(chip, port, speed, false, false);
}
+/* Support 10, 100, 200, 1000, 2500 Mbps (e.g. 88E6341) */
+int mv88e6341_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed)
+{
+ if (speed == SPEED_MAX)
+ speed = port < 5 ? 1000 : 2500;
+
+ if (speed > 2500)
+ return -EOPNOTSUPP;
+
+ if (speed == 200 && port != 0)
+ return -EOPNOTSUPP;
+
+ if (speed == 2500 && port < 5)
+ return -EOPNOTSUPP;
+
+ return mv88e6xxx_port_set_speed(chip, port, speed, !port, true);
+}
+
/* Support 10, 100, 200, 1000 Mbps (e.g. 88E6352 family) */
int mv88e6352_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed)
{
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index f32f56af8e35..36904c9bf955 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -269,6 +269,7 @@ int mv88e6xxx_port_set_duplex(struct mv88e6xxx_chip *chip,
int port, int dup);
int mv88e6065_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed);
int mv88e6185_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed);
+int mv88e6341_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed);
int mv88e6352_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed);
int mv88e6390_port_set_speed(struct mv88e6xxx_chip *chip, int port, int speed);
int mv88e6390x_port_set_speed(struct mv88e6xxx_chip *chip, int port, int
speed);
--
2.18.1
Re: Grant--
I, Mikhail Fridman have selected you specifically as one of my beneficiaries for my Charitable Donation of $5 Million Dollars, Check the link below for confirmation: https://www.rt.com/business/343781-mikhail-fridman-will-charity/ I await your earliest response for further directives. Best Regards, Mikhail Fridman.
Re: [PATCH net-next 1/3] veth: Account for packet drops in ndo_xdp_xmit
On 18/10/13 (土) 16:48, Jesper Dangaard Brouer wrote:
On Thu, 11 Oct 2018 18:36:48 +0900
Toshiaki Makita wrote:
Use existing atomic drop counter. Since drop path is really an
exceptional case here, I'm thinking atomic ops would not hurt the
performance.
Hmm... we try very hard not to add atomic ops to XDP code path. The
XDP_DROP case is also considered hot-path. In below code, the
atomic64_add happens for a bulk of dropped packets (currently up-to
16), so it might be okay.
Yes, this happens only once in a bulk sending.
Note that this drop does not include XDP_DROP. This drop is counted when
- ndo_xdp_xmit "flags" arg is invalid
- peer is detached
- XDP is not loaded on peer
- XDP ring (256 slots) overflow
So really exceptional. XDP_DROP is counted per-queue basis (non-atomic)
in the patch 2/3.
Toshiaki Makita
XDP packets and bytes are not counted in ndo_xdp_xmit, but will be
accounted on rx side by the following commit.
Signed-off-by: Toshiaki Makita
---
drivers/net/veth.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 224c56a..452193f2 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -308,16 +308,20 @@ static int veth_xdp_xmit(struct net_device *dev, int n,
{
struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
struct net_device *rcv;
+ int i, ret, drops = n;
unsigned int max_len;
struct veth_rq *rq;
- int i, drops = 0;
- if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
- return -EINVAL;
+ if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK)) {
+ ret = -EINVAL;
+ goto drop;
+ }
rcv = rcu_dereference(priv->peer);
- if (unlikely(!rcv))
- return -ENXIO;
+ if (unlikely(!rcv)) {
+ ret = -ENXIO;
+ goto drop;
+ }
rcv_priv = netdev_priv(rcv);
rq = _priv->rq[veth_select_rxq(rcv)];
@@ -325,9 +329,12 @@ static int veth_xdp_xmit(struct net_device *dev, int n,
* side. This means an XDP program is loaded on the peer and the peer
* device is up.
*/
- if (!rcu_access_pointer(rq->xdp_prog))
- return -ENXIO;
+ if (!rcu_access_pointer(rq->xdp_prog)) {
+ ret = -ENXIO;
+ goto drop;
+ }
+ drops = 0;
max_len = rcv->mtu + rcv->hard_header_len + VLAN_HLEN;
spin_lock(>xdp_ring.producer_lock);
@@ -346,7 +353,14 @@ static int veth_xdp_xmit(struct net_device *dev, int n,
if (flags & XDP_XMIT_FLUSH)
__veth_xdp_flush(rq);
- return n - drops;
+ if (likely(!drops))
+ return n;
+
+ ret = n - drops;
+drop:
+ atomic64_add(drops, >dropped);
+
+ return ret;
}
static void veth_xdp_flush(struct net_device *dev)
Re: [PATCH net-next 1/3] veth: Account for packet drops in ndo_xdp_xmit
On Thu, 11 Oct 2018 18:36:48 +0900
Toshiaki Makita wrote:
> Use existing atomic drop counter. Since drop path is really an
> exceptional case here, I'm thinking atomic ops would not hurt the
> performance.
Hmm... we try very hard not to add atomic ops to XDP code path. The
XDP_DROP case is also considered hot-path. In below code, the
atomic64_add happens for a bulk of dropped packets (currently up-to
16), so it might be okay.
> XDP packets and bytes are not counted in ndo_xdp_xmit, but will be
> accounted on rx side by the following commit.
>
> Signed-off-by: Toshiaki Makita
> ---
> drivers/net/veth.c | 30 ++
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 224c56a..452193f2 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -308,16 +308,20 @@ static int veth_xdp_xmit(struct net_device *dev, int n,
> {
> struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
> struct net_device *rcv;
> + int i, ret, drops = n;
> unsigned int max_len;
> struct veth_rq *rq;
> - int i, drops = 0;
>
> - if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
> - return -EINVAL;
> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK)) {
> + ret = -EINVAL;
> + goto drop;
> + }
>
> rcv = rcu_dereference(priv->peer);
> - if (unlikely(!rcv))
> - return -ENXIO;
> + if (unlikely(!rcv)) {
> + ret = -ENXIO;
> + goto drop;
> + }
>
> rcv_priv = netdev_priv(rcv);
> rq = _priv->rq[veth_select_rxq(rcv)];
> @@ -325,9 +329,12 @@ static int veth_xdp_xmit(struct net_device *dev, int n,
>* side. This means an XDP program is loaded on the peer and the peer
>* device is up.
>*/
> - if (!rcu_access_pointer(rq->xdp_prog))
> - return -ENXIO;
> + if (!rcu_access_pointer(rq->xdp_prog)) {
> + ret = -ENXIO;
> + goto drop;
> + }
>
> + drops = 0;
> max_len = rcv->mtu + rcv->hard_header_len + VLAN_HLEN;
>
> spin_lock(>xdp_ring.producer_lock);
> @@ -346,7 +353,14 @@ static int veth_xdp_xmit(struct net_device *dev, int n,
> if (flags & XDP_XMIT_FLUSH)
> __veth_xdp_flush(rq);
>
> - return n - drops;
> + if (likely(!drops))
> + return n;
> +
> + ret = n - drops;
> +drop:
> + atomic64_add(drops, >dropped);
> +
> + return ret;
> }
>
> static void veth_xdp_flush(struct net_device *dev)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
Re: [PATCH bpf-next] tools: bpftool: add map create command
On Fri, Oct 12, 2018 at 11:06:14AM -0700, Jakub Kicinski wrote:
> Add a way of creating maps from user space. The command takes
> as parameters most of the attributes of the map creation system
> call command. After map is created its pinned to bpffs. This makes
> it possible to easily and dynamically (without rebuilding programs)
> test various corner cases related to map creation.
>
> Map type names are taken from bpftool's array used for printing.
> In general these days we try to make use of libbpf type names, but
> there are no map type names in libbpf as of today.
>
> As with most features I add the motivation is testing (offloads) :)
>
> Signed-off-by: Jakub Kicinski
> Reviewed-by: Quentin Monnet
...
> fprintf(stderr,
> "Usage: %s %s { show | list } [MAP]\n"
> + " %s %s create FILE type TYPE key KEY_SIZE value
> VALUE_SIZE \\\n"
> + " entries MAX_ENTRIES [name NAME]
> [flags FLAGS] \\\n"
> + " [dev NAME]\n"
I suspect as soon as bpftool has an ability to create standalone maps
some folks will start relying on such interface.
Therefore I'd like to request to make 'name' argument to be mandatory.
I think in the future we will require BTF to be mandatory too.
We need to move towards more transparent and debuggable infra.
Do you think requiring json description of key/value would be managable to
implement?
Then bpftool could convert it to BTF and the map full be fully defined.
I certainly understand that bpf prog can disregard the key/value layout today,
but we will make verifier to enforce that in the future too.
