* [PATCH 2/2] sctp: delay calls to sk_data_ready() as much as possible
From: Marcelo Ricardo Leitner @ 2016-03-29 13:49 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
In-Reply-To: <cover.1459259208.git.marcelo.leitner@gmail.com>
Currently processing of multiple chunks in a single SCTP packet leads to
multiple calls to sk_data_ready, causing multiple wake up signals which
are costy and doesn't make it wake up any faster.
With this patch it will note that the wake up is pending and will do it
before leaving the state machine interpreter, latest place possible to
do it realiably and cleanly.
Note that sk_data_ready events are not dependent on asocs, unlike waking
up writers.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
include/net/sctp/structs.h | 3 ++-
net/sctp/sm_sideeffect.c | 5 +++++
net/sctp/ulpqueue.c | 4 ++--
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 1a6a626904bba4223b7921bbb4be41c2550271a7..21cb11107e378b4da1e7efde22fab4349496e35a 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -217,7 +217,8 @@ struct sctp_sock {
v4mapped:1,
frag_interleave:1,
recvrcvinfo:1,
- recvnxtinfo:1;
+ recvnxtinfo:1,
+ pending_data_ready:1;
atomic_t pd_mode;
/* Receive to here while partial delivery is in effect. */
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 7fe56d0acabf66cfd8fe29dfdb45f7620b470ac7..e7042f9ce63b0cfca50cae252f51b60b68cb5731 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1742,6 +1742,11 @@ out:
error = sctp_outq_uncork(&asoc->outqueue, gfp);
} else if (local_cork)
error = sctp_outq_uncork(&asoc->outqueue, gfp);
+
+ if (sctp_sk(ep->base.sk)->pending_data_ready) {
+ ep->base.sk->sk_data_ready(ep->base.sk);
+ sctp_sk(ep->base.sk)->pending_data_ready = 0;
+ }
return error;
nomem:
error = -ENOMEM;
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index ce469d648ffbe166f9ae1c5650f481256f31a7f8..72e5b3e41cddf9d79371de8ab01484e4601b97b6 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -264,7 +264,7 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *ulpq, struct sctp_ulpevent *event)
sctp_ulpq_clear_pd(ulpq);
if (queue == &sk->sk_receive_queue)
- sk->sk_data_ready(sk);
+ sctp_sk(sk)->pending_data_ready = 1;
return 1;
out_free:
@@ -1140,5 +1140,5 @@ void sctp_ulpq_abort_pd(struct sctp_ulpq *ulpq, gfp_t gfp)
/* If there is data waiting, send it up the socket now. */
if (sctp_ulpq_clear_pd(ulpq) || ev)
- sk->sk_data_ready(sk);
+ sctp_sk(sk)->pending_data_ready = 1;
}
--
2.5.0
^ permalink raw reply related
* [PATCH 1/2] sctp: compress bit-wide flags to a bitfield on sctp_sock
From: Marcelo Ricardo Leitner @ 2016-03-29 13:49 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
In-Reply-To: <cover.1459259208.git.marcelo.leitner@gmail.com>
It wastes space and gets worse as we add new flags, so convert bit-wide
flags to a bitfield.
Currently it already saves 4 bytes in sctp_sock.
Note that do_auto_asconf cannot be merged, as explained in the comment
before it.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
include/net/sctp/structs.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 6df1ce7a411c548bda4163840a90578b6e1b4cfe..1a6a626904bba4223b7921bbb4be41c2550271a7 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -210,14 +210,14 @@ struct sctp_sock {
int user_frag;
__u32 autoclose;
- __u8 nodelay;
- __u8 disable_fragments;
- __u8 v4mapped;
- __u8 frag_interleave;
__u32 adaptation_ind;
__u32 pd_point;
- __u8 recvrcvinfo;
- __u8 recvnxtinfo;
+ __u16 nodelay:1,
+ disable_fragments:1,
+ v4mapped:1,
+ frag_interleave:1,
+ recvrcvinfo:1,
+ recvnxtinfo:1;
atomic_t pd_mode;
/* Receive to here while partial delivery is in effect. */
--
2.5.0
^ permalink raw reply related
* [PATCH 0/2] sctp: delay calls to sk_data_ready() as much as possible
From: Marcelo Ricardo Leitner @ 2016-03-29 13:49 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
1st patch is a preparation for the 2nd. The idea is to not call
->sk_data_ready() for every data chunk processed while processing
packets but only once before releasing the socket.
Marcelo Ricardo Leitner (2):
sctp: compress bit-wide flags to a bitfield on sctp_sock
sctp: delay calls to sk_data_ready() as much as possible
include/net/sctp/structs.h | 13 +++++++------
net/sctp/sm_sideeffect.c | 5 +++++
net/sctp/ulpqueue.c | 4 ++--
3 files changed, 14 insertions(+), 8 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH] sctp: avoid refreshing heartbeat timer too often
From: Marcelo Ricardo Leitner @ 2016-03-29 13:41 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
Currently on high rate SCTP streams the heartbeat timer refresh can
consume quite a lot of resources as timer updates are costly and it
contains a random factor, which a) is also costly and b) invalidates
mod_timer() optimization for not editing a timer to the same value.
It may even cause the timer to be slightly advanced, for no good reason.
There are 3 places that call sctp_transport_reset_timers(), including
one that calls it for every single chunk added to a packet on
sctp_outq_flush(), even if they are bundled. As there is the possibility
of working on several transports, it's not trivial to just post-poned
this call as it would require to at least remember which transports were
used.
This change then moves the random factor to outside
sctp_transport_timeout(), allowing sctp_transport_reset_timers() to
check if a timer update is really necessary. For that, the random factor
is considered 0. If timer expires is still after it, the update is not
necessary as it's a possible random value and there is no
security/functional loss in doing so.
On loopback with MTU of 65535 and data chunks with 1636, so that we
have a considerable amount of chunks without stressing system calls,
netperf -t SCTP_STREAM -l 30, perf looked like this before:
Samples: 103K of event 'cpu-clock', Event count (approx.): 25833000000
Overhead Command Shared Object Symbol
+ 6,15% netperf [kernel.vmlinux] [k] copy_user_enhanced_fast_string
- 5,43% netperf [kernel.vmlinux] [k] _raw_write_unlock_irqrestore
- _raw_write_unlock_irqrestore
- 96,54% _raw_spin_unlock_irqrestore
- 36,14% mod_timer
+ 97,24% sctp_transport_reset_timers
+ 2,76% sctp_do_sm
+ 33,65% __wake_up_sync_key
+ 28,77% sctp_ulpq_tail_event
+ 1,40% del_timer
- 1,84% mod_timer
+ 99,03% sctp_transport_reset_timers
+ 0,97% sctp_do_sm
+ 1,50% sctp_ulpq_tail_event
And after this patch:
Samples: 120K of event 'cpu-clock', Event count (approx.): 30002250000
Overhead Command Shared Object Symbol
+ 7,34% netperf [kernel.vmlinux] [k] memcpy_erms
+ 6,67% netperf [kernel.vmlinux] [k] copy_user_enhanced_fast_string
- 5,34% netperf [kernel.vmlinux] [k] _raw_write_unlock_irqrestore
- _raw_write_unlock_irqrestore
- 98,00% _raw_spin_unlock_irqrestore
+ 54,24% __wake_up_sync_key
+ 41,54% sctp_ulpq_tail_event
- 2,61% mod_timer
+ 79,88% sctp_transport_update_pmtu
+ 20,12% sctp_do_sm
+ 1,61% del_timer
+ 1,83% sctp_ulpq_tail_event
+ 2,34% netperf [kernel.vmlinux] [k] pvclock_clocksource_read
+ 2,31% netperf [sctp] [k] sctp_sendmsg
+ 1,93% netperf [kernel.vmlinux] [k] __slab_free
+ 1,92% netperf [sctp] [k] sctp_packet_transmit
+ 1,85% netperf [kernel.vmlinux] [k] kfree
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
net/sctp/transport.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index 9b6b48c7524e4b441a151b80f0babec81f539d49..c9d6c61f5a511f96f38a0f2c275e418e158e0632 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -185,6 +185,8 @@ static void sctp_transport_destroy(struct sctp_transport *transport)
*/
void sctp_transport_reset_timers(struct sctp_transport *transport)
{
+ unsigned long expires;
+
/* RFC 2960 6.3.2 Retransmission Timer Rules
*
* R1) Every time a DATA chunk is sent to any address(including a
@@ -199,8 +201,10 @@ void sctp_transport_reset_timers(struct sctp_transport *transport)
sctp_transport_hold(transport);
/* When a data chunk is sent, reset the heartbeat interval. */
- if (!mod_timer(&transport->hb_timer,
- sctp_transport_timeout(transport)))
+ expires = sctp_transport_timeout(transport);
+ if (time_before(transport->hb_timer.expires, expires) &&
+ !mod_timer(&transport->hb_timer,
+ expires + prandom_u32_max(transport->rto)))
sctp_transport_hold(transport);
}
@@ -595,7 +599,7 @@ void sctp_transport_burst_reset(struct sctp_transport *t)
unsigned long sctp_transport_timeout(struct sctp_transport *trans)
{
/* RTO + timer slack +/- 50% of RTO */
- unsigned long timeout = (trans->rto >> 1) + prandom_u32_max(trans->rto);
+ unsigned long timeout = trans->rto >> 1;
if (trans->state != SCTP_UNCONFIRMED &&
trans->state != SCTP_PF)
--
2.5.0
^ permalink raw reply related
* [PATCH] sctp: flush if we can't fit another DATA chunk
From: Marcelo Ricardo Leitner @ 2016-03-29 13:41 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
There is no point in delaying the packet if we can't fit a single byte
of data on it anymore. So lets just reduce the threshold by the amount
that a data chunk with 4 bytes (rounding) would use.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
net/sctp/output.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 97745351d58c2fb32b9f9b57d61831d7724d83b2..c518569123ce42a8f21f80754756306c39875013 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -705,7 +705,8 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
/* Check whether this chunk and all the rest of pending data will fit
* or delay in hopes of bundling a full sized packet.
*/
- if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
+ if (chunk->skb->len + q->out_qlen >
+ maxsize - packet->overhead - sizeof(sctp_data_chunk_t) - 4)
/* Enough data queued to fill a packet */
return SCTP_XMIT_OK;
--
2.5.0
^ permalink raw reply related
* [PATCH] sctp: really allow using GFP_KERNEL on sctp_packet_transmit
From: Marcelo Ricardo Leitner @ 2016-03-29 13:41 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, linux-sctp
Somehow my patch for commit cea8768f333e ("sctp: allow
sctp_transmit_packet and others to use gfp") missed two important
chunks, which are now added.
Fixes: cea8768f333e ("sctp: allow sctp_transmit_packet and others to use gfp")
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
net/sctp/output.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 736c004abfbc2787a3c50fa85168ebdf3b112787..97745351d58c2fb32b9f9b57d61831d7724d83b2 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -401,7 +401,7 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
sk = chunk->skb->sk;
/* Allocate the new skb. */
- nskb = alloc_skb(packet->size + MAX_HEADER, GFP_ATOMIC);
+ nskb = alloc_skb(packet->size + MAX_HEADER, gfp);
if (!nskb)
goto nomem;
@@ -523,8 +523,8 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
*/
if (auth)
sctp_auth_calculate_hmac(asoc, nskb,
- (struct sctp_auth_chunk *)auth,
- GFP_ATOMIC);
+ (struct sctp_auth_chunk *)auth,
+ gfp);
/* 2) Calculate the Adler-32 checksum of the whole packet,
* including the SCTP common header and all the
--
2.5.0
^ permalink raw reply related
* [net-next RFC 3/4] bindtoprefix: TCP/IPv6 implementation
From: Gilberto Bertin @ 2016-03-23 2:26 UTC (permalink / raw)
To: netdev; +Cc: tom, markzzzsmith, Gilberto Bertin
In-Reply-To: <1458699966-3752-1-git-send-email-gilberto.bertin@gmail.com>
Signed-off-by: Gilberto Bertin <gilberto.bertin@gmail.com>
---
net/ipv6/inet6_connection_sock.c | 17 ++++++++++++++++-
net/ipv6/inet6_hashtables.c | 6 ++++++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index 36c3f01..c65023f 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -27,6 +27,20 @@
#include <net/sock.h>
#include <net/inet6_connection_sock.h>
+int inet6_csk_bind_prefix_conflict(const struct sock *sk,
+ const struct sock *sk2)
+{
+ u_char plen;
+
+ plen = min(sk->sk_bind_prefix6.plen, sk2->sk_bind_prefix6.plen);
+
+ if (sk->sk_bind_to_prefix && sk2->sk_bind_to_prefix)
+ return ipv6_prefix_equal(&sk->sk_bind_prefix6.net,
+ &sk2->sk_bind_prefix6.net, plen);
+
+ return 0;
+}
+
int inet6_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb, bool relax)
{
@@ -44,7 +58,8 @@ int inet6_csk_bind_conflict(const struct sock *sk,
if (sk != sk2 &&
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
- sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
+ sk->sk_bound_dev_if == sk2->sk_bound_dev_if) &&
+ inet6_csk_bind_prefix_conflict(sk, sk2)) {
if ((!reuse || !sk2->sk_reuse ||
sk2->sk_state == TCP_LISTEN) &&
(!reuseport || !sk2->sk_reuseport ||
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 21ace5a..bcc16ed 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -114,6 +114,12 @@ static inline int compute_score(struct sock *sk, struct net *net,
return -1;
score++;
}
+ if (sk->sk_bind_to_prefix) {
+ if (!ipv6_prefix_equal(&sk->sk_bind_prefix6.net, daddr,
+ sk->sk_bind_prefix6.plen))
+ return -1;
+ score++;
+ }
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
}
--
2.7.3
^ permalink raw reply related
* [net-next RFC 4/4] bindtoprefix: UPD implementation
From: Gilberto Bertin @ 2016-03-23 2:26 UTC (permalink / raw)
To: netdev; +Cc: tom, markzzzsmith, Gilberto Bertin
In-Reply-To: <1458699966-3752-1-git-send-email-gilberto.bertin@gmail.com>
Signed-off-by: Gilberto Bertin <gilberto.bertin@gmail.com>
---
net/ipv4/udp.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 95d2f19..31b9687 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -133,6 +133,23 @@ EXPORT_SYMBOL(udp_memory_allocated);
#define MAX_UDP_PORTS 65536
#define PORTS_PER_CHAIN (MAX_UDP_PORTS / UDP_HTABLE_SIZE_MIN)
+static inline int udp_csk_bind_prefix_conflict(const struct sock *sk,
+ const struct sock *sk2)
+{
+ __be32 mask;
+
+ if (sk->sk_bind_to_prefix && sk2->sk_bind_to_prefix) {
+ mask = inet_make_mask(min(sk->sk_bind_prefix4.plen,
+ sk2->sk_bind_prefix4.plen));
+
+ return (sk->sk_bind_prefix4.net & mask) ==
+ (sk2->sk_bind_prefix4.net & mask);
+ }
+
+ return 0;
+}
+
+
static int udp_lib_lport_inuse(struct net *net, __u16 num,
const struct udp_hslot *hslot,
unsigned long *bitmap,
@@ -153,6 +170,7 @@ static int udp_lib_lport_inuse(struct net *net, __u16 num,
(!sk2->sk_reuse || !sk->sk_reuse) &&
(!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if ||
sk2->sk_bound_dev_if == sk->sk_bound_dev_if) &&
+ udp_csk_bind_prefix_conflict(sk, sk2) &&
(!sk2->sk_reuseport || !sk->sk_reuseport ||
rcu_access_pointer(sk->sk_reuseport_cb) ||
!uid_eq(uid, sock_i_uid(sk2))) &&
@@ -189,6 +207,7 @@ static int udp_lib_lport_inuse2(struct net *net, __u16 num,
(!sk2->sk_reuse || !sk->sk_reuse) &&
(!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if ||
sk2->sk_bound_dev_if == sk->sk_bound_dev_if) &&
+ udp_csk_bind_prefix_conflict(sk, sk2) &&
(!sk2->sk_reuseport || !sk->sk_reuseport ||
rcu_access_pointer(sk->sk_reuseport_cb) ||
!uid_eq(uid, sock_i_uid(sk2))) &&
@@ -426,6 +445,15 @@ static inline int compute_score(struct sock *sk, struct net *net,
return -1;
score += 4;
}
+
+ if (sk->sk_bind_to_prefix) {
+ __be32 mask = inet_make_mask(sk->sk_bind_prefix4.plen);
+
+ if ((sk->sk_bind_prefix4.net & mask) != (daddr & mask))
+ return -1;
+ score += 4;
+ }
+
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
return score;
@@ -471,6 +499,14 @@ static inline int compute_score2(struct sock *sk, struct net *net,
score += 4;
}
+ if (sk->sk_bind_to_prefix) {
+ __be32 mask = inet_make_mask(sk->sk_bind_prefix4.plen);
+
+ if ((sk->sk_bind_prefix4.net & mask) != (daddr & mask))
+ return -1;
+ score += 4;
+ }
+
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
--
2.7.3
^ permalink raw reply related
* [net-next RFC 2/4] bindtoprefix: TCP/IPv4 implementation
From: Gilberto Bertin @ 2016-03-23 2:26 UTC (permalink / raw)
To: netdev; +Cc: tom, markzzzsmith, Gilberto Bertin
In-Reply-To: <1458699966-3752-1-git-send-email-gilberto.bertin@gmail.com>
Signed-off-by: Gilberto Bertin <gilberto.bertin@gmail.com>
---
net/ipv4/inet_connection_sock.c | 20 +++++++++++++++++++-
net/ipv4/inet_hashtables.c | 9 +++++++++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 6414891..162c252 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/jhash.h>
+#include <linux/inetdevice.h>
#include <net/inet_connection_sock.h>
#include <net/inet_hashtables.h>
@@ -43,6 +44,22 @@ void inet_get_local_port_range(struct net *net, int *low, int *high)
}
EXPORT_SYMBOL(inet_get_local_port_range);
+static inline int inet_csk_bind_prefix_conflict(const struct sock *sk,
+ const struct sock *sk2)
+{
+ __be32 mask;
+
+ if (sk->sk_bind_to_prefix && sk2->sk_bind_to_prefix) {
+ mask = inet_make_mask(min(sk->sk_bind_prefix4.plen,
+ sk2->sk_bind_prefix4.plen));
+
+ return (sk->sk_bind_prefix4.net & mask) ==
+ (sk2->sk_bind_prefix4.net & mask);
+ }
+
+ return 0;
+}
+
int inet_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb, bool relax)
{
@@ -63,7 +80,8 @@ int inet_csk_bind_conflict(const struct sock *sk,
!inet_v6_ipv6only(sk2) &&
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
- sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
+ sk->sk_bound_dev_if == sk2->sk_bound_dev_if) &&
+ inet_csk_bind_prefix_conflict(sk, sk2)) {
if ((!reuse || !sk2->sk_reuse ||
sk2->sk_state == TCP_LISTEN) &&
(!reuseport || !sk2->sk_reuseport ||
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index ccc5980..44693c4 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -13,6 +13,7 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/inetdevice.h>
#include <linux/module.h>
#include <linux/random.h>
#include <linux/sched.h>
@@ -189,6 +190,14 @@ static inline int compute_score(struct sock *sk, struct net *net,
return -1;
score += 4;
}
+ if (sk->sk_bind_to_prefix) {
+ __be32 mask = inet_make_mask(sk->sk_bind_prefix4.plen);
+
+ if ((sk->sk_bind_prefix4.net & mask) != (daddr & mask))
+ return -1;
+ score += 4;
+ }
+
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
}
--
2.7.3
^ permalink raw reply related
* [net-next RFC 1/4] bindtoprefix: infrastructure
From: Gilberto Bertin @ 2016-03-23 2:26 UTC (permalink / raw)
To: netdev; +Cc: tom, markzzzsmith, Gilberto Bertin
In-Reply-To: <1458699966-3752-1-git-send-email-gilberto.bertin@gmail.com>
Signed-off-by: Gilberto Bertin <gilberto.bertin@gmail.com>
---
include/net/sock.h | 20 +++++++
include/uapi/asm-generic/socket.h | 1 +
net/core/sock.c | 111 ++++++++++++++++++++++++++++++++++++++
3 files changed, 132 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index f5ea148..409d255 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -109,6 +109,16 @@ typedef struct {
#endif
} socket_lock_t;
+struct ipv4_prefix {
+ __be32 net;
+ u_char plen;
+};
+
+struct ipv6_prefix {
+ struct in6_addr net;
+ u_char plen;
+};
+
struct sock;
struct proto;
struct net;
@@ -176,6 +186,13 @@ struct sock_common {
unsigned char skc_ipv6only:1;
unsigned char skc_net_refcnt:1;
int skc_bound_dev_if;
+
+ unsigned char skc_bind_to_prefix;
+ union {
+ struct ipv4_prefix skc_bind_prefix4;
+ struct ipv6_prefix skc_bind_prefix6;
+ };
+
union {
struct hlist_node skc_bind_node;
struct hlist_nulls_node skc_portaddr_node;
@@ -327,6 +344,9 @@ struct sock {
#define sk_state __sk_common.skc_state
#define sk_reuse __sk_common.skc_reuse
#define sk_reuseport __sk_common.skc_reuseport
+#define sk_bind_to_prefix __sk_common.skc_bind_to_prefix
+#define sk_bind_prefix4 __sk_common.skc_bind_prefix4
+#define sk_bind_prefix6 __sk_common.skc_bind_prefix6
#define sk_ipv6only __sk_common.skc_ipv6only
#define sk_net_refcnt __sk_common.skc_net_refcnt
#define sk_bound_dev_if __sk_common.skc_bound_dev_if
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index fb8a416..b4dd61f 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -30,6 +30,7 @@
#define SO_SNDLOWAT 19
#define SO_RCVTIMEO 20
#define SO_SNDTIMEO 21
+#define SO_BINDTOPREFIX 22
#endif
/* Security levels - as per NRL IPv6 - don't actually do anything */
diff --git a/net/core/sock.c b/net/core/sock.c
index 6c1c8bc..e4c9c55 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -571,6 +571,68 @@ out:
return ret;
}
+static int sock_setbindtoprefix(struct sock *sk, char __user *optval,
+ int optlen)
+{
+ int ret = -ENOPROTOOPT;
+
+ if (sk->sk_family == AF_INET) {
+ struct ipv4_prefix bind_prefix4;
+
+ ret = -EFAULT;
+ if (optlen != sizeof(struct ipv4_prefix))
+ goto out;
+
+ if (copy_from_user(&bind_prefix4, optval,
+ sizeof(struct ipv4_prefix)))
+ goto out;
+
+ ret = -EINVAL;
+ if (bind_prefix4.plen > 32)
+ goto out;
+
+ lock_sock(sk);
+
+ sk->sk_bind_to_prefix = 1;
+ sk->sk_bind_prefix4.net = bind_prefix4.net;
+ sk->sk_bind_prefix4.plen = bind_prefix4.plen;
+ sk_dst_reset(sk);
+
+ release_sock(sk);
+
+ ret = 0;
+ } else if (sk->sk_family == AF_INET6) {
+ struct ipv6_prefix bind_prefix6;
+
+ ret = -EFAULT;
+ if (optlen != sizeof(struct ipv6_prefix))
+ goto out;
+
+ if (copy_from_user(&bind_prefix6, optval,
+ sizeof(struct ipv6_prefix)))
+ goto out;
+
+ ret = -EINVAL;
+ if (bind_prefix6.plen > 128)
+ goto out;
+
+ lock_sock(sk);
+
+ sk->sk_bind_to_prefix = 1;
+ memcpy(&sk->sk_bind_prefix6.net, &bind_prefix6.net,
+ sizeof(struct in6_addr));
+ sk->sk_bind_prefix6.plen = bind_prefix6.plen;
+ sk_dst_reset(sk);
+
+ release_sock(sk);
+
+ ret = 0;
+ }
+
+out:
+ return ret;
+}
+
static int sock_getbindtodevice(struct sock *sk, char __user *optval,
int __user *optlen, int len)
{
@@ -611,6 +673,49 @@ out:
return ret;
}
+static int sock_getbindtoprefix(struct sock *sk, char __user *optval,
+ int __user *optlen, int len)
+{
+ int ret;
+
+ if (sk->sk_bind_to_prefix == 0) {
+ len = 0;
+ goto zero;
+ }
+
+ if (sk->sk_family == AF_INET) {
+ ret = -EINVAL;
+ if (len < sizeof(struct ipv4_prefix))
+ goto out;
+
+ len = sizeof(struct ipv4_prefix);
+
+ ret = -EFAULT;
+ if (copy_to_user(optval, &sk->sk_bind_prefix4, len))
+ goto out;
+
+ } else if (sk->sk_family == AF_INET6) {
+ ret = -EINVAL;
+ if (len < sizeof(struct ipv6_prefix))
+ goto out;
+
+ len = sizeof(struct ipv6_prefix);
+
+ ret = -EFAULT;
+ if (copy_to_user(optval, &sk->sk_bind_prefix6, len))
+ goto out;
+ }
+
+zero:
+ ret = -EFAULT;
+ if (put_user(len, optlen))
+ goto out;
+
+ ret = 0;
+out:
+ return ret;
+}
+
static inline void sock_valbool_flag(struct sock *sk, int bit, int valbool)
{
if (valbool)
@@ -659,6 +764,9 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
if (optname == SO_BINDTODEVICE)
return sock_setbindtodevice(sk, optval, optlen);
+ else if (optname == SO_BINDTOPREFIX)
+ return sock_setbindtoprefix(sk, optval, optlen);
+
if (optlen < sizeof(int))
return -EINVAL;
@@ -1214,6 +1322,9 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
case SO_BINDTODEVICE:
return sock_getbindtodevice(sk, optval, optlen, len);
+ case SO_BINDTOPREFIX:
+ return sock_getbindtoprefix(sk, optval, optlen, len);
+
case SO_GET_FILTER:
len = sk_get_filter(sk, (struct sock_filter __user *)optval, len);
if (len < 0)
--
2.7.3
^ permalink raw reply related
* [net-next RFC 0/4] SO_BINDTOPREFIX
From: Gilberto Bertin @ 2016-03-23 2:26 UTC (permalink / raw)
To: netdev; +Cc: tom, markzzzsmith, Gilberto Bertin
Since the net-next window just opened, I'm resubmitting my RFC for the
SO_BINDTOSUBNET patch, following Mark Smith's suggestion to rename the
whole thing to a more clear SO_BINDTOPREFIX.
Some arguments for and against it since the first submission:
* SO_BINDTOPREFIX is an arbitrary option and can be seens as nother use
* case of the SO_REUSEPORT BPF patch
* but at the same time using BPF requires more work/code on the server
and since the bind to prefix use case could potentially become a
common one maybe there is some value in having it as an option instead
of having to code (either manually or with clang) an eBPF program that
would do the same
* it may probably possible to archive the same results using VRF. This
would require to create a VRF device, configure the device routing
table and make each bind each process to a different VRF device (but
I'm not sure how this would work/interfere with an existing iptables
setup for example)
-----------------------------------------------------------------------------
This series introduces support for the SO_BINDTOPREFIX socket option, which
allows a listener socket to bind to a prefix instead of * or a single address.
Motivation:
consider a set of servers, each one with thousands and thousands of IP
addresses. Since assigning /32 or /128 IP individual addresses would be
inefficient, one solution can be assigning prefixes using local routes
(with 'ip route add local').
This allows a listener to listen and terminate connections going to any
of the IP addresses of these prefixes without explicitly configuring all
the IP addresses of the prefix range.
This is very efficient.
Unfortunately there may be the need to use different prefixes for
different purposes.
One can imagine port 80 being served by one HTTP server for some IP
prefix, while another server used for another prefix.
Right now Linux does not allow this.
It is either possible to bind to *, indicating ALL traffic going to
given port, or to individual IP addresses.
The first only allows to accept connections from all the prefixes.
The latter does not scale well with lots of IP addresses.
Using bindtoprefix would solve this problem: just by adding a local
route rule and setting the SO_BINDTOPREFIX option for a socket it would
be possible to easily partition traffic by prefixes.
API:
the prefix is specified (as argument of the setsockopt syscall) by the
address of the network, and the prefix length of the netmask.
IPv4:
struct ipv4_prefix {
__be32 net;
u_char plen;
};
and IPv6:
struct ipv6_prefix {
struct in6_addr net;
u_char plen;
};
Bind conflicts:
two sockets with the bindtoprefix option enabled generate a bind
conflict if their network addresses masked with the shortest of their
prefix are equal.
The bindtoprefix option can be combined with soreuseport so that two
listener can bind on the same prefix.
Any questions/feedback appreciated.
Thanks,
Gilberto
Gilberto Bertin (4):
bindtoprefix: infrastructure
bindtoprefix: TCP/IPv4 implementation
bindtoprefix: TCP/IPv6 implementation
bindtoprefix: UPD implementation
include/net/sock.h | 20 +++++++
include/uapi/asm-generic/socket.h | 1 +
net/core/sock.c | 111 ++++++++++++++++++++++++++++++++++++++
net/ipv4/inet_connection_sock.c | 20 ++++++-
net/ipv4/inet_hashtables.c | 9 ++++
net/ipv4/udp.c | 36 +++++++++++++
net/ipv6/inet6_connection_sock.c | 17 +++++-
net/ipv6/inet6_hashtables.c | 6 +++
8 files changed, 218 insertions(+), 2 deletions(-)
--
2.7.3
^ permalink raw reply
* Re: [PATCH net-next v3.16]r9169: Correct Set Vlan tag
From: Eric Dumazet @ 2016-03-29 13:29 UTC (permalink / raw)
To: Corcodel Marian; +Cc: netdev, Francois Romieu
In-Reply-To: <1459240400-1602-1-git-send-email-asd@marian1000.go.ro>
On Tue, 2016-03-29 at 11:33 +0300, Corcodel Marian wrote:
> This patch add set Vlan tag and flush CPlusCmd register because when unset
> RxVlan and RxChkSum bit, whithout some explication , unwanted bits
> is set, PCIDAC, PCIMulRW and others.Whithout this patch when run
> ethtool -d eth0 on "C+ Command" field missing "VLAN de-tagging"
Are you a bot or a human being ?
It really looks like a program was assigned to fool us, sending
random patches targeting r8169 and random linux kernels.
We wont accept patches if they are not targeting current linux kernels.
^ permalink raw reply
* Re: [PATCH 1/2 net-next v3.16]r8169: Disable set bit multicast enable per multicast address.
From: Eric Dumazet @ 2016-03-29 12:59 UTC (permalink / raw)
To: Corcodel Marian; +Cc: netdev, Francois Romieu
In-Reply-To: <20160327193150.6085df90@192-168-0-108.rdsnet.ro>
On Sun, 2016-03-27 at 19:31 +0300, Corcodel Marian wrote:
> On Sat, 26 Mar 2016 10:18:46 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Sat, 2016-03-26 at 12:57 +0200, Corcodel Marian wrote:
> > > This patch correct set bit multicast enable only once per
> > > set_rx_mode invocation.
> > >
> > > Signed-off-by: Corcodel Marian <asd@marian1000.go.ro>
> > > ---
> > > drivers/net/ethernet/realtek/r8169.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/realtek/r8169.c
> > > b/drivers/net/ethernet/realtek/r8169.c index 7f6fb1f..f7b0dfb 100644
> > > --- a/drivers/net/ethernet/realtek/r8169.c
> > > +++ b/drivers/net/ethernet/realtek/r8169.c
> > > @@ -4619,12 +4619,11 @@ static void rtl_set_rx_mode(struct
> > > net_device *dev) } else {
> > > struct netdev_hw_addr *ha;
> > >
> > > - rx_mode = AcceptBroadcast | AcceptMyPhys;
> > > + rx_mode = AcceptBroadcast | AcceptMyPhys |
> > > AcceptMulticast; mc_filter[1] = mc_filter[0] = 0;
> > > netdev_for_each_mc_addr(ha, dev) {
> > > int bit_nr = ether_crc(ETH_ALEN, ha->addr)
> > > >> 26; mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
> > > - rx_mode |= AcceptMulticast;
> > > }
> > > }
> > >
> >
> > If the list is empty, why should we enable AcceptMulticast ?
> >
> >
> >
>
> I not experienced list empty, allways on my case exist bit_nr variable.
If dev->mc list is empty, the netdev_for_each_mc_addr(ha, dev) does
nothing at all.
In other words, netdev_mc_count(dev) can be 0
Current code is fine, and run in control (slow) path anyway.
^ permalink raw reply
* Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
From: Eric Dumazet @ 2016-03-29 12:58 UTC (permalink / raw)
To: Wei-Ning Huang
Cc: Kalle Valo, Linux Wireless, LKML, Amitkumar Karwar,
Nishant Sarmukadam, Sameer Nanda, netdev, Sonny Rao,
Douglas Anderson
In-Reply-To: <CABicQ-UJ1kniq6m86QcyVZBPznvNexfrUrTk3A_=GmZy69hvCA@mail.gmail.com>
On Tue, 2016-03-29 at 17:27 +0800, Wei-Ning Huang wrote:
> Adding some chromium devs to the thread.
>
> In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152
>
> The default mm retry allocation when 'order <=
> PAGE_ALLOC_COSTLY_ORDER' of gfp_mask contains __GFP_REPEAT.
> PAGE_ALLOC_COSTLY_ORDER is defined to be 3. On systems with page size
> = 4K, this means memory compaction and retry is only done when the
> size of allocation is <= 32K
> In mwifiex, the allocation size is 64K.
> When we have system with
> memory fragmentation and allocation failed, there will be no retry.
> This is why we need to add __GFP_REPEAT here to allow the system to
> perform memory compaction and retry allocation.
>
> Maybe Amit@marvell can comment on if this is a good fix on this issue.
> I'm also aware that marvell is the progress of implementing
> scatter/gatter for mwifiex, which can also fix the issue.
Before SG is implemented, you really need to copy incoming frames into
smallest chunks (to get lowest skb->truesize) and leave the 64KB
allocated stuff forever in the driver.
__GFP_REPEAT wont really solve the issue.
It seems the problem comes from the fact that the drivers calls
dev_kfree_skb_any() after calling mwifiex_deaggr_sdio_pkt(), instead of
recycling this very precious 64KB skb once memory gets fragmented.
Another problem is that mwifiex_deaggr_sdio_pkt() uses
mwifiex_alloc_dma_align_buf() with GFP_KERNEL | GFP_DMA
Really GFP_DMA makes no sense here, since the skb is going to be
processed by the stack, which has no such requirement.
Please use normal skb allocations there.
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index b2c839a..8404db5 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1123,8 +1123,8 @@ static void mwifiex_deaggr_sdio_pkt(struct mwifiex_adapter *adapter,
__func__, pkt_len, blk_size);
break;
}
- skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len,
- GFP_KERNEL | GFP_DMA);
+ skb_deaggr = __netdev_alloc_skb_ip_align(NULL, pkt_len,
+ GFP_KERNEL);
if (!skb_deaggr)
break;
skb_put(skb_deaggr, pkt_len);
^ permalink raw reply related
* Re: bpf: net/core/filter.c:2115 suspicious rcu_dereference_protected() usage!
From: Michal Kubecek @ 2016-03-29 12:58 UTC (permalink / raw)
To: Sasha Levin
Cc: Jiri Slaby, David S. Miller, ast, Daniel Borkmann,
netdev@vger.kernel.org, LKML
In-Reply-To: <56CB29D5.9090000@oracle.com>
On Mon, Feb 22, 2016 at 10:31:33AM -0500, Sasha Levin wrote:
>
> I've hit the following warning while fuzzing with trinity inside a kvmtool guest
> running the latest -next kernel:
>
> [ 1343.104588] ===============================
> [ 1343.104591] [ INFO: suspicious RCU usage. ]
> [ 1343.104619] 4.5.0-rc4-next-20160219-sasha-00026-g7978205-dirty #2978 Not tainted
> [ 1343.104624] -------------------------------
> [ 1343.104635] net/core/filter.c:2115 suspicious rcu_dereference_protected() usage!
> [ 1343.104641]
> [ 1343.104641] other info that might help us debug this:
> [ 1343.104641]
> [ 1343.104650]
> [ 1343.104650] rcu_scheduler_active = 1, debug_locks = 0
> [ 1343.104660] 1 lock held by syz-executor/17916:
> [ 1343.104784] #0: (rtnl_mutex){+.+.+.}, at: rtnl_lock (net/core/rtnetlink.c:71)
> [ 1343.104789]
> [ 1343.104789] stack backtrace:
> [ 1343.104820] CPU: 1 PID: 17916 Comm: trinity-c8 Not tainted 4.5.0-rc4-next-20160219-sasha-00026-g7978205-dirty #2978
> [ 1343.104868] 1ffff10036968f44 ffff8801b4b47aa8 ffffffffa23d9a9d ffffffff00000001
> [ 1343.104891] fffffbfff5c2a630 0000000041b58ab3 ffffffffadb3a8f2 ffffffffa23d9905
> [ 1343.104914] 0000000000000000 ffff8801b5419b40 fffffbfff7596522 0000000000000001
> [ 1343.104919] Call Trace:
> [ 1343.104985] dump_stack (lib/dump_stack.c:53)
> [ 1343.105060] lockdep_rcu_suspicious (kernel/locking/lockdep.c:4282)
> [ 1343.105093] sk_detach_filter (net/core/filter.c:2114 (discriminator 5))
> [ 1343.105193] tun_detach_filter (drivers/net/tun.c:1808 (discriminator 7))
> [ 1343.105238] __tun_chr_ioctl (drivers/net/tun.c:2133)
> [ 1343.105370] tun_chr_ioctl (drivers/net/tun.c:2161)
> [ 1343.105407] do_vfs_ioctl (fs/ioctl.c:44 fs/ioctl.c:674)
> [ 1343.105506] SyS_ioctl (fs/ioctl.c:689 fs/ioctl.c:680)
> [ 1343.105542] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:200)
Looks like sk_detach_filter() wants the socket to be owned which neither
tun_detach_filter() does not do, unlike sock_setsockopt(). Could you
check if the patch below helps?
I'm also not really sure if it is safe to ignore return value of
sk_detach_filter() and just sets tun->filter_attached to false - but
it's not really clear what should be done if one of the calls fails
after some succeeded.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index afdf950617c3..7417d7c20bab 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1818,11 +1818,13 @@ static int set_offload(struct tun_struct *tun, unsigned long arg)
static void tun_detach_filter(struct tun_struct *tun, int n)
{
int i;
- struct tun_file *tfile;
for (i = 0; i < n; i++) {
- tfile = rtnl_dereference(tun->tfiles[i]);
- sk_detach_filter(tfile->socket.sk);
+ struct sock *sk = rtnl_dereference(tun->tfiles[i])->socket.sk;
+
+ lock_sock(sk);
+ sk_detach_filter(sk);
+ release_sock(sk);
}
tun->filter_attached = false;
^ permalink raw reply related
* Re: [PATCH 15/16] wcn36xx: don't pad beacons for mesh
From: Sergei Shtylyov @ 2016-03-29 12:45 UTC (permalink / raw)
To: Bjorn Andersson, Eugene Krasnikov, Kalle Valo
Cc: wcn36xx, linux-wireless, netdev, linux-kernel, Jason Mobarak,
Chun-Yeow Yeoh
In-Reply-To: <1459231593-360-16-git-send-email-bjorn.andersson@linaro.org>
Hello.
On 3/29/2016 9:06 AM, Bjorn Andersson wrote:
> From: Jason Mobarak <jam@cozybit.com>
>
> Patch "wcn36xx: Pad TIM PVM if needed" has caused a regression in mesh
scripts/checkpatch.pl now enforces the specific commit citing format, i.e.
<12-digit SHA1> ("<commit summary>").
> beaconing. The field tim_off is always 0 for mesh mode, and thus
> pvm_len (referring to the TIM length field) and pad are both incorrectly
> calculated. Thus, msg_body.beacon_length is incorrectly calculated for
> mesh mode. Fix this.
>
> Signed-off-by: Jason Mobarak <jam@cozybit.com>
> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
You might want to add the Fixes: tag.
[...]
MBR, Sergei
^ permalink raw reply
* Re: am335x: no multicast reception over VLAN
From: Grygorii Strashko @ 2016-03-29 12:44 UTC (permalink / raw)
To: Yegor Yefremov
Cc: Mugunthan V N, netdev, linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <CAGm1_ksvEdk-mF-hW4o5+bri6J6sMgnQQVD3j-e7xm6PsP8k0A@mail.gmail.com>
On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>> Hi Mugunthan,
>>>
>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>> Hi Yegor
>>>>
>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>> VLAN ID:
>>>>>
>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>
>>>>> I can successfully send multicast packets, but not receive them. On
>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>> could both receive and send multicast packets via VLAN.
>>>>
>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>
>>> I'm trying multicast tx/rx on eth1.100.
>>>
>>> eth1 has no problems.
>>>
>>
>> it'd be nice if will be able to post here output fom commands:
>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>> # ifconfig -a
>> # tcpdump -e -f -Q in -i eth0
>> # tcpdump -e -f -Q in -i eth0.100
>
> Which kernel/branch do you want me to test?
>
> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>
> So far I was using vanilla kernel.
Your branch (but better 4.5 kernels (or 4.4)).
Just when you've done with configuration run cmds 1&2,
and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
then stop test and run cmd 1 again.
After all could you provide your console output here, pls.
--
regards,
-grygorii
^ permalink raw reply
* Re: am335x: no multicast reception over VLAN
From: Yegor Yefremov @ 2016-03-29 12:35 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Mugunthan V N, netdev, linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <56FA616C.9080502@ti.com>
On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>> Hi Mugunthan,
>>
>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>> Hi Yegor
>>>
>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>> VLAN ID:
>>>>
>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>
>>>> I can successfully send multicast packets, but not receive them. On
>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>> could both receive and send multicast packets via VLAN.
>>>
>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>
>> I'm trying multicast tx/rx on eth1.100.
>>
>> eth1 has no problems.
>>
>
> it'd be nice if will be able to post here output fom commands:
> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
> # ifconfig -a
> # tcpdump -e -f -Q in -i eth0
> # tcpdump -e -f -Q in -i eth0.100
Which kernel/branch do you want me to test?
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
So far I was using vanilla kernel.
Yegor
^ permalink raw reply
* [PATCH net-next v2 2/2] net: dsa: mv88e6xxx: Clear the PDOWN bit on setup
From: Patrick Uiterwijk @ 2016-03-29 11:11 UTC (permalink / raw)
To: linux, davem, vivien.didelot, andrew
Cc: netdev, dennis, pbrobinson, Patrick Uiterwijk
In-Reply-To: <1459249908-4556-1-git-send-email-patrick@puiterwijk.org>
Some of the vendor-specific bootloaders set up this part
of the initialization for us, so this was never added.
However, since upstream bootloaders don't initialize the
chip specifically, they leave the fiber MII's PDOWN flag
set, which means that the CPU port doesn't connect.
This patch checks whether this flag has been clear prior
by something else, and if not make us clear it.
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
---
drivers/net/dsa/mv88e6xxx.c | 36 ++++++++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx.h | 8 ++++++++
2 files changed, 44 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 86a2029..9807913 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2296,6 +2296,25 @@ restore_page_0:
return ret;
}
+static int mv88e6xxx_power_on_serdes(struct dsa_switch *ds)
+{
+ int ret;
+
+ ret = _mv88e6xxx_phy_page_read(ds, REG_FIBER_SERDES, PAGE_FIBER_SERDES,
+ MII_BMCR);
+ if (ret < 0)
+ return ret;
+
+ if (ret & BMCR_PDOWN) {
+ ret = ret & ~BMCR_PDOWN;
+ ret = _mv88e6xxx_phy_page_write(ds, REG_FIBER_SERDES,
+ PAGE_FIBER_SERDES, MII_BMCR,
+ ret);
+ }
+
+ return ret;
+}
+
static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -2399,6 +2418,23 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
goto abort;
}
+ /* If this port is connected to a SerDes, make sure the SerDes is not
+ * powered down.
+ */
+ if (mv88e6xxx_6352_family(ds)) {
+ ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_STATUS);
+ if (ret < 0)
+ goto abort;
+ ret &= PORT_STATUS_CMODE_MASK;
+ if ((ret == PORT_STATUS_CMODE_100BASE_X) ||
+ (ret == PORT_STATUS_CMODE_1000BASE_X) ||
+ (ret == PORT_STATUS_CMODE_SGMII)) {
+ ret = mv88e6xxx_power_on_serdes(ds);
+ if (ret < 0)
+ goto abort;
+ }
+ }
+
/* Port Control 2: don't force a good FCS, set the maximum frame size to
* 10240 bytes, disable 802.1q tags checking, don't discard tagged or
* untagged frames on this port, do a destination address lookup on all
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 9a038ab..26a424a 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -28,6 +28,10 @@
#define SMI_CMD_OP_45_READ_DATA_INC ((3 << 10) | SMI_CMD_BUSY)
#define SMI_DATA 0x01
+/* Fiber/SERDES Registers are located at SMI address F, page 1 */
+#define REG_FIBER_SERDES 0x0f
+#define PAGE_FIBER_SERDES 0x01
+
#define REG_PORT(p) (0x10 + (p))
#define PORT_STATUS 0x00
#define PORT_STATUS_PAUSE_EN BIT(15)
@@ -45,6 +49,10 @@
#define PORT_STATUS_MGMII BIT(6) /* 6185 */
#define PORT_STATUS_TX_PAUSED BIT(5)
#define PORT_STATUS_FLOW_CTRL BIT(4)
+#define PORT_STATUS_CMODE_MASK 0x0f
+#define PORT_STATUS_CMODE_100BASE_X 0x8
+#define PORT_STATUS_CMODE_1000BASE_X 0x9
+#define PORT_STATUS_CMODE_SGMII 0xa
#define PORT_PCS_CTRL 0x01
#define PORT_PCS_CTRL_RGMII_DELAY_RXCLK BIT(15)
#define PORT_PCS_CTRL_RGMII_DELAY_TXCLK BIT(14)
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}
From: Patrick Uiterwijk @ 2016-03-29 11:11 UTC (permalink / raw)
To: linux, davem, vivien.didelot, andrew
Cc: netdev, dennis, pbrobinson, Patrick Uiterwijk
Add versions of the phy_page_read and _write functions to
be used in a context where the SMI mutex is held.
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
---
drivers/net/dsa/mv88e6xxx.c | 49 +++++++++++++++++++++++++++++++++------------
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index fa086e0..86a2029 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2264,6 +2264,38 @@ static void mv88e6xxx_bridge_work(struct work_struct *work)
mutex_unlock(&ps->smi_mutex);
}
+static int _mv88e6xxx_phy_page_write(struct dsa_switch *ds, int port, int page,
+ int reg, int val)
+{
+ int ret;
+
+ ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
+ if (ret < 0)
+ goto restore_page_0;
+
+ ret = _mv88e6xxx_phy_write_indirect(ds, port, reg, val);
+restore_page_0:
+ _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
+
+ return ret;
+}
+
+static int _mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page,
+ int reg)
+{
+ int ret;
+
+ ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
+ if (ret < 0)
+ goto restore_page_0;
+
+ ret = _mv88e6xxx_phy_read_indirect(ds, port, reg);
+restore_page_0:
+ _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
+
+ return ret;
+}
+
static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -2714,13 +2746,9 @@ int mv88e6xxx_phy_page_read(struct dsa_switch *ds, int port, int page, int reg)
int ret;
mutex_lock(&ps->smi_mutex);
- ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
- if (ret < 0)
- goto error;
- ret = _mv88e6xxx_phy_read_indirect(ds, port, reg);
-error:
- _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
+ ret = _mv88e6xxx_phy_page_read(ds, port, page, reg);
mutex_unlock(&ps->smi_mutex);
+
return ret;
}
@@ -2731,14 +2759,9 @@ int mv88e6xxx_phy_page_write(struct dsa_switch *ds, int port, int page,
int ret;
mutex_lock(&ps->smi_mutex);
- ret = _mv88e6xxx_phy_write_indirect(ds, port, 0x16, page);
- if (ret < 0)
- goto error;
-
- ret = _mv88e6xxx_phy_write_indirect(ds, port, reg, val);
-error:
- _mv88e6xxx_phy_write_indirect(ds, port, 0x16, 0x0);
+ ret = _mv88e6xxx_phy_page_write(ds, port, page, reg, val);
mutex_unlock(&ps->smi_mutex);
+
return ret;
}
--
2.7.4
^ permalink raw reply related
* Re: am335x: no multicast reception over VLAN
From: Grygorii Strashko @ 2016-03-29 11:05 UTC (permalink / raw)
To: Yegor Yefremov, Mugunthan V N
Cc: netdev, linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <CAGm1_ksxRPCAqx4n5gbsARSYeF116BT7r8cC6=1QYnEsYRxpVw@mail.gmail.com>
On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
> Hi Mugunthan,
>
> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> Hi Yegor
>>
>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>> VLAN ID:
>>>
>>> ip link add link eth1 name eth1.100 type vlan id 100
>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>
>>> I can successfully send multicast packets, but not receive them. On
>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>> could both receive and send multicast packets via VLAN.
>>
>> Are you trying multicast tx/rx on eth1 or eth1.100?
>
> I'm trying multicast tx/rx on eth1.100.
>
> eth1 has no problems.
>
it'd be nice if will be able to post here output fom commands:
# switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
# ifconfig -a
# tcpdump -e -f -Q in -i eth0
# tcpdump -e -f -Q in -i eth0.100
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH] mwifiex: advertise low priority scan feature
From: Wei-Ning Huang @ 2016-03-29 10:56 UTC (permalink / raw)
To: Kalle Valo
Cc: Linux Wireless, LKML, Amitkumar Karwar, Daniel Kurtz,
Nishant Sarmukadam, netdev
In-Reply-To: <CABicQ-WPZ39iBc_JVUU-vm2NNCq50rhEKXk6KmqQ7s3-uYgbkQ@mail.gmail.com>
I've resent the patch here: https://patchwork.kernel.org/patch/8637861/
Thanks!
Wei-Ning
On Tue, Mar 22, 2016 at 12:12 PM, Wei-Ning Huang <wnhuang@google.com> wrote:
> Hi Kalle,
>
> Thanks for the review. I accidentally removed the s-o-b line from
> akarwar in this version.
> The original patch can be found at:
> https://chromium-review.googlesource.com/#/c/246052/
> I've resent a new one.
>
> Wei-Ning
>
> On Mon, Mar 21, 2016 at 6:28 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Wei-Ning Huang <wnhuang@chromium.org> writes:
>>
>>> From: Amitkumar Karwar <akarwar@marvell.com>
>>>
>>> Low priority scan handling code which delays or aborts scan
>>> operation based on Tx traffic is removed recently. The reason
>>> is firmware already takes care of it in our new feature scan
>>> channel gap. Hence we should advertise low priority scan
>>> support to cfg80211.
>>>
>>> This patch fixes a problem in which OBSS scan request from
>>> wpa_supplicant was being rejected by cfg80211.
>>>
>>> Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
>>
>> The From line states that this is written by Amitkumar but there's no
>> Signed-off-By line from him. I can't take this without that, please
>> resend.
>>
>> (Wei-Ning's s-o-b line is correct, I just need also Amitkumar's line.)
>>
>> --
>> Kalle Valo
>
>
>
> --
> Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
> wnhuang@google.com | Cell: +886 910-380678
--
Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
wnhuang@google.com | Cell: +886 910-380678
^ permalink raw reply
* RE: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
From: Amitkumar Karwar @ 2016-03-29 10:51 UTC (permalink / raw)
To: Wei-Ning Huang, Kalle Valo
Cc: Linux Wireless, LKML, Nishant Sarmukadam, Sameer Nanda,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sonny Rao,
Douglas Anderson
In-Reply-To: <CABicQ-UJ1kniq6m86QcyVZBPznvNexfrUrTk3A_=GmZy69hvCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> From: Wei-Ning Huang [mailto:wnhuang@google.com]
> Sent: Tuesday, March 29, 2016 2:57 PM
> To: Kalle Valo
> Cc: Linux Wireless; LKML; Amitkumar Karwar; Nishant Sarmukadam; Sameer
> Nanda; netdev@vger.kernel.org; Sonny Rao; Douglas Anderson
> Subject: Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
>
> Adding some chromium devs to the thread.
>
> In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152
>
> The default mm retry allocation when 'order <= PAGE_ALLOC_COSTLY_ORDER'
> of gfp_mask contains __GFP_REPEAT.
> PAGE_ALLOC_COSTLY_ORDER is defined to be 3. On systems with page size =
> 4K, this means memory compaction and retry is only done when the size of
> allocation is <= 32K In mwifiex, the allocation size is 64K. When we
> have system with memory fragmentation and allocation failed, there will
> be no retry.
> This is why we need to add __GFP_REPEAT here to allow the system to
> perform memory compaction and retry allocation.
>
> Maybe Amit@marvell can comment on if this is a good fix on this issue.
> I'm also aware that marvell is the progress of implementing
> scatter/gatter for mwifiex, which can also fix the issue.
>
> Wei-Ning
>
This fix would be useful. We have a feature called single port aggregation in which sometimes data received from SDIO interface can be >32k (but less than 64k). This feature improves throughput performance. We are preparing patches for scatter/gather feature. but scatter/gather won't be supported by some platforms. Hence this fix would still be needed.
Regards,
Amitkumar
^ permalink raw reply
* [PATCH] bridge: Allow set bridge ageing time when switchdev disabled
From: Haishuang Yan @ 2016-03-29 10:48 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller
Cc: bridge, netdev, linux-kernel, Haishuang Yan
When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP,
we should ignore this error code and continue to set the ageing time.
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/bridge/br_stp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index e234490..9cb7044 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -582,7 +582,7 @@ int br_set_ageing_time(struct net_bridge *br, u32 ageing_time)
int err;
err = switchdev_port_attr_set(br->dev, &attr);
- if (err)
+ if (err && err != -EOPNOTSUPP)
return err;
br->ageing_time = t;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
From: Wei-Ning Huang @ 2016-03-29 9:27 UTC (permalink / raw)
To: Kalle Valo
Cc: Linux Wireless, LKML, Amitkumar Karwar, Nishant Sarmukadam,
Sameer Nanda, netdev, Sonny Rao, Douglas Anderson
In-Reply-To: <87vb45brxc.fsf@kamboji.qca.qualcomm.com>
Adding some chromium devs to the thread.
In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152
The default mm retry allocation when 'order <=
PAGE_ALLOC_COSTLY_ORDER' of gfp_mask contains __GFP_REPEAT.
PAGE_ALLOC_COSTLY_ORDER is defined to be 3. On systems with page size
= 4K, this means memory compaction and retry is only done when the
size of allocation is <= 32K
In mwifiex, the allocation size is 64K. When we have system with
memory fragmentation and allocation failed, there will be no retry.
This is why we need to add __GFP_REPEAT here to allow the system to
perform memory compaction and retry allocation.
Maybe Amit@marvell can comment on if this is a good fix on this issue.
I'm also aware that marvell is the progress of implementing
scatter/gatter for mwifiex, which can also fix the issue.
Wei-Ning
On Tue, Mar 29, 2016 at 4:37 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Wei-Ning Huang <wnhuang@chromium.org> writes:
>
>> "single skb allocation failure" happens when system is under heavy
>> memory pressure. Add __GFP_REPEAT to skb allocation call so kernel
>> attempts to reclaim pages and retry the allocation.
>>
>> Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
>
> Is this really a proper way to fix the issue? This is the first time I'm
> hearing about the flag and there isn't even a single user in
> drivers/net. I would like to get confirmation from others that
> __GFP_REPEAT is really ok to use in a wireless driver before I can take
> this.
>
> --
> Kalle Valo
--
Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan |
wnhuang@google.com | Cell: +886 910-380678
^ 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