* [PATCH net-next v2 15/16] tipc: create TIPC_CONNECTING as a new sk_state
From: Parthasarathy Bhuvaragan @ 2016-11-01 13:02 UTC (permalink / raw)
To: netdev; +Cc: tipc-discussion, jon.maloy, maloy, ying.xue
In-Reply-To: <1478005369-17239-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
In this commit, we create a new tipc socket state TIPC_CONNECTING
by primarily replacing the SS_CONNECTING with TIPC_CONNECTING.
There is no functional change in this commit.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
---
v2: set TIPC_CONNECTING to TCP_SYN_SENT.
---
net/tipc/socket.c | 60 ++++++++++++++++++++++++++-----------------------------
1 file changed, 28 insertions(+), 32 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index e732b1fe7eab..074f4d546828 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -55,6 +55,7 @@ enum {
TIPC_ESTABLISHED = TCP_ESTABLISHED,
TIPC_OPEN = TCP_CLOSE,
TIPC_DISCONNECTING = TCP_CLOSE_WAIT,
+ TIPC_CONNECTING = TCP_SYN_SENT,
};
/**
@@ -349,7 +350,6 @@ static bool tsk_peer_msg(struct tipc_sock *tsk, struct tipc_msg *msg)
*/
static int tipc_set_sk_state(struct sock *sk, int state)
{
- int oldstate = sk->sk_socket->state;
int oldsk_state = sk->sk_state;
int res = -EINVAL;
@@ -358,16 +358,17 @@ static int tipc_set_sk_state(struct sock *sk, int state)
res = 0;
break;
case TIPC_LISTEN:
+ case TIPC_CONNECTING:
if (oldsk_state == TIPC_OPEN)
res = 0;
break;
case TIPC_ESTABLISHED:
- if (oldstate == SS_CONNECTING ||
+ if (oldsk_state == TIPC_CONNECTING ||
oldsk_state == TIPC_OPEN)
res = 0;
break;
case TIPC_DISCONNECTING:
- if (oldstate == SS_CONNECTING ||
+ if (oldsk_state == TIPC_CONNECTING ||
oldsk_state == TIPC_ESTABLISHED)
res = 0;
break;
@@ -689,16 +690,12 @@ static unsigned int tipc_poll(struct file *file, struct socket *sock,
if (sk->sk_shutdown == SHUTDOWN_MASK)
mask |= POLLHUP;
- switch ((int)sock->state) {
- case SS_CONNECTED:
+ if ((int)sock->state == SS_CONNECTED) {
if (!tsk->link_cong && !tsk_conn_cong(tsk))
mask |= POLLOUT;
- /* fall thru' */
- case SS_CONNECTING:
if (!skb_queue_empty(&sk->sk_receive_queue))
mask |= (POLLIN | POLLRDNORM);
- break;
- default:
+ } else {
switch (sk->sk_state) {
case TIPC_OPEN:
if (!tsk->link_cong)
@@ -711,6 +708,7 @@ static unsigned int tipc_poll(struct file *file, struct socket *sock,
mask = (POLLIN | POLLRDNORM | POLLHUP);
break;
case TIPC_LISTEN:
+ case TIPC_CONNECTING:
if (!skb_queue_empty(&sk->sk_receive_queue))
mask |= (POLLIN | POLLRDNORM);
break;
@@ -1014,7 +1012,7 @@ static int __tipc_sendmsg(struct socket *sock, struct msghdr *m, size_t dsz)
rc = tipc_node_xmit(net, &pktchain, dnode, tsk->portid);
if (likely(!rc)) {
if (!is_connectionless)
- sock->state = SS_CONNECTING;
+ tipc_set_sk_state(sk, TIPC_CONNECTING);
return dsz;
}
if (rc == -ELINKCONG) {
@@ -1650,9 +1648,10 @@ static bool filter_connect(struct tipc_sock *tsk, struct sk_buff *skb)
sk->sk_state_change(sk);
}
return true;
+ }
- case SS_CONNECTING:
-
+ switch (sk->sk_state) {
+ case TIPC_CONNECTING:
/* Accept only ACK or NACK message */
if (unlikely(!msg_connected(hdr)))
return false;
@@ -1684,9 +1683,7 @@ static bool filter_connect(struct tipc_sock *tsk, struct sk_buff *skb)
/* 'ACK-' message is neither accepted nor rejected: */
msg_set_dest_droppable(hdr, 1);
return false;
- }
- switch (sk->sk_state) {
case TIPC_OPEN:
case TIPC_DISCONNECTING:
break;
@@ -1955,7 +1952,8 @@ static int tipc_wait_for_connect(struct socket *sock, long *timeo_p)
return sock_intr_errno(*timeo_p);
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
- done = sk_wait_event(sk, timeo_p, sock->state != SS_CONNECTING);
+ done = sk_wait_event(sk, timeo_p,
+ sk->sk_state != TIPC_CONNECTING);
finish_wait(sk_sleep(sk), &wait);
} while (!done);
return 0;
@@ -1978,7 +1976,7 @@ static int tipc_connect(struct socket *sock, struct sockaddr *dest,
struct sockaddr_tipc *dst = (struct sockaddr_tipc *)dest;
struct msghdr m = {NULL,};
long timeout = (flags & O_NONBLOCK) ? 0 : tsk->conn_timeout;
- socket_state previous;
+ int previous;
int res = 0;
lock_sock(sk);
@@ -2006,7 +2004,7 @@ static int tipc_connect(struct socket *sock, struct sockaddr *dest,
goto exit;
}
- previous = sock->state;
+ previous = sk->sk_state;
switch (sk->sk_state) {
case TIPC_OPEN:
@@ -2024,31 +2022,29 @@ static int tipc_connect(struct socket *sock, struct sockaddr *dest,
if ((res < 0) && (res != -EWOULDBLOCK))
goto exit;
- /* Just entered SS_CONNECTING state; the only
+ /* Just entered TIPC_CONNECTING state; the only
* difference is that return value in non-blocking
* case is EINPROGRESS, rather than EALREADY.
*/
res = -EINPROGRESS;
- break;
- }
-
- switch (sock->state) {
- case SS_CONNECTING:
- if (previous == SS_CONNECTING)
- res = -EALREADY;
- if (!timeout)
+ /* fall thru' */
+ case TIPC_CONNECTING:
+ if (!timeout) {
+ if (previous == TIPC_CONNECTING)
+ res = -EALREADY;
goto exit;
+ }
timeout = msecs_to_jiffies(timeout);
/* Wait until an 'ACK' or 'RST' arrives, or a timeout occurs */
res = tipc_wait_for_connect(sock, &timeout);
- break;
- case SS_CONNECTED:
+ goto exit;
+ }
+
+ if (sock->state == SS_CONNECTED)
res = -EISCONN;
- break;
- default:
+ else
res = -EINVAL;
- break;
- }
+
exit:
release_sock(sk);
return res;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next V2 1/3] net/mlx4_en: Add TX_XDP for CQ types
From: Saeed Mahameed @ 2016-11-01 11:57 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller
Cc: netdev, Eran Ben Elisha, Brenden Blanco, Alexei Starovoitov
In-Reply-To: <1478000186-5158-2-git-send-email-tariqt@mellanox.com>
On 11/01/2016 01:36 PM, Tariq Toukan wrote:
> Support XDP CQ type, and refactor the CQ type enum.
> Rename the is_tx field to match the change.
>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCHv2 net 0/3] sctp: a bunch of fixes by holding transport
From: Neil Horman @ 2016-11-01 13:32 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner,
Vlad Yasevich
In-Reply-To: <cover.1477916928.git.lucien.xin@gmail.com>
On Mon, Oct 31, 2016 at 08:32:30PM +0800, Xin Long wrote:
> There are several places where it holds assoc after getting transport by
> searching from transport rhashtable, it may cause use-after-free issue.
>
> This patchset is to fix them by holding transport instead.
>
> v1->v2:
> Fix the changelog of patch 2/3
>
> Xin Long (3):
> sctp: hold transport instead of assoc in sctp_diag
> sctp: return back transport in __sctp_rcv_init_lookup
> sctp: hold transport instead of assoc when lookup assoc in rx path
>
> include/net/sctp/sctp.h | 2 +-
> net/sctp/input.c | 35 +++++++++++++++++------------------
> net/sctp/ipv6.c | 2 +-
> net/sctp/socket.c | 5 +----
> 4 files changed, 20 insertions(+), 24 deletions(-)
>
> --
> 2.1.0
>
>
series
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: Why does tcp collapse behavior depend on nr_frags?
From: Eric Dumazet @ 2016-11-01 13:33 UTC (permalink / raw)
To: Ilya Lesokhin; +Cc: netdev@vger.kernel.org, tls-fpga-sw-dev, Ilpo Järvinen
In-Reply-To: <VI1PR0502MB29577BA8C670D1379CC4F1B7D4A10@VI1PR0502MB2957.eurprd05.prod.outlook.com>
On Tue, 2016-11-01 at 08:15 +0000, Ilya Lesokhin wrote:
> Hi,
> I've notice that tcp_can_collapse() returns false if skb_shinfo(skb)->nr_frags != 0.
> Is there a reason why we want to base the collapse decision in retransmission on whether
> the data is located in a frag or the linear part?
>
> The relevant commit is
> tcp: collapse more than two on retransmission ('4a17fc3add594fcc1c778e93a95b6ecf47f630e5')
>
> Thanks,
> Ilya
Good point.
I am guessing you see this after commit
3613b3dbd1ade9a6a626dae1f608c57638eb5e8a
("tcp: prepare skbs for better sack shifting") ?
Problem is that the left skb might have no skb_availroom() anyway...
We could theoretically use the same helpers we use at sack shifting,
but are these collapse events frequent enough we should care ?
Thanks !
^ permalink raw reply
* 39165255551 netdev
From: nmckenna @ 2016-11-01 13:33 UTC (permalink / raw)
To: netdev
[-- Attachment #1: jlnetdev.zip --]
[-- Type: application/zip, Size: 13429 bytes --]
^ permalink raw reply
* [PATCH net-next 0/2] misc TC/flower changes
From: Roi Dayan @ 2016-11-01 14:08 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jiri Pirko, Roi Dayan
This series includes two small changes to the TC flower classifier.
Thanks,
Roi
Roi Dayan (2):
net/sched: cls_flower: add missing unbind call when destroying flows
net/sched: cls_flower: merge filter delete/destroy common code
net/sched/cls_flower.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 1/2] net/sched: cls_flower: add missing unbind call when destroying flows
From: Roi Dayan @ 2016-11-01 14:08 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jiri Pirko, Roi Dayan
In-Reply-To: <1478009309-63180-1-git-send-email-roid@mellanox.com>
tcf_unbind was called in fl_delete but was missing in fl_destroy when
force deleting flows.
Fixes: 77b9900ef53a ('tc: introduce Flower classifier')
Signed-off-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_flower.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index f6f40fb..a5f6370 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -280,6 +280,7 @@ static bool fl_destroy(struct tcf_proto *tp, bool force)
list_for_each_entry_safe(f, next, &head->filters, list) {
fl_hw_destroy_filter(tp, (unsigned long)f);
list_del_rcu(&f->list);
+ tcf_unbind_filter(tp, &f->res);
call_rcu(&f->rcu, fl_destroy_filter);
}
RCU_INIT_POINTER(tp->root, NULL);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/2] net/sched: cls_flower: merge filter delete/destroy common code
From: Roi Dayan @ 2016-11-01 14:08 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jiri Pirko, Roi Dayan
In-Reply-To: <1478009309-63180-1-git-send-email-roid@mellanox.com>
Move common code from fl_delete and fl_detroy to __fl_delete.
Signed-off-by: Roi Dayan <roid@mellanox.com>
---
net/sched/cls_flower.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index a5f6370..a8fb1ca 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -269,6 +269,14 @@ static void fl_hw_update_stats(struct tcf_proto *tp, struct cls_fl_filter *f)
dev->netdev_ops->ndo_setup_tc(dev, tp->q->handle, tp->protocol, &tc);
}
+static void __fl_delete(struct tcf_proto *tp, struct cls_fl_filter *f)
+{
+ list_del_rcu(&f->list);
+ fl_hw_destroy_filter(tp, (unsigned long)f);
+ tcf_unbind_filter(tp, &f->res);
+ call_rcu(&f->rcu, fl_destroy_filter);
+}
+
static bool fl_destroy(struct tcf_proto *tp, bool force)
{
struct cls_fl_head *head = rtnl_dereference(tp->root);
@@ -277,12 +285,8 @@ static bool fl_destroy(struct tcf_proto *tp, bool force)
if (!force && !list_empty(&head->filters))
return false;
- list_for_each_entry_safe(f, next, &head->filters, list) {
- fl_hw_destroy_filter(tp, (unsigned long)f);
- list_del_rcu(&f->list);
- tcf_unbind_filter(tp, &f->res);
- call_rcu(&f->rcu, fl_destroy_filter);
- }
+ list_for_each_entry_safe(f, next, &head->filters, list)
+ __fl_delete(tp, f);
RCU_INIT_POINTER(tp->root, NULL);
if (head->mask_assigned)
rhashtable_destroy(&head->ht);
@@ -742,10 +746,7 @@ static int fl_delete(struct tcf_proto *tp, unsigned long arg)
rhashtable_remove_fast(&head->ht, &f->ht_node,
head->ht_params);
- list_del_rcu(&f->list);
- fl_hw_destroy_filter(tp, (unsigned long)f);
- tcf_unbind_filter(tp, &f->res);
- call_rcu(&f->rcu, fl_destroy_filter);
+ __fl_delete(tp, f);
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Eric Dumazet @ 2016-11-01 14:19 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, jiri, mlxsw, roopa, dsa, nikolay, andy,
vivien.didelot, andrew, f.fainelli, alexander.h.duyck, kuznet,
jmorris, yoshfuji, kaber, Ido Schimmel
In-Reply-To: <20161031225737.7nfoy4ka3ydzhptq@splinter>
On Tue, 2016-11-01 at 00:57 +0200, Ido Schimmel wrote:
> On Mon, Oct 31, 2016 at 02:24:06PM -0700, Eric Dumazet wrote:
> > How well will this work for large FIB tables ?
> >
> > Holding rtnl while sending thousands of skb will prevent consumers to
> > make progress ?
>
> Can you please clarify what do you mean by "while sending thousands of
> skb"? This patch doesn't generate notifications to user space, but
> instead invokes notification routines inside the kernel. I probably
> misunderstood you.
>
> Are you suggesting this be done using RCU instead? Well, there are a
> couple of reasons why I took RTNL here:
>
No, I do not believe RCU is wanted here, in control path where we might
sleep anyway.
> 1) The FIB notification chain is blocking, so listeners are expected to
> be able to sleep. This isn't possible if we use RCU. Note that this
> chain is mainly useful for drivers that reflect the FIB table into a
> capable device and hardware operations usually involve sleeping.
>
> 2) The insertion of a single route is done with RTNL held. I didn't want
> to differentiate between both cases. This property is really useful for
> listeners, as they don't need to worry about locking in writer-side.
> Access to data structs is serialized by RTNL.
My concern was that for large iterations, you might hold RTNL and/or
current cpu for hundred of ms or even seconds...
^ permalink raw reply
* ATENCIÓN;
From: Sistemas administrador @ 2016-11-01 14:06 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2016
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/sched: cls_flower: merge filter delete/destroy common code
From: Jiri Pirko @ 2016-11-01 14:23 UTC (permalink / raw)
To: Roi Dayan; +Cc: David S. Miller, netdev, Jiri Pirko
In-Reply-To: <1478009309-63180-3-git-send-email-roid@mellanox.com>
Tue, Nov 01, 2016 at 03:08:29PM CET, roid@mellanox.com wrote:
>Move common code from fl_delete and fl_detroy to __fl_delete.
>
>Signed-off-by: Roi Dayan <roid@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next V2 2/3] net/mlx4_en: Refactor the XDP forwarding rings scheme
From: Saeed Mahameed @ 2016-11-01 11:57 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller
Cc: netdev, Eran Ben Elisha, Brenden Blanco, Alexei Starovoitov
In-Reply-To: <1478000186-5158-3-git-send-email-tariqt@mellanox.com>
On 11/01/2016 01:36 PM, Tariq Toukan wrote:
> Separately manage the two types of TX rings: regular ones, and XDP.
> Upon an XDP set, do not borrow regular TX rings and convert them
> into XDP ones, but allocate new ones, unless we hit the max number
> of rings.
> Which means that in systems with smaller #cores we will not consume
> the current TX rings for XDP, while we are still in the num TX limit.
>
> XDP TX rings counters are not shown in ethtool statistics.
> Instead, XDP counters will be added to the respective RX rings
> in a downstream patch.
>
> This has no performance implications.
>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* [PATCH] MAINTAINERS: Update MELLANOX MLX5 core VPI driver maintainers
From: Saeed Mahameed @ 2016-11-01 13:09 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Leon Romanovsky, Matan Barak, Saeed Mahameed
Add myself as a maintainer for mlx5 core driver as well.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4012c2f..53964ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8053,6 +8053,7 @@ F: drivers/infiniband/hw/mlx4/
F: include/linux/mlx4/
MELLANOX MLX5 core VPI driver
+M: Saeed Mahameed <saeedm@mellanox.com>
M: Matan Barak <matanb@mellanox.com>
M: Leon Romanovsky <leonro@mellanox.com>
L: netdev@vger.kernel.org
--
2.7.4
^ permalink raw reply related
* mlx5 bug in error path of mlx5e_open_channel()
From: Jesper Dangaard Brouer @ 2016-11-01 14:44 UTC (permalink / raw)
To: Saeed Mahameed, Tariq Toukan, Tariq Toukan, Eran Ben Elisha
Cc: brouer, netdev@vger.kernel.org
In driver mlx5 function mlx5e_open_channel() does not handle error
path correctly. (Tested by letting mlx5e_create_rq fail with -ENOMEM,
propagates to mlx5e_open_rq)
This first seemed related to commit b5503b994ed5 ("net/mlx5e: XDP TX
forwarding support"). As a failed call of mlx5e_open_rq() always
calls mlx5e_close_sq(&c->xdp_sq) on "xdp_sq" even-though a XDP program
is not attached.
Fixing this like:
@@ -1504,24 +1533,38 @@ static int mlx5e_open_channel(struct mlx5e_priv *priv, int ix,
c->xdp = !!priv->xdp_prog;
err = mlx5e_open_rq(c, &cparam->rq, &c->rq);
- if (err)
- goto err_close_xdp_sq;
+ if (err) {
+ if (c->xdp)
+ goto err_close_xdp_sq;
+ else
+ goto err_close_sqs;
+ }
The fix does remove one problem, but the error path still cause the
kernel to crash. This time it seems related to correct disabling of
NAPI polling before disabling the queues.
Now with another error:
XXX: call mlx5e_close_sqs(c)
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD 401e00067
PUD 40746e067 PMD 0
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: mlx5_core coretemp kvm_intel kvm irqbypass intel_cstate mxm_wmi i2c_i801 i2c_smbus]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc3-page_pool04+ #124
Hardware name: To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.10 05/12/2015
task: ffffffff81c0c4c0 task.stack: ffffffff81c00000
RIP: 0010:[<0000000000000000>] [< (null)>] (null)
RSP: 0018:ffff88041fa03e70 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff880401ecc000 RCX: 0000000000000005
RDX: 0000000000000000 RSI: ffff880401c38000 RDI: ffff880401ecc000
RBP: ffff88041fa03e88 R08: 0000000000000001 R09: ffff8803ea6a7230
R10: 0000000000000000 R11: 0000000000000040 R12: ffff880401c38000
R13: ffff880401ecf148 R14: 0000000000000040 R15: ffff880401ecc000
FS: 0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000040c468000 CR4: 00000000001406f0
Stack:
ffffffffa02e62e0 0000000000000000 0000000000000001 ffff88041fa03ed0
ffffffffa02e84c2 0000ffff00000000 ffffffff00000040 ffff880401ecf148
0000000000000040 0000000000000000 000000000000012c 0000000000000000
Call Trace:
<IRQ> [ 428.032595] [<ffffffffa02e62e0>] ? mlx5e_post_rx_wqes+0x80/0xc0 [mlx5_core]
[<ffffffffa02e84c2>] mlx5e_napi_poll+0xf2/0x530 [mlx5_core]
[<ffffffff8160e50c>] net_rx_action+0x1fc/0x350
[<ffffffff8172aff8>] __do_softirq+0xc8/0x2c6
[<ffffffff8106728e>] irq_exit+0xbe/0xd0
[<ffffffff8172ad44>] do_IRQ+0x54/0xd0
[<ffffffff8172937f>] common_interrupt+0x7f/0x7f
<EOI> [ 428.075157] [<ffffffff817285d0>] ? _raw_spin_unlock_irq+0x10/0x20
[<ffffffff81086db8>] ? finish_task_switch+0x78/0x200
[<ffffffff81722dfa>] __schedule+0x17a/0x670
[<ffffffff8172332d>] schedule+0x3d/0x90
[<ffffffff817236a5>] schedule_preempt_disabled+0x15/0x20
[<ffffffff810a560c>] cpu_startup_entry+0x12c/0x1c0
[<ffffffff8171c274>] rest_init+0x84/0x90
[<ffffffff81d95f14>] start_kernel+0x3fe/0x40b
[<ffffffff81d9528f>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d953f9>] x86_64_start_kernel+0x168/0x176
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP <ffff88041fa03e70>
CR2: 0000000000000000
---[ end trace a871278f0d0523ac ]---
Could you please look at fixing your driver?
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net-next v2] genetlink: fix error return code in genl_register_family()
From: Wei Yongjun @ 2016-11-01 14:45 UTC (permalink / raw)
To: David S . Miller, stephen hemminger, Tom Herbert,
Florian Westphal, Johannes Berg, pravin shelar, Tycho Andersen,
Matti Vaittinen
Cc: Wei Yongjun, netdev
In-Reply-To: <1477925583-7956-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return a negative error code from the idr_alloc() error handling
case instead of 0, as done elsewhere in this function.
Also fix the return value check of idr_alloc() since idr_alloc return
negative errors on failure, not zero.
Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
v1 -> v2: fix the return value check and return idr_alloc's err code
---
net/netlink/genetlink.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index caf04d7..bbd3bff 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -362,8 +362,10 @@ int genl_register_family(struct genl_family *family)
family->id = idr_alloc(&genl_fam_idr, family,
start, end + 1, GFP_KERNEL);
- if (!family->id)
+ if (family->id < 0) {
+ err = family->id;
goto errout_locked;
+ }
err = genl_validate_assign_mc_groups(family);
if (err)
^ permalink raw reply related
* Re: [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
From: David Miller @ 2016-11-01 14:50 UTC (permalink / raw)
To: dongli.zhang
Cc: JBeulich, boris.ostrovsky, jgross, netdev, xen-devel,
david.vrabel, linux-kernel
In-Reply-To: <8eb8496b-16d7-4be7-bc43-6ff3f2b8708e@default>
From: Dongli Zhang <dongli.zhang@oracle.com>
Date: Mon, 31 Oct 2016 21:46:09 -0700 (PDT)
> David, I am very sorry for this error and I will be careful the next time.
> Would you please let me know if I should resend a new patch or an incremental
> based on previous one at
> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git?
Incremental, please.
^ permalink raw reply
* Re: [net-next 00/22][pull request] 40GbE Intel Wired LAN Driver Updates 2016-10-31
From: David Miller @ 2016-11-01 14:59 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1477952992-125662-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 31 Oct 2016 15:29:30 -0700
> This series contains updates to i40e and i40evf.
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/2] qed*: Fixes to "Allow unicast filtering"
From: David Miller @ 2016-11-01 15:00 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <1477945614-29133-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Mon, 31 Oct 2016 22:26:52 +0200
> Commit 7b7e70f979e3 ("qed*: Allow unicast filtering") introduced several
> issues in driver. This series is intended to address and fix those.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: Let's do P4
From: John Fastabend @ 2016-11-01 15:03 UTC (permalink / raw)
To: Jamal Hadi Salim, Jiri Pirko, netdev
Cc: davem, tgraf, roopa, jakub.kicinski, simon.horman, ast, daniel,
prem, hannes, jbenc, tom, mattyk, idosch, eladr, yotamg, nogahf,
ogerlitz, linville, andy, f.fainelli, dsa, vivien.didelot, andrew,
ivecera
In-Reply-To: <0c0b9176-c768-25e3-1fc7-cd2b4a8e3d31@mojatatu.com>
On 16-11-01 04:57 AM, Jamal Hadi Salim wrote:
>
> I am in travel mode so havent read the huge blast of
> emails (and i am probably taking this email out of
> the already discussed topics). I will try to catchup later.
>
> Simple question (same chat I had with Prem at netdev1.2):
> What is it that can be expressed by P4 that cant be expressed
> with the (userspace) tc grammar? If any i would say the diff
> is very small.
Taking eBPF into account its small if it at all as you note. But,
the real problem is mapping it onto hardware. Pushing eBPF onto
pipeline ASICs is difficult and even when its done it is extremely
fragile as pointed out by folks. cls_u32 works OK IMO although the
mapping between hardware tables and software tables is a bit of an art.
cls_flower has no notion of tables or arbitrary actions and
continuations.
Also P4 is about programming the hardware parse graph, table layout,
etc. and doing this from 'tc' requires drivers to generate very
low level hardware ucode typically or a cpu on the board to process
to the generation from high level commands. At least those are the
only two options I see. I suspect the end result is the reprogramming
of these flexible devices is done out of band via firmware uploading.
> Is there something we need to add to kernel tc that will complete
> the policy graph needed to express a P4 context?
> Essentially if one can express the tc policies with p4 DSL then
> that could become another frontend to tc (and a p4 component could
> be implemented in classic tc action/classifier or ebpf).
per above runtime programming perhaps, configuration of the device
unlikely.
>
> I think trying to express p4 at the coarse granularity it offers
> using ebpf is challenging.
Nope its actually much easier than "compiling" p4 for hardware IMO.
Mapping P4 onto an instruction set vs mapping it onto some of the
esoteric features of CAM based parsing logic, other non-standard ALU
designs, etc. A lot of the hardware architecture is bent around pushing
32+ ports of 100Gbps through the system which creates some interesting
designs. Caveat being I'm a software guy and hardware folks might have
a different take. I've not found any part of the spec for example that
can not be mapped onto LLVM-IR.
Also there exist a handful of proof points of p4 to ebpf code on the
Internet. We should get a LLVM frontend here shortly.
>
> cheers,
> jamal
>
> On 16-10-29 03:53 AM, Jiri Pirko wrote:
>> Hi all.
>>
>> The network world is divided into 2 general types of hw:
>> 1) network ASICs - network specific silicon, containing things like TCAM
>> These ASICs are suitable to be programmed by P4.
>> 2) network processors - basically a general purpose CPUs
>> These processors are suitable to be programmed by eBPF.
>>
>> I believe that by now, the most people came to a conclusion that it is
>> very difficult to handle both types by either P4 or eBPF. And since
>> eBPF is part of the kernel, I would like to introduce P4 into kernel
>> as well. Here's a plan:
>>
>> 1) Define P4 intermediate representation
>> I cannot imagine loading P4 program (c-like syntax text file) into
>> kernel as is. That means that as the first step, we need find some
>> intermediate representation. I can imagine someting in a form of AST,
>> call it "p4ast". I don't really know how to do this exactly though,
>> it's just an idea.
>>
>> In the end there would be a userspace precompiler for this:
>> $ makep4ast example.p4 example.ast
>>
>> 2) Implement p4ast in-kernel interpreter
>> A kernel module which takes a p4ast and emulates the pipeline.
>> This can be implemented from scratch. Or, p4ast could be compiled
>> to eBPF. I know there are already couple of p4>eBPF compilers.
>> Not sure how feasible it would be to put this compiler in kernel.
>>
>> 3) Expose the p4ast in-kernel interpreter to userspace
>> As the easiest way I see in to introduce a new TC classifier cls_p4.
>>
>> This can work in a very similar way cls_bpf is:
>> $ tc filter add dev eth0 ingress p4 da ast example.ast
>>
>> The TC cls_p4 will be also used for runtime table manipulation.
>>
>> 4) Offload p4ast programs into hardware
>> The same p4ast program representation will be passed down
>> to drivers via existing TC offloading way - ndo_setup_tc.
>> Drivers will then parse it and setup the hardware
>> accordingly. Driver will also have possibility to error out
>> in case it does not support some requested feature.
>>
>> Thoughts? Ideas?
>>
>> Thanks,
>> Jiri
>>
>
^ permalink raw reply
* Re: [PATCH net-next 00/14] cleanups and RX path rewrite
From: David Miller @ 2016-11-01 15:05 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev
In-Reply-To: <1477946602-19644-1-git-send-email-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 31 Oct 2016 20:43:08 +0000
> This series lays groundwork for upcoming XDP support by updating
> the RX path not to pre-allocate sk_buffs. I start with few
> cleanups, removal of NFP3200-related code being the most significant.
> Patch 7 moves to alloc_frag() and build_skb() APIs. Again, a number
> of small cleanups follow. The set ends with adding support for
> different number of RX and TX rings.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Jakub Sitnicki @ 2016-11-01 15:13 UTC (permalink / raw)
To: David Miller; +Cc: tom, netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161031.151534.329043104568805244.davem@davemloft.net>
On Mon, Oct 31, 2016 at 07:15 PM GMT, David Miller wrote:
> From: Jakub Sitnicki <jkbs@redhat.com>
> Date: Sun, 30 Oct 2016 14:03:11 +0100
>
>> 2) ensure the flow labels used in both directions are the same (either
>> reflected by one side, or fixed, e.g. not used and set to 0), so that
>> the 4-tuple we hash over when forwarding, <src addr, dst addr, flow
>> label, next hdr>, is the same both ways, modulo the order of
>> addresses.
>
> Even Linux, by default, does not do reflection.
>
> See the flowlabel_consistency sysctl, which we set by default to '1'.
Yes, unfortunately, if Linux-based hosts are used as sending/receiving
IPv6, ICMP error forwarding will not work out of the box. Users will be
burdened with adjusting the runtime network stack config, as you point
out, or otherwise instructing the apps to set the flow label,
e.g. traceroute6 -I <flow label> ...
> I think we need to think a lot more about how systems actually set and
> use flowlabels.
The only alternative I can think of, only for ECMP routing, is having a
toggle option that would exclude the flow label from the input to the
multipath hash.
We would be sacrificing the entropy that potentially comes from hashing
over the flow label, leading to better flow balancing. But we wouldn't
be making IPv6 multipath routing any worse than IPv4 is in that regard.
And user-space apps wouldn't need to resort to reflecting/setting the
label, just like with IPv4.
Is that something that you would consider a viable option?
> Also, one issue I also had with this series was adding a new member
> to the flow label. Is it possible to implement this like the ipv4
> side did, by simply passing a new parameter around to the necessary
> functions?
This was my initial approach, i.e. to mimic the IPv4 and pass the
multipath hash down the call chain via a parameter. However, I gave up
on it, thinking it will cause too much disturbance in the involved
functions' interfaces, when I realized that one of the call paths the
multipath hash would have to also be passed through is:
ip6_route_input_lookup
fib6_rule_lookup
fib_rules_lookup
fib6_rule_action
ip6_pol_route_input
To be honest, I was thinking that if extending flowi6 structure would
find acceptance, then maybe the new member could be at some point moved
to flowi_common and also used by IPv4 to avoid parameter passing there
as well.
Thanks,
Jakub
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Roopa Prabhu @ 2016-11-01 15:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ido Schimmel, netdev, davem, jiri, mlxsw, dsa, nikolay, andy,
vivien.didelot, andrew, f.fainelli, alexander.h.duyck, kuznet,
jmorris, yoshfuji, kaber, Ido Schimmel
In-Reply-To: <1478009999.7065.334.camel@edumazet-glaptop3.roam.corp.google.com>
On 11/1/16, 7:19 AM, Eric Dumazet wrote:
> On Tue, 2016-11-01 at 00:57 +0200, Ido Schimmel wrote:
>> On Mon, Oct 31, 2016 at 02:24:06PM -0700, Eric Dumazet wrote:
>>> How well will this work for large FIB tables ?
>>>
>>> Holding rtnl while sending thousands of skb will prevent consumers to
>>> make progress ?
>> Can you please clarify what do you mean by "while sending thousands of
>> skb"? This patch doesn't generate notifications to user space, but
>> instead invokes notification routines inside the kernel. I probably
>> misunderstood you.
>>
>> Are you suggesting this be done using RCU instead? Well, there are a
>> couple of reasons why I took RTNL here:
>>
> No, I do not believe RCU is wanted here, in control path where we might
> sleep anyway.
>
>> 1) The FIB notification chain is blocking, so listeners are expected to
>> be able to sleep. This isn't possible if we use RCU. Note that this
>> chain is mainly useful for drivers that reflect the FIB table into a
>> capable device and hardware operations usually involve sleeping.
>>
>> 2) The insertion of a single route is done with RTNL held. I didn't want
>> to differentiate between both cases. This property is really useful for
>> listeners, as they don't need to worry about locking in writer-side.
>> Access to data structs is serialized by RTNL.
> My concern was that for large iterations, you might hold RTNL and/or
> current cpu for hundred of ms or even seconds...
>
I have the same concern as Eric here.
I understand why you need it, but can the driver request for an initial dump and that
dump be made more efficient somehow ie not hold rtnl for the whole dump ?.
instead of making the fib notifier registration code doing it.
these routing table sizes can be huge and an analogy for this in user-space:
We do request a netlink dump of routing tables at initialization (on driver starts or resets)...
but, existing netlink routing table dumps for that scale don't hold rtnl for the whole dump.
The dump is split into multiple responses to the user and hence it does not starve other rtnl users.
In-fact I don't think netlink routing table dumps from user-space hold rtnl_lock for the whole dump.
IIRC this was done to allow route add/dels to be allowed in parallel for performance reasons.
(I will need to double check to confirm this).
^ permalink raw reply
* Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
From: Lorenzo Colitti @ 2016-11-01 15:25 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Daniel Mack, Pablo Neira Ayuso, htejun, ast,
David Miller, kafai, Florian Westphal, harald,
netdev@vger.kernel.org, Sargun Dhillon, cgroups
In-Reply-To: <581506C4.30902@iogearbox.net>
On Sun, Oct 30, 2016 at 5:29 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> Fwiw, not sure if swapping brings much, even after netfilter there could
> be complex processing that would potentially drop, mangle, redirect, etc
> from tc layer (egress or from qdisc itself). But also at even lower layers
I agree lots of stuff can still happen after the netfilter hooks have
finished. But it seems to me that netfilter hooks are more flexible
and have more access to more data (L2 headers, output devices,
conntrack state entries, etc. etc.) than this hook. So it seems to me
that this hook would be more useful if it ran after netfilter on
egress.
That way, if you want to modify the packet or do something
sophisticated in netfilter, you can still use the eBPF hook on the
results of that operation, and if you don't want to run netfilter, you
can write netfilter rules to skip the packet (and maybe still fix it
up later, perhaps in another netfilter chain).
^ permalink raw reply
* [PATCH net-next] mlxsw: switchib: Remove unused including <generated/utsrelease.h>
From: Wei Yongjun @ 2016-11-01 15:14 UTC (permalink / raw)
To: Jiri Pirko, Ido Schimmel; +Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Remove including <generated/utsrelease.h> that don't need it.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/mellanox/mlxsw/switchib.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/switchib.c b/drivers/net/ethernet/mellanox/mlxsw/switchib.c
index ec0b27e..1552594 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/switchib.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/switchib.c
@@ -43,7 +43,6 @@
#include <linux/skbuff.h>
#include <linux/if_vlan.h>
#include <net/switchdev.h>
-#include <generated/utsrelease.h>
#include "pci.h"
#include "core.h"
^ permalink raw reply related
* Re: Let's do P4
From: John Fastabend @ 2016-11-01 15:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: Alexei Starovoitov, Thomas Graf, Jakub Kicinski, netdev, davem,
jhs, roopa, simon.horman, ast, daniel, prem, hannes, jbenc, tom,
mattyk, idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera,
Maciej Żenczykowski
In-Reply-To: <20161101084643.GA1707@nanopsycho.orion>
[...]
>>> P4 is ment to program programable hw, not fixed pipeline.
>>>
>>
>> I'm guessing there are no upstream drivers at the moment that support
>> this though right? The rocker universe bits though could leverage this.
>
> mlxsw. But this is naturaly not implemented yet, as there is no
> infrastructure.
Really? What is re-programmable?
Can the parse graph support arbitrary parse graph?
Can the table topology be reconfigured?
Can new tables be created?
What about "new" actions being defined at configuration time?
Or is this just the normal TCAM configuration of defining key widths and
fields.
>
>
>>
>>>
>>>>
>>>>>
>>>>>> since I cannot see how one can put the whole p4 language compiler
>>>>>> into the driver, so this last step of p4ast->hw, I presume, will be
>>>>>> done by firmware, which will be running full compiler in an embedded cpu
>>>>>
>>>>> In case of mlxsw, that compiler would be in driver.
>>>>>
>>>>>
>>>>>> on the switch. To me that's precisely the kernel bypass, since we won't
>>>>>> have a clue what HW capabilities actually are and won't be able to fine
>>>>>> grain control them.
>>>>>> Please correct me if I'm wrong.
>>>>>
>>>>> You are wrong. By your definition, everything has to be figured out in
>>>>> driver and FW does nothing. Otherwise it could do "something else" and
>>>>> that would be a bypass? Does not make any sense to me whatsoever.
>>>>>
>>>>>
>>>>>>
>>>>>>> Plus the thing I cannot imagine in the model you propose is table fillup.
>>>>>>> For ebpf, you use maps. For p4 you would have to have a separate HW-only
>>>>>>> API. This is very similar to the original John's Flow-API. And therefore
>>>>>>> a kernel bypass.
>>>>>>
>>>>>> I think John's flow api is a better way to expose mellanox switch capabilities.
>>>>>
>>>>> We are under impression that p4 suits us nicely. But it is not about
>>>>> us, it is about finding the common way to do this.
>>>>>
>>>>
>>>> I'll just poke at my FlowAPI question again. For fixed ASICS what is
>>>> the Flow-API missing. We have a few proof points that show it is both
>>>> sufficient and usable for the handful of use cases we care about.
>>>
>>> Yeah, it is most probably fine. Even for flex ASICs to some point. The
>>> question is how it stands comparing to other alternatives, like p4
>>>
>>
>> Just to be clear the Flow-API _was_ generated from the initial P4 spec.
>> The header files and tools used with it were autogenerated ("compiled"
>> in a loose sense) from the P4 program. The piece I never exposed
>> was the set_* operations to reconfigure running systems. I'm not sure
>> how valuable this is in practice though.
>>
>> Also there is a P4-16 spec that will be released shortly that is more
>> flexible and also more complex.
>
> Would it be able to easily extend the Flow-API to include the changes?
>
P4-16 will allow externs, "functions" to execute in the control flow and
possibly inside the parse graph. None of this was considered in the
Flow-API. So none of this is supported.
I still have the question are you trying to push the "programming" of
the device via 'tc' or just the runtime configuration of tables? If it
is just runtime Flow-API is sufficient IMO. If its programming the
device using the complete P4-16 spec than no its not sufficient. But
I don't believe vendors will expose the complete programmability of the
device in the driver, this is going to look more like a fw update than
a runtime change at least on the devices I'm aware of.
>
>>
>>>
>>>>
>>>>>
>>>>>> I also think it's not fair to call it 'bypass'. I see nothing in it
>>>>>> that justify such 'swear word' ;)
>>>>>
>>>>> John's Flow-API was a kernel bypass. Why? It was a API specifically
>>>>> designed to directly work with HW tables, without kernel being involved.
>>>>
>>>> I don't think that is a fair definition of HW bypass. The SKIP_SW flag
>>>> does exactly that for 'tc' based offloads and it was not rejected.
>>>
>>> No, no, no. You still have possibility to do the same thing in kernel,
>>> same functionality, with the same API. That is a big difference.
>>>
>>>
>>>>
>>>> The _real_ reason that seems to have fallen out of this and other
>>>> discussion is the Flow-API didn't provide an in-kernel translation into
>>>> an emulated patch. Note we always had a usermode translation to eBPF.
>>>> A secondary reason appears to be overhead of adding yet another netlink
>>>> family.
>>>
>>> Yeah. Maybe you remember, back then when Flow-API was being discussed,
>>> I suggested to wrap it under TC as cls_xflows and cls_xflowsaction of
>>> some sort and do in-kernel datapath implementation. I believe that after
>>> that, it would be acceptable.
>>>
>>
>> As I understand the thread here that is exactly the proposal here right?
>> With a discussion around if the structures/etc are sufficient or any
>> alternative representations exist.
>
> Might be the way, yes. But I fear that with other p4 extensions this
> might not be easy to align with. Therefore I though about something more
> generic, like the p4ast.
>
Same question as above are we _really_ talking about pushing the entire
programmability of the device via 'tc'. If so we need to have a vendor
say they will support and implement this?
>
>>
>>>
>>>>
>>>>>
>>>>>
>>>>>> The goal of flow api was to expose HW features to user space, so that
>>>>>> user space can program it. For something simple as mellanox switch
>>>>>> asic it fits perfectly well.
>>>>>
>>>>> Again, this is not mlx-asic-specific. And again, that is a kernel bypass.
>>>>>
>>>>>
>>>>>> Unless I misunderstand the bigger goal of this discussion and it's
>>>>>> about programming ezchip devices.
>>>>>
>>>>> No. For network processors, I believe that BPF is nicely offloadable, no
>>>>> need to do the excercise for that.
>>>>>
>>>>>
>>>>>>
>>>>>> If the goal is to model hw tcam in the linux kernel then just introduce
>>>>>> tcam bpf map type. It will be dog slow in user space, but it will
>>>>>> match exactly what is happnening in the HW and user space can make
>>>>>> sensible trade-offs.
>>>>>
>>>>> No, you got me completely wrong. This is not about the TCAM. This is
>>>>> about differences in the 2 words (p4/bpf).
>>>>> Again, for "p4-ish" devices, you have to translate BPF. And as you
>>>>> noted, it's an instruction set. Very hard if not impossible to parse in
>>>>> order to get back the original semantics.
>>>>>
>>>>
>>>> I think in this discussion "p4-ish" devices means devices with multiple
>>>> tables in a pipeline? Not devices that have programmable/configurable
>>>> pipelines right? And if we get to talking about reconfigurable devices
>>>> I believe this should be done out of band as it typically means
>>>> reloading some ucode, etc.
>>>
>>> I'm talking about both. But I think we should focus on reconfigurable
>>> ones, as we probably won't see that much fixed ones in the future.
>>>
>>
>> hmm maybe but the 10/40/100Gbps devices are going to be around for some
>> time. So we need to ensure these work well.
>
> Yes, but I would like to emphasize, if we are defining new api
> the primary focus should be on new devices.
>
>
What device though. Back to mlxsw question about actually supporting
this stuff.
^ 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