* [PATCH BUGFIX 1/6] pkt_sched: properly cap timestamps in charge_actual_service
From: Paolo valente @ 2013-03-05 18:04 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller, shemminger
Cc: netdev, linux-kernel, fchecconi, rizzo, Paolo Valente
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
QFQ+ schedules the active aggregates in a group using a bucket list
(one list per group). The bucket in which each aggregate is inserted
depends on the aggregate's timestamps, and the number
of buckets in a group is enough to accomodate the possible (range of)
values of the timestamps of all the aggregates in the group. For this
property to hold, timestamps must however be computed correctly. One
necessary condition for computing timestamps correctly is that the
number of bits dequeued for each aggregate, while the aggregate is in
service, does not exceed the maximum budget budgetmax assigned to the
aggregate.
For each aggregate, budgetmax is proportional to the number of classes
in the aggregate. If the number of classes of the aggregate is
decreased through qfq_change_class(), then budgetmax is decreased
automatically as well. Problems may occur if the aggregate is in
service when budgetmax is decreased, because the current remaining
budget of the aggregate and/or the service already received by the
aggregate may happen to be larger than the new value of budgetmax. In
this case, when the aggregate is eventually deselected and its
timestamps are updated, the aggregate may happen to have received an
amount of service larger than budgetmax. This may cause the aggregate
to be assigned a higher virtual finish time than the maximum
acceptable value for the last bucket in the bucket list of the group.
This fix introduces a cap that addresses this issue.
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Reviewed-by: Fabio Checconi <fchecconi@gmail.com>
---
net/sched/sch_qfq.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 6ed3765..0f6e2db 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -299,6 +299,10 @@ static void qfq_update_agg(struct qfq_sched *q, struct qfq_aggregate *agg,
new_num_classes == q->max_agg_classes - 1) /* agg no more full */
hlist_add_head(&agg->nonfull_next, &q->nonfull_aggs);
+ /* The next assignment may let
+ * agg->initial_budget > agg->budgetmax
+ * hold, we will take it into account in charge_actual_service().
+ */
agg->budgetmax = new_num_classes * agg->lmax;
new_agg_weight = agg->class_weight * new_num_classes;
agg->inv_w = ONE_FP/new_agg_weight;
@@ -990,8 +994,13 @@ static inline struct sk_buff *qfq_peek_skb(struct qfq_aggregate *agg,
/* Update F according to the actual service received by the aggregate. */
static inline void charge_actual_service(struct qfq_aggregate *agg)
{
- /* compute the service received by the aggregate */
- u32 service_received = agg->initial_budget - agg->budget;
+ /* Compute the service received by the aggregate, taking into
+ * account that, after decreasing the number of classes in
+ * agg, it may happen that
+ * agg->initial_budget - agg->budget > agg->bugdetmax
+ */
+ u32 service_received = min(agg->budgetmax,
+ agg->initial_budget - agg->budget);
agg->F = agg->S + (u64)service_received * agg->inv_w;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH BUGFIX 2/6] pkt_sched: fix the update of eligible-group sets
From: Paolo valente @ 2013-03-05 18:04 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller, shemminger
Cc: netdev, linux-kernel, fchecconi, rizzo, Paolo Valente
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
Between two invocations of make_eligible, the system virtual time may
happen to grow enough that, in its binary representation, a bit with
higher order than 31 flips. This happens especially with
TSO/GSO. Before this fix, the mask used in make_eligible was computed
as (1UL<<index_of_last_flipped_bit)-1, whose value is well defined on
a 64-bit architecture, because index_of_flipped_bit <= 63, but is in
general undefined on a 32-bit architecture if index_of_flipped_bit > 31.
The fix just replaces 1UL with 1ULL.
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Reviewed-by: Fabio Checconi <fchecconi@gmail.com>
---
net/sched/sch_qfq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 0f6e2db..4cbbf79 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -823,7 +823,7 @@ static void qfq_make_eligible(struct qfq_sched *q)
unsigned long old_vslot = q->oldV >> q->min_slot_shift;
if (vslot != old_vslot) {
- unsigned long mask = (1UL << fls(vslot ^ old_vslot)) - 1;
+ unsigned long mask = (1ULL << fls(vslot ^ old_vslot)) - 1;
qfq_move_groups(q, mask, IR, ER);
qfq_move_groups(q, mask, IB, EB);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH BUGFIX 3/6] pkt_sched: serve activated aggregates immediately if the scheduler is empty
From: Paolo valente @ 2013-03-05 18:04 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller, shemminger
Cc: netdev, linux-kernel, fchecconi, rizzo, Paolo Valente
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
If no aggregate is in service, then the function qfq_dequeue() does
not dequeue any packet. For this reason, to guarantee QFQ+ to be work
conserving, a just-activated aggregate must be set as in service
immediately if it happens to be the only active aggregate.
This is done by the function qfq_enqueue().
Unfortunately, the function qfq_add_to_agg(), used to add a class to
an aggregate, does not perform this important additional operation.
In particular, if: 1) qfq_add_to_agg() is invoked to complete the move
of a class from a source aggregate, becoming, for this move, inactive,
to a destination aggregate, becoming instead active, and 2) the
destination aggregate becomes the only active aggregate, then this
aggregate is not however set as in service. QFQ+ remains then in a
non-work-conserving state until a new invocation of qfq_enqueue()
recovers the situation.
This fix solves the problem by moving the logic for setting an
aggregate as in service directly into the function qfq_activate_agg().
Hence, from whatever point qfq_activate_aggregate() is invoked, QFQ+
remains work conserving. Since the more-complex logic of this new
version of activate_aggregate() is not necessary, in qfq_dequeue(), to
reschedule an aggregate that finishes its budget, then the aggregate
is now rescheduled by invoking directly the functions needed.
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Reviewed-by: Fabio Checconi <fchecconi@gmail.com>
---
net/sched/sch_qfq.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 4cbbf79..0dbec31 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1005,6 +1005,12 @@ static inline void charge_actual_service(struct qfq_aggregate *agg)
agg->F = agg->S + (u64)service_received * agg->inv_w;
}
+static inline void qfq_update_agg_ts(struct qfq_sched *q,
+ struct qfq_aggregate *agg,
+ enum update_reason reason);
+
+static void qfq_schedule_agg(struct qfq_sched *q, struct qfq_aggregate *agg);
+
static struct sk_buff *qfq_dequeue(struct Qdisc *sch)
{
struct qfq_sched *q = qdisc_priv(sch);
@@ -1032,7 +1038,7 @@ static struct sk_buff *qfq_dequeue(struct Qdisc *sch)
in_serv_agg->initial_budget = in_serv_agg->budget =
in_serv_agg->budgetmax;
- if (!list_empty(&in_serv_agg->active))
+ if (!list_empty(&in_serv_agg->active)) {
/*
* Still active: reschedule for
* service. Possible optimization: if no other
@@ -1043,8 +1049,9 @@ static struct sk_buff *qfq_dequeue(struct Qdisc *sch)
* handle it, we would need to maintain an
* extra num_active_aggs field.
*/
- qfq_activate_agg(q, in_serv_agg, requeue);
- else if (sch->q.qlen == 0) { /* no aggregate to serve */
+ qfq_update_agg_ts(q, in_serv_agg, requeue);
+ qfq_schedule_agg(q, in_serv_agg);
+ } else if (sch->q.qlen == 0) { /* no aggregate to serve */
q->in_serv_agg = NULL;
return NULL;
}
@@ -1228,17 +1235,11 @@ static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
cl->deficit = agg->lmax;
list_add_tail(&cl->alist, &agg->active);
- if (list_first_entry(&agg->active, struct qfq_class, alist) != cl)
- return err; /* aggregate was not empty, nothing else to do */
-
- /* recharge budget */
- agg->initial_budget = agg->budget = agg->budgetmax;
+ if (list_first_entry(&agg->active, struct qfq_class, alist) != cl ||
+ q->in_serv_agg == agg)
+ return err; /* non-empty or in service, nothing else to do */
- qfq_update_agg_ts(q, agg, enqueue);
- if (q->in_serv_agg == NULL)
- q->in_serv_agg = agg;
- else if (agg != q->in_serv_agg)
- qfq_schedule_agg(q, agg);
+ qfq_activate_agg(q, agg, enqueue);
return err;
}
@@ -1295,8 +1296,15 @@ skip_update:
static void qfq_activate_agg(struct qfq_sched *q, struct qfq_aggregate *agg,
enum update_reason reason)
{
+ agg->initial_budget = agg->budget = agg->budgetmax; /* recharge budg. */
+
qfq_update_agg_ts(q, agg, reason);
- qfq_schedule_agg(q, agg);
+ if (q->in_serv_agg == NULL) { /* no aggr. in service or scheduled */
+ q->in_serv_agg = agg; /* start serving this aggregate */
+ /* update V: to be in service, agg must be eligible */
+ q->oldV = q->V = agg->S;
+ } else if (agg != q->in_serv_agg)
+ qfq_schedule_agg(q, agg);
}
static void qfq_slot_remove(struct qfq_sched *q, struct qfq_group *grp,
--
1.7.9.5
^ permalink raw reply related
* [PATCH BUGFIX 4/6] pkt_sched: prevent budget from wrapping around after a dequeue
From: Paolo valente @ 2013-03-05 18:05 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller, shemminger
Cc: netdev, linux-kernel, fchecconi, rizzo, Paolo Valente
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
Aggregate budgets are computed so as to guarantee that, after an
aggregate has been selected for service, that aggregate has enough
budget to serve at least one maximum-size packet for the classes it
contains. For this reason, after a new aggregate has been selected
for service, its next packet is immediately dequeued, without any
further control.
The maximum packet size for a class, lmax, can be changed through
qfq_change_class(). In case the user sets lmax to a lower value than
the the size of some of the still-to-arrive packets, QFQ+ will
automatically push up lmax as it enqueues these packets. This
automatic push up is likely to happen with TSO/GSO.
In any case, if lmax is assigned a lower value than the size of some
of the packets already enqueued for the class, then the following
problem may occur: the size of the next packet to dequeue for the
class may happen to be larger than lmax, after the aggregate to which
the class belongs has been just selected for service. In this case,
even the budget of the aggregate, which is an unsigned value, may be
lower than the size of the next packet to dequeue. After dequeueing
this packet and subtracting its size from the budget, the latter would
wrap around.
This fix prevents the budget from wrapping around after any packet
dequeue.
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Reviewed-by: Fabio Checconi <fchecconi@gmail.com>
---
net/sched/sch_qfq.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 0dbec31..26149e2 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1070,7 +1070,15 @@ static struct sk_buff *qfq_dequeue(struct Qdisc *sch)
qdisc_bstats_update(sch, skb);
agg_dequeue(in_serv_agg, cl, len);
- in_serv_agg->budget -= len;
+ /* If lmax is lowered, through qfq_change_class, for a class
+ * owning pending packets with larger size than the new value
+ * of lmax, then the following condition may hold.
+ */
+ if (unlikely(in_serv_agg->budget < len))
+ in_serv_agg->budget = 0;
+ else
+ in_serv_agg->budget -= len;
+
q->V += (u64)len * IWSUM;
pr_debug("qfq dequeue: len %u F %lld now %lld\n",
len, (unsigned long long) in_serv_agg->F,
--
1.7.9.5
^ permalink raw reply related
* [PATCH BUGFIX 5/6] pkt_sched: do not allow virtual time to jump if an aggregate is in service
From: Paolo valente @ 2013-03-05 18:05 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller, shemminger
Cc: netdev, linux-kernel, fchecconi, rizzo, Paolo Valente
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
By definition of (the algorithm of) QFQ+, the system virtual time must
be pushed up only if there is no 'eligible' aggregate, i.e. no
aggregate that would have started to be served also in the ideal
system emulated by QFQ+. QFQ+ serves only eligible aggregates, hence
the aggregate currently in service is eligible. As a consequence, to
decide whether there is no eligible aggregate, QFQ+ must also check
whether there is no aggregate in service.
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Reviewed-by: Fabio Checconi <fchecconi@gmail.com>
---
net/sched/sch_qfq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 26149e2..5d327b3 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1281,7 +1281,8 @@ static void qfq_schedule_agg(struct qfq_sched *q, struct qfq_aggregate *agg)
/* group was surely ineligible, remove */
__clear_bit(grp->index, &q->bitmaps[IR]);
__clear_bit(grp->index, &q->bitmaps[IB]);
- } else if (!q->bitmaps[ER] && qfq_gt(roundedS, q->V))
+ } else if (!q->bitmaps[ER] && qfq_gt(roundedS, q->V) &&
+ q->in_serv_agg == NULL)
q->V = roundedS;
grp->S = roundedS;
--
1.7.9.5
^ permalink raw reply related
* [PATCH BUGFIX 6/6] pkt_sched: remove a useless invocation of qfq_update_eligible
From: Paolo valente @ 2013-03-05 18:05 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller, shemminger
Cc: netdev, linux-kernel, fchecconi, rizzo, Paolo Valente
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
QFQ+ can select for service only 'eligible' aggregates, i.e.,
aggregates that would have started to be served also in the emulated
ideal system. As a consequence, for QFQ+ to be work conserving, at
least one of the active aggregates must be eligible when it is time to
choose the next aggregate to serve.
The set of eligible aggregates is updated through the function
qfq_update_eligible(), which does guarantee that, after its
invocation, at least one of the active aggregates is eligible.
Because of this property, this function is invoked in
qfq_deactivate_agg() to guarantee that at least one of the active
aggregates is still eligible after an aggregate has been deactivated.
In particular, the critical case is when there are other active
aggregates, but the aggregate being deactivated happens to be the only
one eligible.
However, this precaution is not needed for QFQ+ to be work conserving,
because update_eligible() is always invoked also at the beginning of
qfq_choose_next_agg(). This patch removes the additional invocation of
update_eligible() in qfq_deactivate_agg().
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Reviewed-by: Fabio Checconi <fchecconi@gmail.com>
---
net/sched/sch_qfq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 5d327b3..7cfa1f8 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1385,8 +1385,6 @@ static void qfq_deactivate_agg(struct qfq_sched *q, struct qfq_aggregate *agg)
__set_bit(grp->index, &q->bitmaps[s]);
}
}
-
- qfq_update_eligible(q);
}
static void qfq_qlen_notify(struct Qdisc *sch, unsigned long arg)
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next] tcp: ipv6: bind() use stronger condition for bind_conflict
From: Flavio Leitner @ 2013-03-05 18:11 UTC (permalink / raw)
To: netdev; +Cc: Hideaki YOSHIFUJI, Flavio Leitner
We must try harder to get unique (addr, port) pairs when
doing port autoselection for sockets with SO_REUSEADDR
option set.
This is a continuation of commit aacd9289af8b82f5fb01bcdd53d0e3406d1333c7
for IPv6.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
net/ipv6/inet6_connection_sock.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index b386a2c..f7f49bf 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -55,6 +55,10 @@ int inet6_csk_bind_conflict(const struct sock *sk,
if (ipv6_rcv_saddr_equal(sk, sk2))
break;
}
+ if (!relax && reuse && sk2->sk_reuse &&
+ sk2->sk_state != TCP_LISTEN &&
+ ipv6_rcv_saddr_equal(sk, sk2))
+ break;
}
}
--
1.8.1.4
^ permalink raw reply related
* network-namespace and NETLINK_INET_DIAG - kernel v3.2.39-longterm
From: Dilip Daya @ 2013-03-05 18:20 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
Hi Eric et al,
Re: Network-namespace and NETLINK_INET_DIAG
=> Kernel v3.2.39-longterm
Within a default/host namespace:
--------------------------------
# strace /bin/ss -pim
execve("/bin/ss", ["/bin/ss", "-pim"], [/* 28 vars */]) = 0
...
...
socket(PF_NETLINK, SOCK_RAW, 4) = 3
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
msg_iov(1)=[{"L\0\0\0\22\0\1\3@\342\1\0\0\0\0\0\2\0\0\17\0\0
\0\0\0\0\0\0\0\0\0\0"..., 76}],
msg_controllen=0,
msg_flags=0}, 0) = 76
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
msg_iov(1)=[{"\344\0\0\0\22\0\2\0@\342\1\0\31|\0\0\2\1\2\0\0
\26\353;\300\250\2=088 "..., 8192}],
msg_controllen=0, msg_flags=0}, 0) = 684
...
# /bin/ss -pim
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.2.61:ssh 192.168.2.62:60220
users:(("sshd",7491,3))
mem:(r0,w0,f0,t0) cubic wscale:5,5 rto:216 rtt:18.5/19 ato:40 cwnd:10
send 6.3Mbps rcv_rtt:4 rcv_space:14480
Within a network-namespace:
---------------------------
# strace /bin/ss -pim
execve("/bin/ss", ["/bin/ss", "-pim"], [/* 28 vars */]) = 0
...
...
socket(PF_NETLINK, SOCK_RAW, 4) = 5
sendmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
msg_iov(1)=[{"L\0\0\0\22\0\1\3@\342\1\0\0\0\0\0\2\0\0\17\0\0
\0\0\0\0\0\0\0\0\0\0"..., 76}],
msg_controllen=0,
msg_flags=0}, 0) = -1 ECONNREFUSED (Connection refused)
...
# /bin/ss -pim
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.2.61:ssh 192.168.2.62:60220
rto:0.21 ato:0.04 cwnd:10 bidir
users:(("sshd",7491,3))
=> Network namespace (kernel v3.2.39-longterm) not allowing /bin/ss
missing information from structs tcp_info and inet_diag_meminfo.
This is fixed in kernel v3.6-rc1. Are there identifiable patchsets
from kernel v3.6-rc1 that can be easily backported to
kernel v3.2.x-longterm ??
Thanks.
--
-DilipD.
^ permalink raw reply
* Re: From Capt: Mohamed Habbash
From: Capt: Mohamed Habbash @ 2013-03-05 18:19 UTC (permalink / raw)
Assalamu'alaikum, wr,wb.,
Attn:Dear,
I am, Capt: Mohamed Habbash, am seeking for an Agent in your country to transfer $10.3Million US Dollars for investment get back for more Detail, if interested.
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Srivatsa S. Bhat @ 2013-03-05 18:27 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Lai Jiangshan, Michel Lespinasse, linux-doc, peterz, fweisbec,
linux-kernel, namhyung, mingo, linux-arch, linux, xiaoguangrong,
wangyun, paulmck, nikunj, linux-pm, rusty, rostedt, rjw,
vincent.guittot, tglx, linux-arm-kernel, netdev, oleg, sbw, tj,
akpm, linuxppc-dev
In-Reply-To: <51361C71.5060502@cn.fujitsu.com>
Hi Lai,
On 03/05/2013 09:55 PM, Lai Jiangshan wrote:
> Hi, Srivatsa,
>
> I'm sorry again, I delayed your works.
>
No, you didn't :-) I have been busy with some internal work lately,
so I haven't been able to go through the recent discussions and
review the new code carefully.. I'll get to it as soon as I can.
> I have some thinkings about the way how to get this work done.
>
> First step: (2~3 patches)
> Use preempt_disable() to implement get_online_cpu_atomic(), and add lockdep for it.
>
> Second step:
> Conversion patches.
>
> We can send the patchset of the above steps at first.
> {
> It does not change any behavior of the kernel.
> and it is annotation(instead of direct preempt_diable() without comments sometimes),
> so I expected they can be merged very early.
> }
>
> Third step:
> After all people confide the conversion patches covered all cases and cpuhotplug site is ready for it,
> we will implement get_online_cpu_atomic() via locks and remove stop_machine() from cpuhotplug.
>
> Any thought?
>
That sounds like a good plan. It might involve slightly more churn
than just directly changing the locking scheme, but it is safer.
And the extra churn is anyway limited only to the implementation of
get/put_online_cpus_atomic().. so that should be fine IMHO.
>
> If I have time, I will help you for the patches of the first step.
> (I was assigned bad job in office-time, I can only do kernel-dev work in night.)
>
> And for step2, I will write a checklist or spatch-script.
>
Do look at the conversion already done in this v6 as well. In
addition to that, we will have to account for the new kernel
code that went in recently.
I'll get back to working on the above mentioned aspects soon.
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [PATCH] SCTP: Free the per-net sysctl table on net exit. v2
From: David Miller @ 2013-03-05 19:32 UTC (permalink / raw)
To: mmokrejs; +Cc: ebiederm, vyasevich, netdev, linux-sctp, stable
In-Reply-To: <5135B542.8020905@fold.natur.cuni.cz>
From: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Date: Tue, 05 Mar 2013 10:05:06 +0100
> this is to let you know that this patch is still not in stable.
> I just fetched 3.7.10 and reproduced the original problem.
3.7.x is end of life and no longer being actively maintained.
^ permalink raw reply
* Re: [PATCH 1/1] net: ipv4: Remove redundant NULL check
From: David Miller @ 2013-03-05 19:40 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev
In-Reply-To: <1362482829-10455-1-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Tue, 5 Mar 2013 16:57:09 +0530
> kfree on a null pointer is a NO-OP. Hence null check is not necessary.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Unnecessary writes to the socket struct should be avoided, as it
generates unnecessary write traffic to the L2 cache.
I'm not applying this.
^ permalink raw reply
* Re: [RFC PATCH 1/5] net: implement support for low latency socket polling
From: David Miller @ 2013-03-05 19:55 UTC (permalink / raw)
To: bhutchings
Cc: eliezer.tamir, linux-kernel, netdev, jesse.brandeburg,
e1000-devel, willemb, andi, hpa, eliezer
In-Reply-To: <1362501781.2791.19.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 5 Mar 2013 16:43:01 +0000
> In general it appears to require a run-time check. You might need to
> augment <asm/timex.h>.
On the other hand, unlike get_cycles, sched_clock() is always available.
^ permalink raw reply
* Re: [RFC PATCH 1/5] net: implement support for low latency socket polling
From: David Miller @ 2013-03-05 19:57 UTC (permalink / raw)
To: eliezer.tamir
Cc: bhutchings, eliezer.tamir, linux-kernel, netdev, jesse.brandeburg,
e1000-devel, willemb, andi, hpa, eliezer
In-Reply-To: <5136282E.9080307@linux.intel.com>
From: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Date: Tue, 05 Mar 2013 19:15:26 +0200
> We are not very sensitive to this setting, anything on the order of
> your half round time trip plus a few standard deviations works well.
> We are busy waiting, so setting a higher value does not change the
> results much.
This makes the argument for using sched_clock() even stronger.
^ permalink raw reply
* Re: [RFC PATCH 1/5] net: implement support for low latency socket polling
From: H. Peter Anvin @ 2013-03-05 20:03 UTC (permalink / raw)
To: David Miller
Cc: eliezer.tamir, willemb, e1000-devel, netdev, jesse.brandeburg,
linux-kernel, andi, bhutchings, eliezer
In-Reply-To: <20130305.145524.1486936679665458305.davem@davemloft.net>
On 03/05/2013 11:55 AM, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue, 5 Mar 2013 16:43:01 +0000
>
>> In general it appears to require a run-time check. You might need to
>> augment <asm/timex.h>.
>
> On the other hand, unlike get_cycles, sched_clock() is always available.
>
On the gripping hand, we need to know when it uses something like
jiffies, in which case we probably need to disable the whole interface.
-hpa
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: network-namespace and NETLINK_INET_DIAG - kernel v3.2.39-longterm
From: Eric W. Biederman @ 2013-03-05 21:01 UTC (permalink / raw)
To: dilip.daya; +Cc: netdev
In-Reply-To: <1362507649.2840.55.camel@pro6455b.example.com>
Dilip Daya <dilip.daya@hp.com> writes:
> Hi Eric et al,
>
> Re: Network-namespace and NETLINK_INET_DIAG
>
> => Network namespace (kernel v3.2.39-longterm) not allowing /bin/ss
> missing information from structs tcp_info and inet_diag_meminfo.
> This is fixed in kernel v3.6-rc1. Are there identifiable patchsets
> from kernel v3.6-rc1 that can be easily backported to
> kernel v3.2.x-longterm ??
Possibly. Certainly the patches that changed this were INET_DIAG
specific. Take a look in the git history.
Not having a feature implemented is not the same as a bug. So I don't
expect anyone is in a rush to backport this.
Eric
^ permalink raw reply
* Re: [PATCH] SCTP: Free the per-net sysctl table on net exit. v2
From: Martin Mokrejs @ 2013-03-05 21:04 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, vyasevich, netdev, linux-sctp, stable
In-Reply-To: <20130305.143233.739103204837913775.davem@davemloft.net>
David Miller wrote:
> From: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
> Date: Tue, 05 Mar 2013 10:05:06 +0100
>
>> this is to let you know that this patch is still not in stable.
>> I just fetched 3.7.10 and reproduced the original problem.
>
> 3.7.x is end of life and no longer being actively maintained.
??? 3.7.10 was released on 2013-02-27.
I disagree with making a kernel line 3.7 released on 2012-12-11 unsupported
while 3.8.0 was released just on 2013-02-18. That is way too new. Sorry
to say that but I don't expect 3.8 to be tested properly like 3.7.4 was
NOT in January 2013 when I reported the particular sctp bug, and several
others in USB, pci/e hotplug, etc. Now, with 3.8.2 being out one day
already I will hit for sure other bugs. I really want something stable.
For USB3.0 I need 3.2.x at least, actually 3.5 for some better URB handling
... The already buggy (in 3.2.x PCI/e hotplug) got reworked in about 3.5
into another buggy behavior so another workaround had to be invented.
Of course I do appreciate your work but if somebody bothered to report a bug
and some devs bothered to provide patches, you should let the fix go into life.
It is waiting in the patchwork since 1,5 month. By that time, 3.7.x was the
current, latest&greatest stable. I just don't agree.
Sorry for such a rant, I couldn't resist. ;)
Martin
^ permalink raw reply
* Re: [PATCH] SCTP: Free the per-net sysctl table on net exit. v2
From: David Miller @ 2013-03-05 21:08 UTC (permalink / raw)
To: mmokrejs; +Cc: ebiederm, vyasevich, netdev, linux-sctp, stable
In-Reply-To: <51365DC5.5010003@fold.natur.cuni.cz>
From: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Date: Tue, 05 Mar 2013 22:04:05 +0100
> Sorry for such a rant, I couldn't resist. ;)
Thankfully none of the stable maintainers had to actually read your
rant because you got the stable address wrong.
^ permalink raw reply
* Re: [PATCH 1/2] benet: Wait f/w POST until timeout
From: David Miller @ 2013-03-05 21:34 UTC (permalink / raw)
To: shangw; +Cc: netdev, sathya.perla, subbu.seetharaman, ajit.khaparde
In-Reply-To: <1362383327-32362-1-git-send-email-shangw@linux.vnet.ibm.com>
From: Gavin Shan <shangw@linux.vnet.ibm.com>
Date: Mon, 4 Mar 2013 15:48:46 +0800
> While PCI card faces EEH errors, reset (usually hot reset) is
> expected to recover from the EEH errors. After EEH core finishes
> the reset, the driver callback (be_eeh_reset) is called and wait
> the firmware to complete POST successfully. The original code would
> return with error once detecting failure during POST stage. That
> seems not enough.
>
> The patch forces the driver (be_eeh_reset) to wait the firmware
> completes POST until timeout, instead of returning error upon
> detection POST failure immediately. Also, it would improve the
> reliability of the EEH funtionality of the driver.
>
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
I know that patch #2 of this series needs to be implemented differently,
but this patch seems fine.
So can I get an ACK from one of the benet driver folks?
Thanks.
^ permalink raw reply
* Re: mac80211: regression: fd0f979 no long authenticates w/ath9k_htc
From: Corey Richardson @ 2013-03-05 21:49 UTC (permalink / raw)
To: John W. Linville, Johannes Berg, David S. Miller, linux-wireless,
netdev, linux-kernel, Johannes Berg
On Mon, Mar 4, 2013 at 3:42 AM, Corey Richardson <corey@octayn.net> wrote:
> ath9k_htc driver , AR9271 (at least according to lsusb)
>
> commit fd0f979a1b67f0889aea24a7c7d2a54d6706a1cf
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: Thu Feb 7 00:14:51 2013 +0100
>
> mac80211: simplify idle handling
>
> Now that we have channel contexts, idle is (pretty
> much) equivalent to not having a channel context.
> Change the code to use this relation so that there
> no longer is a need for a lot of idle recalculate
> calls everywhere.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>
> :040000 040000 85b3d4d114efb012773b4c7e1728b5bcae2e6b37
> 3ff33170763520b03e84e067f91cc0a8334e4d36 M net
>
> any more info needed?
I noticed the mail didn't get through to all lists, perhaps the
attachments were too large? (~135K)
Files are at https://gist.github.com/cmr/a5ace41e765fca073201
^ permalink raw reply
* Verify Your Account.
From: Outlook Team. @ 2013-03-05 22:18 UTC (permalink / raw)
To: netdev
Dear Webmail User,
Due to Spam mails,Web E-mail account needs to be Re validated and
Re-confirmed by using/clicking the link below:
https://docs.google.com/a/blumail.org/spreadsheet/viewform?formkey=dEhZS25ZQmZFbTNpY21rWkdvZkFRanc6MQ
Warning:Failure to comply to this message, your account will be
deactivated from our database in 24 hrs
We are sorry for this inconveniences this may cause you.
Thank You,
Outlook Team.
^ permalink raw reply
* Re: tipc: MTU discovery
From: Ying Xue @ 2013-03-06 1:23 UTC (permalink / raw)
To: Sebastian Pöhn; +Cc: Erik Hugne, netdev, jon.maloy, allan.stephens
In-Reply-To: <CAGUzgdLyqett=78cVYYVWi=ZRE_Z4xgp8tB+jRyEeykcPxRjOQ@mail.gmail.com>
1. Can you dump all TIPC packets for us while TIPC link is established?
2. There has a big gap between 2.6.32 and 3.8, meaning TIPC code is also
made big changes. If you can reproduce the problem on latest kernel
version, please let us know.
Thanks,
Ying
On 03/06/2013 12:22 AM, Sebastian Pöhn wrote:
> I run a DLink DGE-528T (PCI-ID: 1186:4300). Kernel is 2.6.32
> There is a dedicated VLAN sitting over the physical device.
>
> I even made some similar observations in a VM environment but I think
> this is even a more fragile setup.
>
> Will install ethtool ...
>
> On Tue, Mar 5, 2013 at 3:18 PM, Erik Hugne <erik.hugne@ericsson.com> wrote:
>> On Tue, Mar 05, 2013 at 01:43:29PM +0100, Sebastian Pöhn wrote:
>>> State Messages larger than 1500 which as used for the MTU negotiation
>>> do not appear in the TIPC stack. But I am able to seen them entering
>>> the correct device.
>>> Because of that no reply with the correct max_packet field set can be
>>> send and the negotiation will always end up at 1.5k.
>>>
>>> So my questions are:
>>> # Is TIPC meant to detect and use the MTU larger than 1.5k?
>> Yes, it should probe and detect MTU's up to ~66k
>>
>>> # Why are the packets not passed to the TIPC stack?
>> TIPC just registers itself as a handler for ETH_P_TIPC through
>> dev_add_pack.
>> If link mtu probes >1.5k are not passed to TIPC, it sounds to me that the
>> NIC driver
>> is to blame. What NIC type and kernel version are you running?
>>
>> Do you see any packet drops in ethtool statistics?
>>
>> //E
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH net-next 1/2] net: introduce NAPI_POLL_WEIGHT
From: Eric Dumazet @ 2013-03-06 1:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eilon Greenstein
From: Eric Dumazet <edumazet@google.com>
Some drivers use a too big NAPI poll weight.
This patch adds a NAPI_POLL_WEIGHT default value
and issues an error message if a driver attempts
to use a bigger weight.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Eilon Greenstein <eilong@broadcom.com>
---
include/linux/netdevice.h | 5 +++++
net/core/dev.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index b3d00fa..896eb49 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1475,6 +1475,11 @@ static inline void *netdev_priv(const struct net_device *dev)
*/
#define SET_NETDEV_DEVTYPE(net, devtype) ((net)->dev.type = (devtype))
+/* Default NAPI poll() weight
+ * Device drivers are strongly advised to not use bigger value
+ */
+#define NAPI_POLL_WEIGHT 64
+
/**
* netif_napi_add - initialize a napi context
* @dev: network device
diff --git a/net/core/dev.c b/net/core/dev.c
index a06a7a5..9610389 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4057,6 +4057,9 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
napi->gro_list = NULL;
napi->skb = NULL;
napi->poll = poll;
+ if (weight > NAPI_POLL_WEIGHT)
+ pr_err_once("netif_napi_add() called with weight %d on device %s\n",
+ weight, dev->name);
napi->weight = weight;
list_add(&napi->dev_list, &dev->napi_list);
napi->dev = dev;
^ permalink raw reply related
* [PATCH net-next 2/2] bnx2x: use the default NAPI weight
From: Eric Dumazet @ 2013-03-06 1:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eilon Greenstein
From: Eric Dumazet <edumazet@google.com>
BQL (Byte Queue Limits) proper operation needs TX completion
being serviced in a timely fashion.
bnx2x uses a non standard NAPI poll weight, and thats not fair to other
napi poll handlers, and even not reasonable.
Use the default value instead.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 -
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index e4605a9..9577cce 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -492,7 +492,6 @@ enum bnx2x_tpa_mode_t {
struct bnx2x_fastpath {
struct bnx2x *bp; /* parent */
-#define BNX2X_NAPI_WEIGHT 128
struct napi_struct napi;
union host_hc_status_block status_blk;
/* chip independed shortcuts into sb structure */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index aee7671..8d158d8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -834,7 +834,7 @@ static inline void bnx2x_add_all_napi_cnic(struct bnx2x *bp)
/* Add NAPI objects */
for_each_rx_queue_cnic(bp, i)
netif_napi_add(bp->dev, &bnx2x_fp(bp, i, napi),
- bnx2x_poll, BNX2X_NAPI_WEIGHT);
+ bnx2x_poll, NAPI_POLL_WEIGHT);
}
static inline void bnx2x_add_all_napi(struct bnx2x *bp)
@@ -844,7 +844,7 @@ static inline void bnx2x_add_all_napi(struct bnx2x *bp)
/* Add NAPI objects */
for_each_eth_queue(bp, i)
netif_napi_add(bp->dev, &bnx2x_fp(bp, i, napi),
- bnx2x_poll, BNX2X_NAPI_WEIGHT);
+ bnx2x_poll, NAPI_POLL_WEIGHT);
}
static inline void bnx2x_del_all_napi_cnic(struct bnx2x *bp)
^ permalink raw reply related
* Re: [PATCH net-next 2/2] bnx2x: use the default NAPI weight
From: David Miller @ 2013-03-06 2:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, eilong
In-Reply-To: <1362535067.15793.146.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Mar 2013 17:57:47 -0800
> BQL (Byte Queue Limits) proper operation needs TX completion
> being serviced in a timely fashion.
>
> bnx2x uses a non standard NAPI poll weight, and thats not fair to other
> napi poll handlers, and even not reasonable.
Can you give some details about the situation in which you noticed
this?
It may be reason enough to target this for 'net' and -stable instead.
Thanks!
^ 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