* [PATCH net-next v2 13/16] tipc: create TIPC_DISCONNECTING 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_DISCONNECTING in
sk_state. TIPC_DISCONNECTING is replacing the socket connection status
update using SS_DISCONNECTING.
TIPC_DISCONNECTING is set for connection oriented sockets at:
- tipc_shutdown()
- connection probe timeout
- when we receive an error message on the connection.
There is no functional change in this commit.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
---
v2: set TIPC_DISCONNECTING to TCP_CLOSE_WAIT.
---
net/tipc/socket.c | 39 ++++++++++++++++++++++++---------------
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index b14dd2549980..a48c0c0676cf 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -54,6 +54,7 @@ enum {
TIPC_LISTEN = TCP_LISTEN,
TIPC_ESTABLISHED = TCP_ESTABLISHED,
TIPC_OPEN = TCP_CLOSE,
+ TIPC_DISCONNECTING = TCP_CLOSE_WAIT,
};
/**
@@ -362,10 +363,14 @@ static int tipc_set_sk_state(struct sock *sk, int state)
break;
case TIPC_ESTABLISHED:
if (oldstate == SS_CONNECTING ||
- oldstate == SS_UNCONNECTED ||
oldsk_state == TIPC_OPEN)
res = 0;
break;
+ case TIPC_DISCONNECTING:
+ if (oldstate == SS_CONNECTING ||
+ oldsk_state == TIPC_ESTABLISHED)
+ res = 0;
+ break;
}
if (!res)
@@ -621,13 +626,14 @@ static int tipc_getname(struct socket *sock, struct sockaddr *uaddr,
int *uaddr_len, int peer)
{
struct sockaddr_tipc *addr = (struct sockaddr_tipc *)uaddr;
- struct tipc_sock *tsk = tipc_sk(sock->sk);
+ struct sock *sk = sock->sk;
+ struct tipc_sock *tsk = tipc_sk(sk);
struct tipc_net *tn = net_generic(sock_net(sock->sk), tipc_net_id);
memset(addr, 0, sizeof(*addr));
if (peer) {
if ((sock->state != SS_CONNECTED) &&
- ((peer != 2) || (sock->state != SS_DISCONNECTING)))
+ ((peer != 2) || (sk->sk_state != TIPC_DISCONNECTING)))
return -ENOTCONN;
addr->addr.id.ref = tsk_peer_port(tsk);
addr->addr.id.node = tsk_peer_node(tsk);
@@ -693,6 +699,9 @@ static unsigned int tipc_poll(struct file *file, struct socket *sock,
(!skb_queue_empty(&sk->sk_receive_queue)))
mask |= (POLLIN | POLLRDNORM);
break;
+ case TIPC_DISCONNECTING:
+ mask = (POLLIN | POLLRDNORM | POLLHUP);
+ break;
case TIPC_LISTEN:
if (!skb_queue_empty(&sk->sk_receive_queue))
mask |= (POLLIN | POLLRDNORM);
@@ -1028,7 +1037,7 @@ static int tipc_wait_for_sndpkt(struct socket *sock, long *timeo_p)
int err = sock_error(sk);
if (err)
return err;
- if (sock->state == SS_DISCONNECTING)
+ if (sk->sk_state == TIPC_DISCONNECTING)
return -EPIPE;
else if (sock->state != SS_CONNECTED)
return -ENOTCONN;
@@ -1098,7 +1107,7 @@ static int __tipc_send_stream(struct socket *sock, struct msghdr *m, size_t dsz)
return -EMSGSIZE;
if (unlikely(sock->state != SS_CONNECTED)) {
- if (sock->state == SS_DISCONNECTING)
+ if (sk->sk_state == TIPC_DISCONNECTING)
return -EPIPE;
else
return -ENOTCONN;
@@ -1626,7 +1635,7 @@ static bool filter_connect(struct tipc_sock *tsk, struct sk_buff *skb)
return false;
if (unlikely(msg_errcode(hdr))) {
- sock->state = SS_DISCONNECTING;
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
/* Let timer expire on it's own */
tipc_node_remove_conn(net, tsk_peer_node(tsk),
tsk->portid);
@@ -1641,13 +1650,13 @@ static bool filter_connect(struct tipc_sock *tsk, struct sk_buff *skb)
return false;
if (unlikely(msg_errcode(hdr))) {
- sock->state = SS_DISCONNECTING;
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
sk->sk_err = ECONNREFUSED;
return true;
}
if (unlikely(!msg_isdata(hdr))) {
- sock->state = SS_DISCONNECTING;
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
sk->sk_err = EINVAL;
return true;
}
@@ -1674,6 +1683,7 @@ static bool filter_connect(struct tipc_sock *tsk, struct sk_buff *skb)
switch (sk->sk_state) {
case TIPC_OPEN:
+ case TIPC_DISCONNECTING:
break;
case TIPC_LISTEN:
/* Accept only SYN message */
@@ -2195,9 +2205,7 @@ static int tipc_shutdown(struct socket *sock, int how)
lock_sock(sk);
- switch (sock->state) {
- case SS_CONNECTING:
- case SS_CONNECTED:
+ if (sock->state == SS_CONNECTING || sock->state == SS_CONNECTED) {
restart:
dnode = tsk_peer_node(tsk);
@@ -2218,11 +2226,12 @@ static int tipc_shutdown(struct socket *sock, int how)
if (skb)
tipc_node_xmit_skb(net, skb, dnode, tsk->portid);
}
- sock->state = SS_DISCONNECTING;
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
tipc_node_remove_conn(net, dnode, tsk->portid);
- /* fall through */
+ }
- case SS_DISCONNECTING:
+ switch (sk->sk_state) {
+ case TIPC_DISCONNECTING:
/* Discard any unreceived messages */
__skb_queue_purge(&sk->sk_receive_queue);
@@ -2258,7 +2267,7 @@ static void tipc_sk_timeout(unsigned long data)
if (tsk->probe_unacked) {
if (!sock_owned_by_user(sk)) {
- sk->sk_socket->state = SS_DISCONNECTING;
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
tipc_node_remove_conn(sock_net(sk), tsk_peer_node(tsk),
tsk_peer_port(tsk));
sk->sk_state_change(sk);
--
2.1.4
^ permalink raw reply related
* [PATCH net-next v2 14/16] tipc: remove SS_DISCONNECTING 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 replace the references to SS_DISCONNECTING with
the combination of sk_state TIPC_DISCONNECTING and flags set in
sk_shutdown.
We introduce a new function _tipc_shutdown(), which provides
the common code required by tipc_release() and tipc_shutdown().
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
---
v2: introduce __tipc_shutdown() to avoid code duplication.
replace the TIPC_CLOSING state in v1 with sk_shutdown flag.
---
net/tipc/socket.c | 132 +++++++++++++++++++++---------------------------------
1 file changed, 52 insertions(+), 80 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index a48c0c0676cf..e732b1fe7eab 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -442,6 +442,7 @@ static int tipc_sk_create(struct net *net, struct socket *sock,
}
msg_set_origport(msg, tsk->portid);
setup_timer(&sk->sk_timer, tipc_sk_timeout, (unsigned long)tsk);
+ sk->sk_shutdown = 0;
sk->sk_backlog_rcv = tipc_backlog_rcv;
sk->sk_rcvbuf = sysctl_tipc_rmem[1];
sk->sk_data_ready = tipc_data_ready;
@@ -470,6 +471,44 @@ static void tipc_sk_callback(struct rcu_head *head)
sock_put(&tsk->sk);
}
+/* Caller should hold socket lock for the socket. */
+static void __tipc_shutdown(struct socket *sock, int error)
+{
+ struct sock *sk = sock->sk;
+ struct tipc_sock *tsk = tipc_sk(sk);
+ struct net *net = sock_net(sk);
+ u32 dnode = tsk_peer_node(tsk);
+ struct sk_buff *skb;
+
+ /* Reject all unreceived messages, except on an active connection
+ * (which disconnects locally & sends a 'FIN+' to peer).
+ */
+ while ((skb = __skb_dequeue(&sk->sk_receive_queue)) != NULL) {
+ if (TIPC_SKB_CB(skb)->bytes_read) {
+ kfree_skb(skb);
+ } else {
+ if (!tipc_sk_type_connectionless(sk) &&
+ sk->sk_state != TIPC_DISCONNECTING) {
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
+ tipc_node_remove_conn(net, dnode, tsk->portid);
+ }
+ tipc_sk_respond(sk, skb, error);
+ }
+ }
+ if (sk->sk_state != TIPC_DISCONNECTING) {
+ skb = tipc_msg_create(TIPC_CRITICAL_IMPORTANCE,
+ TIPC_CONN_MSG, SHORT_H_SIZE, 0, dnode,
+ tsk_own_node(tsk), tsk_peer_port(tsk),
+ tsk->portid, error);
+ if (skb)
+ tipc_node_xmit_skb(net, skb, dnode, tsk->portid);
+ if (!tipc_sk_type_connectionless(sk)) {
+ tipc_node_remove_conn(net, dnode, tsk->portid);
+ tipc_set_sk_state(sk, TIPC_DISCONNECTING);
+ }
+ }
+}
+
/**
* tipc_release - destroy a TIPC socket
* @sock: socket to destroy
@@ -489,10 +528,7 @@ static void tipc_sk_callback(struct rcu_head *head)
static int tipc_release(struct socket *sock)
{
struct sock *sk = sock->sk;
- struct net *net;
struct tipc_sock *tsk;
- struct sk_buff *skb;
- u32 dnode;
/*
* Exit if socket isn't fully initialized (occurs when a failed accept()
@@ -501,46 +537,16 @@ static int tipc_release(struct socket *sock)
if (sk == NULL)
return 0;
- net = sock_net(sk);
tsk = tipc_sk(sk);
lock_sock(sk);
- /*
- * Reject all unreceived messages, except on an active connection
- * (which disconnects locally & sends a 'FIN+' to peer)
- */
- dnode = tsk_peer_node(tsk);
- while (sock->state != SS_DISCONNECTING) {
- skb = __skb_dequeue(&sk->sk_receive_queue);
- if (skb == NULL)
- break;
- if (TIPC_SKB_CB(skb)->bytes_read)
- kfree_skb(skb);
- else {
- if ((sock->state == SS_CONNECTING) ||
- (sock->state == SS_CONNECTED)) {
- sock->state = SS_DISCONNECTING;
- tipc_node_remove_conn(net, dnode, tsk->portid);
- }
- tipc_sk_respond(sk, skb, TIPC_ERR_NO_PORT);
- }
- }
-
+ __tipc_shutdown(sock, TIPC_ERR_NO_PORT);
+ sk->sk_shutdown = SHUTDOWN_MASK;
tipc_sk_withdraw(tsk, 0, NULL);
sk_stop_timer(sk, &sk->sk_timer);
tipc_sk_remove(tsk);
- if (tipc_sk_connected(sk)) {
- skb = tipc_msg_create(TIPC_CRITICAL_IMPORTANCE,
- TIPC_CONN_MSG, SHORT_H_SIZE, 0, dnode,
- tsk_own_node(tsk), tsk_peer_port(tsk),
- tsk->portid, TIPC_ERR_NO_PORT);
- if (skb)
- tipc_node_xmit_skb(net, skb, dnode, tsk->portid);
- tipc_node_remove_conn(net, dnode, tsk->portid);
- }
/* Reject any messages that accumulated in backlog queue */
- sock->state = SS_DISCONNECTING;
release_sock(sk);
call_rcu(&tsk->rcu, tipc_sk_callback);
@@ -678,6 +684,11 @@ static unsigned int tipc_poll(struct file *file, struct socket *sock,
sock_poll_wait(file, sk_sleep(sk), wait);
+ if (sk->sk_shutdown & RCV_SHUTDOWN)
+ mask |= POLLRDHUP | POLLIN | POLLRDNORM;
+ if (sk->sk_shutdown == SHUTDOWN_MASK)
+ mask |= POLLHUP;
+
switch ((int)sock->state) {
case SS_CONNECTED:
if (!tsk->link_cong && !tsk_conn_cong(tsk))
@@ -687,9 +698,6 @@ static unsigned int tipc_poll(struct file *file, struct socket *sock,
if (!skb_queue_empty(&sk->sk_receive_queue))
mask |= (POLLIN | POLLRDNORM);
break;
- case SS_DISCONNECTING:
- mask = (POLLIN | POLLRDNORM | POLLHUP);
- break;
default:
switch (sk->sk_state) {
case TIPC_OPEN:
@@ -882,7 +890,7 @@ static int tipc_wait_for_sndmsg(struct socket *sock, long *timeo_p)
int err = sock_error(sk);
if (err)
return err;
- if (sock->state == SS_DISCONNECTING)
+ if (sk->sk_shutdown & SEND_SHUTDOWN)
return -EPIPE;
if (!*timeo_p)
return -EAGAIN;
@@ -1335,7 +1343,7 @@ static int tipc_wait_for_rcvmsg(struct socket *sock, long *timeop)
for (;;) {
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
if (timeo && skb_queue_empty(&sk->sk_receive_queue)) {
- if (sock->state == SS_DISCONNECTING) {
+ if (sk->sk_shutdown & RCV_SHUTDOWN) {
err = -ENOTCONN;
break;
}
@@ -1676,9 +1684,6 @@ 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;
-
- case SS_DISCONNECTING:
- break;
}
switch (sk->sk_state) {
@@ -2191,13 +2196,6 @@ static int tipc_accept(struct socket *sock, struct socket *new_sock, int flags)
static int tipc_shutdown(struct socket *sock, int how)
{
struct sock *sk = sock->sk;
- struct net *net = sock_net(sk);
- struct tipc_sock *tsk = tipc_sk(sk);
- struct sk_buff *skb;
- u32 dnode = tsk_peer_node(tsk);
- u32 dport = tsk_peer_port(tsk);
- u32 onode = tipc_own_addr(net);
- u32 oport = tsk->portid;
int res;
if (how != SHUT_RDWR)
@@ -2205,43 +2203,17 @@ static int tipc_shutdown(struct socket *sock, int how)
lock_sock(sk);
- if (sock->state == SS_CONNECTING || sock->state == SS_CONNECTED) {
-
-restart:
- dnode = tsk_peer_node(tsk);
-
- /* Disconnect and send a 'FIN+' or 'FIN-' message to peer */
- skb = __skb_dequeue(&sk->sk_receive_queue);
- if (skb) {
- if (TIPC_SKB_CB(skb)->bytes_read) {
- kfree_skb(skb);
- goto restart;
- }
- tipc_sk_respond(sk, skb, TIPC_CONN_SHUTDOWN);
- } else {
- skb = tipc_msg_create(TIPC_CRITICAL_IMPORTANCE,
- TIPC_CONN_MSG, SHORT_H_SIZE,
- 0, dnode, onode, dport, oport,
- TIPC_CONN_SHUTDOWN);
- if (skb)
- tipc_node_xmit_skb(net, skb, dnode, tsk->portid);
- }
- tipc_set_sk_state(sk, TIPC_DISCONNECTING);
- tipc_node_remove_conn(net, dnode, tsk->portid);
- }
-
- switch (sk->sk_state) {
- case TIPC_DISCONNECTING:
+ __tipc_shutdown(sock, TIPC_CONN_SHUTDOWN);
+ sk->sk_shutdown = SEND_SHUTDOWN;
+ if (sk->sk_state == TIPC_DISCONNECTING) {
/* Discard any unreceived messages */
__skb_queue_purge(&sk->sk_receive_queue);
/* Wake up anyone sleeping in poll */
sk->sk_state_change(sk);
res = 0;
- break;
-
- default:
+ } else {
res = -ENOTCONN;
}
--
2.1.4
^ permalink raw reply related
* [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
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