* Re: [PATCH 1/5] ifb: remove function declarations
From: jamal @ 2010-12-15 12:31 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1292251414-5154-1-git-send-email-xiaosuo@gmail.com>
Sorry - I am very distracted with work but will get back to you
on these patches. If i can respond to from a quick glance such
as this one, I will do now.
On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
> Restructure to remove function declarations.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/5] ifb: code cleanup
From: jamal @ 2010-12-15 12:32 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1292251414-5154-2-git-send-email-xiaosuo@gmail.com>
On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
> Clean up code according to scripts/checkpatch.pl
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 4/5] ifb: add multiqueue support
From: jamal @ 2010-12-15 12:34 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1292251414-5154-4-git-send-email-xiaosuo@gmail.com>
On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
> Each ifb NIC has nr_cpu_ids rx queues and nr_cpu_ids queues. Packets
> transmitted to ifb are enqueued to the corresponding per cpu tx queues,
> and processed in the corresponding per cpu tasklet latter.
>
> The stats are converted to the u64 ones.
>
> tq is a stack variable now. It makes ifb_q_private smaller and tx queue
> locked only once in ri_tasklet.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
I will look closely at this one later and catchup with the discussion
you had with Eric.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/5] ifb: fix tx_queue_len overlimit
From: Changli Gao @ 2010-12-15 12:36 UTC (permalink / raw)
To: hadi; +Cc: David S. Miller, netdev
In-Reply-To: <1292416439.2067.6.camel@mojatatu>
On Wed, Dec 15, 2010 at 8:33 PM, jamal <hadi@cyberus.ca> wrote:
> On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
>> We should check the length of rq after enqueuing, otherwise the length
>> of rq will be over tx_queue_len.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Not sure about this one. The check is also for ==, so we are going
> to stop before we go over tx_queue_len. What am i missing?
>
But then, we put this skb into rq in any way, and the length of rq
becomes tx_queue_len + 1.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 3/5] ifb: fix tx_queue_len overlimit
From: jamal @ 2010-12-15 12:33 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1292251414-5154-3-git-send-email-xiaosuo@gmail.com>
On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
> We should check the length of rq after enqueuing, otherwise the length
> of rq will be over tx_queue_len.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Not sure about this one. The check is also for ==, so we are going
to stop before we go over tx_queue_len. What am i missing?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 5/5] net: add skb.old_queue_mapping
From: jamal @ 2010-12-15 12:40 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1292251414-5154-5-git-send-email-xiaosuo@gmail.com>
On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
> For the skbs returned from ifb, we should use the queue_mapping
> saved before ifb.
>
> We save old queue_mapping in old_queue_mapping just before calling
> dev_queue_xmit, and restore the old_queue_mapping to queue_mapping
> just before reinjecting the skb.
>
> dev_pick_tx() use the current queue_mapping for the skbs reinjected
> by ifb.
You are hard-coding policy here, no? ifb can do a lot of funky things
which change the nature of the flow. I can shape, i can edit packets
etc. Why is the queue mapping any different?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 3/5] ifb: fix tx_queue_len overlimit
From: jamal @ 2010-12-15 12:42 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <AANLkTi=GTo=JZ5kDEXpZDNdK1RdtirP6G8TmaJARmeL+@mail.gmail.com>
On Wed, 2010-12-15 at 20:36 +0800, Changli Gao wrote:
>
> But then, we put this skb into rq in any way, and the length of rq
> becomes tx_queue_len + 1.
;->
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: |PATCH net-next-2.6] ifb: use netif_receive_skb() instead of netif_rx()
From: jamal @ 2010-12-15 12:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Changli Gao, David S. Miller, Stephen Hemminger, Tom Herbert,
Jiri Pirko, netdev, netem
In-Reply-To: <1292402398.3427.6.camel@edumazet-laptop>
On Wed, 2010-12-15 at 09:39 +0100, Eric Dumazet wrote:
> In ri_tasklet(), we run from softirq, so can directly handle packet
> through netif_receive_skb() instead of netif_rx().
> There is no risk of recursion.
Eric, did you do at least a simple test on this one?
It used to be problematic (I cant remember why or
what use case was problematic).
cheers,
jamal
^ permalink raw reply
* Submission deadline extended to 2 Jan 2011 CFP: IFIP/IEEE DANMS 2011 (co-located with IM 2011)
From: danms2011 @ 2010-12-15 12:45 UTC (permalink / raw)
To: danms2011
(We apologize if you receive multiple copies of this message.)
CALL FOR PAPERS
IFIP/IEEE DANMS 2011
Forth International Workshop on Distributed Autonomous Network Management Systems
Co-located with IM 2011, Dublin, Ireland
www.danms.org
Important Dates
Paper submission deadline: 2 Jan 2011 (extended)
Notification of acceptance: 30 Jan 2011
Camera-ready paper: 15 Feb 2011
Paper Submission URL
https://jems.sbc.org.br/danms2011
The DANMS 2011 workshop is part of a series of workshops dedicated to advances in network management and the application of new management principles in network design.
This year’s workshop emphasizes on “Efficient Management of Loosely Collaborative Service Networks” where network connectivity providers, content and service providers come together to provide high-level services such as Over-The-Top (OTT) services to end-users in a loosely collaborative way.
In the recent past, end-user services such as high quality video calls, web-based video content servers, HD video streaming and VoD services etc. have driven the telecom market. The appearance of these new content/service providers, which include so called Over-The-Top (OTT) service providers, has driven network usage, but also created huge network management problems for the operators. In this context, content/service providers together with network operators provide value to the subscribers in a “loosely collaborative” fashion. Service assurance in this loose collaborative environment is challenging, particularly in the presence of a network with limited or no guarantees. This nascent eco-system is driving fundamental changes in how networks are deployed and managed as well as how they interact with content and service providers. In this context, together with wider network management contributions, we expect to have technical contributions in the areas of automated service assurance and in loosely collaborative service networks.
Topics of interest include (but are not limited to) the following:
* Federated network management
* Impact of Over the Top (OTT) services in resource management
* Case studies of service assurance
* Efficient use of terminal reports in service assurance
* SLA for OTT service assurance
* Service and resource modelling approaches for management
* Business rules and organizational modelling
* Use of semantics in service deployment and quality assurance
* Extensions and refinements of NM standards
* Aspects of service management and assurance
* Automated service provisioning across multiple service providers
* Fault and performance management, diagnosis, and troubleshooting
* End-to-end QoS management for enterprise networks
* Measurements and insights from network operations
* Metrics, techniques, and experiments for evaluating network
* Convergence of fixed and mobile networks
Steering Committee
Nazim Agoulmine, University of Evry Val d'Essonne France
Raouf Boutaba, University of Waterloo Canada
Gabriel Hogan, Network Management Lab, Ericsson, Ireland
Workshop Co-Chairs
Sidath Handurukande, Network Management Lab, Ericsson Ireland
Jose Neuman de Souza, Federal University of Ceara, Brazil
Publicity Chair
Yangcheng Huang, Ericsson Ireland
Technical Program Committee
Arosha Bandara, Open University, UK
Javier Baliosian, Uni. of the Republic, Uruguay
Saleem Bhatti, Uni. of St Andrews, UK
Sami Bhiri, DERI, Ireland
Anne-Marie Bosneag, Ericsson, Ireland
Anca Chandra, IBM Research, USA
Dave Cleary, Ericsson, Ireland
Zoran Despotovic, NTT DoCoMo Euro-Labs, Germany
Dominique Dudkowski, NEC, Germany
Liam Fallon, Ericsson, Ireland
James Hong, POSTECH, Korea
Jesse Kielthy, TSSG, Ireland
Francine Krief, Bordeaux 1 University, France
Petr Kuznetsov, Deutsche Telekom Laboratories, Germany
Brian Lee, AIT, Ireland
Declan O'Sullivan, Trinity College Dublin, Ireland
Gerard Parr, University of Ulster, UK
Luis Rodrigues, INESC-ID/IST, Portugal
Florian Schreiner, Fraunhofer FOKUS, Germany
Rolf Stadler, KTH, Sweden
Martin van Steen, Vrje University, Netherlands
Filip De Turck, Ghent University-IBBT, Belgium
Stefan Wallin, Luleå University of Technology, Sweden
Martin Zach, Siemens AG Austria
Paper Submission Instructions
Authors are invited to submit papers of maximum six pages or extended papers of up to eight pages (including figures, tables, and references), in the standard two-column, 11 pt font, IEEE conference paper format. Standard IEEE Transactions templates for Microsoft Word or LaTeX formats can be found at
http://www.ieee.org/portal/pages/pubs/transactions/stylesheets.html.
All work submitted must be original, not previously published or under submission at other venues.
At least one author of accepted papers must be present at the workshop, to present the paper. Accepted papers will be published by IEEE Xplore and indexed accordingly.
Only PDF files will be accepted for the review process and all submissions must be done through JEMS at the URL below:
https://jems.sbc.org.br/danms2011
^ permalink raw reply
* Re: [PATCH 5/5] net: add skb.old_queue_mapping
From: Changli Gao @ 2010-12-15 12:52 UTC (permalink / raw)
To: hadi; +Cc: David S. Miller, netdev
In-Reply-To: <1292416832.2067.13.camel@mojatatu>
On Wed, Dec 15, 2010 at 8:40 PM, jamal <hadi@cyberus.ca> wrote:
> On Mon, 2010-12-13 at 22:43 +0800, Changli Gao wrote:
>>
>> dev_pick_tx() use the current queue_mapping for the skbs reinjected
>> by ifb.
>
> You are hard-coding policy here, no? ifb can do a lot of funky things
> which change the nature of the flow. I can shape, i can edit packets
> etc. Why is the queue mapping any different?
>
It seems reasonable. Thanks. I'll remove this hard-coding policy.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [RFC PATCH v1] iproute2: add IFLA_TC support to 'ip link'
From: jamal @ 2010-12-15 13:19 UTC (permalink / raw)
To: John Fastabend
Cc: shemminger@vyatta.com, netdev@vger.kernel.org,
tgraf@infradead.org, eric.dumazet@gmail.com, davem@davemloft.net
In-Reply-To: <4D0134CC.8070605@intel.com>
Sorry for the latency.
On Thu, 2010-12-09 at 11:58 -0800, John Fastabend wrote:
> I think what we really want is a container to create groups of tx queues
> which can then be managed and given a scheduler. One reason for this is
> the 802.1Q spec allows for different schedulers to be running on different
> traffic classes including vendor specific schedulers. So having a root
> "hardware-kinda-8021q-sched" doesn't seem flexible enough to handle
> adding/removing schedulers per traffic class.
>
> With a container qdisc statistics roll up nicely as expected and
> the default scheduler can be the usual mq qdisc.
As far as i can see the "container" is a qdisc. The noun doesnt
matter, mq looks sufficient.
[I just said "hardware-kinda-8021q-sched" because what you posted didnt
look 8012q conformant.]
> A first take at this coming shortly. Any thoughts?
Havent had time to look at patches you posted.
> > Ok, so you can do rate control as well?
>
> Yes, but per tx_ring. So software needs to then balance the rings into
> an aggregated rate limiter. Using the container scheme I imagine a root
> mclass qdisc with multiple "sch_rate_limiter" qdiscs. This qdisc could
> manage the individual rate limiters per queue and get something like a
> rate limiter per groups of tx queues.
>
The qdisc semantics allow for hierachies i.e you could have qdiscs that
hold other qdiscs that each hold different scheduling algorithms etc.
> Yes this is how I would expect this to work. The prio mapping is configurable
> so I think this could be worked around by policy in tc. iproute2 would need
> to pick a reasonable default mapping.
>
> Warning thinking out loud here but maybe we could also add a qdisc op to pick
> the underlying tx queue basically a qdisc ops for dev_pick_tx(). This ops could
> be part of the root qdisc and called in dev_queue_xmit(). I would need to think
> about this some more to see if it is sane but bottom line is the tx queue needs
> to be learned before __dev_xmit_skb(). The default mechanism in this patch set
> being the skb prio.
>
You could use the qdisc major:minor to map to the hardware level queues.
But care is needed so that the user doesnt choose the wrong mapping, out
of boundary mapping etc. I am sure such validation can be done at
iproute2 level way before the hardware is configured.
cheers,
jamal
^ permalink raw reply
* Re: [RFC][net-next-2.6 PATCH 0/2] rtnetlink: New IFLA_PORT_PROTO_* attr
From: Arnd Bergmann @ 2010-12-15 13:33 UTC (permalink / raw)
To: Christian Benvenuti (benve)
Cc: netdev, davem, Stefan Berger, Roopa Prabhu (roprabhu),
David Wang (dwang2)
In-Reply-To: <184D23435BECB444AB6B9D4630C8EC83C7EE17@XMB-RCD-303.cisco.com>
On Tuesday 14 December 2010, Christian Benvenuti (benve) wrote:
> If we do not do it now, for sure later it will be either more
> painful or impossible (as of now we would need to deprecate only
> two attributes and nothing would break).
> It is not a mandatory step, but to us it would make sense to think
> in the long term too.
Right. I understood this from your original mail, but I still
disagree. I can't think of any reason why a future could have
a bigger impact than the change you are proposing now.
> > The changes you propose now seem reasonable and we could probably have
> > done it that way initially, but as far as I'm concerned they are too
> > late.
> > The burden imposed by the change is larger than the risk of breaking
> > backwards compatibility later by not fixing it now, as far as I'm
> > concerned.
>
> We would only deprecate two attributes and nothing would break actually.
Yes, that's true. It does mean though that every user of the interface
would have to deal with the old and the new interface. Deprecating a
kernel interface does not mean that we can stop supporting it in the
future.
> > I really don't think that you should add per-driver attributes. If we
> > believe that we need an extension for a specific feature in the
> > netlink interface, it should be defined in a way that is generic
> > enough to work for other hardware implementing the same feature.
>
> In general, yes, that's the way to go.
> However, the use case of IFLA_PORT_DATA would be that where the
> "extra config" is NOT generic enough to be shared with other hardware
> implementing the same feature. And because of that it may be hard
> to justify a change to the "shared" attribute scheme to include
> support for a vendor specific extra attribute.
If it's vendor specific, it's normally a bad idea, or not defined
as generic as it should be ;-)
Think of it this way: if the rest of the world thinks that they
should not implement this feature, maybe you shouldn't either.
If the feature is going to be implemented slightly differently
on other hardware, make the interface generic enough to cope
with either version.
> I agree.
> However, from a vendor/driver perspective, what matters more is the
> functionality/usefulness/performance_gain of the optional feature, and
> not the likelihood of having other vendors support the same feature.
> The idea behind IFLA_PORT_DATA is that of not having to change the
> Netlink (shared) attribute scheme to support anything that is not
> yet standard or will never be. As I said in the original email, it
> is just a way to pass more info down the stack synchronously with
> the shared attributes/data.
>
> Here is an example. Supposing there was _not_ agreement on the
> introduction of the a new IFLA_PORT_XYZ attribute because considered
> too vendor/driver-centric.
> In that case you either pass (async) XYZ to the driver using something
> like the Generic Netlink proto or sysfs or ... one cleaner option would
> be that of using IFLA_PORT_DATA, which would guarantee that the extra
> config gets sent synchronously with the rest of the config.
No. The right solution would be in that case to not implement the interface
at all until there is agreement on a cross-vendor solution. Generally
this is not the problem, because we deal with smart people that can
introduce an interface in a way that works for themselves and other
future users.
> > > If in the future driver ABC needed to change any of its private
> > > parameters (those it receives through the IFLA_PORT_DATA attribute),
> > > it can do it by updating its parsing routine (of course it would
> > > need to implement a basic versioning scheme for its private
> > > attributes), but no change would be required in the core Netlink
> > > code.
> >
> > A data structure being private to a driver would not save you from
> > maintaining backwards compatibility, you still cannot just go and
> > change it as you like.
>
> Yes of course.
> However in this case the driver itself would take care of it
> (RTNetlink does not need to know what is inside the IFLA_PORT_DATA
> attribute).
There is a significant difference between interfaces per functionality,
like we have GETLINK take different arguments on a vlan device than
on a bridge, and having interfaces on multiple device drivers implementing
the same thing. IMHO, there is nothing wrong with having a Cisco switch
specific interface in the IFLA_PORT_* family, and have only enic
implement this, as long as the interface allows other device drivers
to implement the exact same semantics when they want to talk to the
same switch.
> > Just don't add driver-private interfaces, make them official!
>
> I would not look at IFLA_PORT_DATA as a private-interface replacing
> the public one/s, but rather as a way to make it easier to configure
> new extensions without having to wait for a standard/spec to show up
> and make a case for the change to the shared Netlink scheme.
>
> Anyway, IFLA_PORT_DATA was just a proposal (which I think makes
> sense) and can be added/revisited at any time, not necessarily now.
> Since we were proposing a change to the Netlink scheme, I thought
> it was the right context to mention it too.
Yes, I think it's good that you brought it up. A lot of people want
private interfaces like this, and we should just document that this
is not the way to do it in Linux.
> In summary, here are the three points I would like to reach an
> agreement on:
>
> (A) Redesign of IFLA_PORT_* attributes as described in the
> original patch 0/2 post
>
> YES/NO?
>
> (I vote for "Yes")
It's not a vote, in the end you have to convince davem to take
it. My position is "No", as I have made clear, but this is mostly
because I see the advantages as insignificant and don't think
it's worth it.
> (B) Introduction of the following new attributes (with
> CLUSTER_UUID being top priority):
>
> - IFLA_PORT_CLUSTER_UUID : string UUID
> Used to scope the port profile
>
> - IFLA_PORT_CLIENT_TYPE : string
> Used to identify the type of entity using the port
> profile (OS type, etc).
>
> If we go for A/YES, the above two attributes would go
> into the new IFLA_PORT_8021QBH_* attr list.
>
> If we go for A/NO, they would be added to the
> IFLA_PORT_* attribute list and would be usable by all
> protocols.
No objections from me at all here.
> (C) Attribute versioning: #ifdef vs GET_VERSION
>
> On the libvirt side we need to #ifdef each time the attribute
> list changes. This is the default way of handling this kind
> of situation, however, by adding support for versioning (see
> my previous post) libvirt could detect the attribute "version"
> at run-time.
> I am fine with going with #ifdefs, unless someone expresses some
> interest in adding support for versioning (I would add it).
>
> I am OK in both cases (I think versioning is better but I
> understand the counter-argument).
This is where the large problem arises:
* #ifdef is bad because that means breaking compatibility with other
versions. As the qemu/kvm people found out years ago, the only
sane way to handle this is to keep the latest version of the interface
headers shipping with the code using it, and doing run-time checks
everywhere.
* Versioning is something we don't normally do in kernel interfaces,
it is not enough to describe the complexity, especially with selective
features getting backported into distributions etc. You essentially
have to try using an attribute to see if the kernel supports it.
Arnd
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: remove cancel_work_sync() from remove_one
From: Tejun Heo @ 2010-12-15 13:52 UTC (permalink / raw)
To: Michael Chan, David S. Miller, netdev; +Cc: lkml
In-Reply-To: <1292348880.7394.63.camel@nseg_linux_HP1.broadcom.com>
On 12/14/2010 06:48 PM, Michael Chan wrote:
>
> On Tue, 2010-12-14 at 08:09 -0800, Tejun Heo wrote:
>> Michael pointed out that bnx2_close() already cancels bp->reset_task
>> and thus it is guaranteed to be idle when bnx2_remove_one() is called.
>> Remove the unnecessary cancel_work_sync() in remove_one.
>>
>> Signed-off-by: Tejun Heo <tj@kernel.org>
>> Cc: Michael Chan <mchan@broadcom.com>
>
> Acked-by: Michael Chan <mchan@broadcom.com>
After looking through the code, I don't think this is necessarily
correct. ->ndo_close() doesn't guarantee that the watchdog timer has
finished running (the timer is deleted with del_timer() not
del_timer_sync()). ie. the watchdog timer could still be running
after ->ndo_close() and may schedule reset_task. If remove_one
doesn't flush the task, it may still be running when remove_one() is
called.
David, am I missing something? Wouldn't it cleaner to guarantee that
->ndo_close() is called with the guarantee that the watchdog timer is
not running anymore?
--
tejun
^ permalink raw reply
* Re: [OOPS]e1000e .ko 1.0.2-k2
From: Ben Hutchings @ 2010-12-15 13:52 UTC (permalink / raw)
To: cpwu; +Cc: netdev
In-Reply-To: <1292402583.2484.25.camel@cephhost>
On Wed, 2010-12-15 at 16:43 +0800, Jeff Wu wrote:
> Hi ,
>
> iozone test for our distributed file system ,
> we detect a oops(see below ,logs).
This is not an oops.
[...]
> [181174.967056] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
[...]
Read that line again.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] net_sched: sch_sfq: fix allot handling
From: Eric Dumazet @ 2010-12-15 14:03 UTC (permalink / raw)
To: David Miller; +Cc: Patrick McHardy, netdev, Jarek Poplawski
When deploying SFQ/IFB here at work, I found the allot management was
pretty wrong in sfq, even changing allot from short to int...
We should init allot for each new flow turn, not using a previous value,
or else small packets can easily make allot overflow.
Before patch, I saw burst of several packets per flow, apparently
denying the "allot 1514" limit I had on my SFQ class.
class sfq 11:1 parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 7p requeues 0
allot 11546
class sfq 11:46 parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 1p requeues 0
allot -23873
class sfq 11:78 parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 5p requeues 0
allot 11393
After patch, better fairness among each flow, allot limit being
respected.
class sfq 11:52 parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 4p requeues 0
allot 1514
class sfq 11:60 parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 3p requeues 0
allot -586
class sfq 11:6b parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 3p requeues 0
allot -586
class sfq 11:71 parent 11:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 3p requeues 0
allot 1514
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_sfq.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 3cf478d..8c8a190 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -270,7 +270,7 @@ static unsigned int sfq_drop(struct Qdisc *sch)
/* It is difficult to believe, but ALL THE SLOTS HAVE LENGTH 1. */
d = q->next[q->tail];
q->next[q->tail] = q->next[d];
- q->allot[q->next[d]] += q->quantum;
+ q->allot[q->next[d]] = q->quantum;
skb = q->qs[d].prev;
len = qdisc_pkt_len(skb);
__skb_unlink(skb, &q->qs[d]);
@@ -321,14 +321,13 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
sfq_inc(q, x);
if (q->qs[x].qlen == 1) { /* The flow is new */
if (q->tail == SFQ_DEPTH) { /* It is the first flow */
- q->tail = x;
q->next[x] = x;
- q->allot[x] = q->quantum;
} else {
q->next[x] = q->next[q->tail];
q->next[q->tail] = x;
- q->tail = x;
}
+ q->tail = x;
+ q->allot[x] = q->quantum;
}
if (++sch->q.qlen <= q->limit) {
sch->bstats.bytes += qdisc_pkt_len(skb);
@@ -382,11 +381,11 @@ sfq_dequeue(struct Qdisc *sch)
return skb;
}
q->next[q->tail] = a;
- q->allot[a] += q->quantum;
+ q->allot[a] = q->quantum;
} else if ((q->allot[a] -= qdisc_pkt_len(skb)) <= 0) {
q->tail = a;
a = q->next[a];
- q->allot[a] += q->quantum;
+ q->allot[a] = q->quantum;
}
return skb;
}
^ permalink raw reply related
* [PATCH net-next-2.6] vxge: add missing flush of reset_task
From: Tejun Heo @ 2010-12-15 14:03 UTC (permalink / raw)
To: David S. Miller, netdev@vger.kernel.org, lkml, jon.mason
Commit 6e07ebd84 (drivers/net: remove unnecessary
flush_scheduled_work() calls) incorrectly removed the flush call
without replacing it with the appropriate work specific operation.
Fix it by flushing vdev->reset_task explicitly.
Pointed out by Jon Mason.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jon Mason <jon.mason@exar.com>
---
drivers/net/vxge/vxge-main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 537ad87..1ac9b56 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -3439,6 +3439,8 @@ static void vxge_device_unregister(struct __vxge_hw_device *hldev)
strncpy(buf, dev->name, IFNAMSIZ);
+ flush_work_sync(&vdev->reset_task);
+
/* in 2.6 will call stop() if device is up */
unregister_netdev(dev);
^ permalink raw reply related
* Re: |PATCH net-next-2.6] ifb: use netif_receive_skb() instead of netif_rx()
From: Eric Dumazet @ 2010-12-15 14:21 UTC (permalink / raw)
To: hadi
Cc: Changli Gao, David S. Miller, Stephen Hemminger, Tom Herbert,
Jiri Pirko, netdev, netem
In-Reply-To: <1292417363.2067.17.camel@mojatatu>
Le mercredi 15 décembre 2010 à 07:49 -0500, jamal a écrit :
> On Wed, 2010-12-15 at 09:39 +0100, Eric Dumazet wrote:
> > In ri_tasklet(), we run from softirq, so can directly handle packet
> > through netif_receive_skb() instead of netif_rx().
> > There is no risk of recursion.
>
> Eric, did you do at least a simple test on this one?
> It used to be problematic (I cant remember why or
> what use case was problematic).
Yes, I run SFQ / IFB right now on my dev machine, and found SFQ bugs by
the way ;)
^ permalink raw reply
* Re: [PATCH net-next-2.6] vxge: add missing flush of reset_task
From: Jon Mason @ 2010-12-15 14:29 UTC (permalink / raw)
To: Tejun Heo; +Cc: David S. Miller, netdev@vger.kernel.org, lkml
In-Reply-To: <4D08CAB1.6040402@kernel.org>
On Wed, Dec 15, 2010 at 06:03:29AM -0800, Tejun Heo wrote:
> Commit 6e07ebd84 (drivers/net: remove unnecessary
> flush_scheduled_work() calls) incorrectly removed the flush call
> without replacing it with the appropriate work specific operation.
> Fix it by flushing vdev->reset_task explicitly.
>
> Pointed out by Jon Mason.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Jon Mason <jon.mason@exar.com>
Acked-by: Jon Mason <jon.mason@exar.com>
> ---
> drivers/net/vxge/vxge-main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
> index 537ad87..1ac9b56 100644
> --- a/drivers/net/vxge/vxge-main.c
> +++ b/drivers/net/vxge/vxge-main.c
> @@ -3439,6 +3439,8 @@ static void vxge_device_unregister(struct __vxge_hw_device *hldev)
>
> strncpy(buf, dev->name, IFNAMSIZ);
>
> + flush_work_sync(&vdev->reset_task);
> +
> /* in 2.6 will call stop() if device is up */
> unregister_netdev(dev);
>
^ permalink raw reply
* [PATCH net-next-2.6] net: force a fresh timestamp for ingress packets
From: Eric Dumazet @ 2010-12-15 15:50 UTC (permalink / raw)
To: David Miller; +Cc: Changli Gao, Jarek Poplawski, netdev, Patrick McHardy
In commit 8caf153974f2 (net: sch_netem: Fix an inconsistency in ingress
netem timestamps.), Jarek added a logic to refresh timestamps of
ingressed packets going through netem.
I believe we should generalize this, forcing a refresh of timestamps in
dev_queue_xmit_nit() for all ingress packets, whatever qdisc/class they
used before being delivered.
This way, we can have a good idea when packets are delivered to our
stack (tcpdump -i ifb0), while a tcpdump on original device gives
timestamps right before ingressing.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dev.c | 2 +-
net/sched/sch_netem.c | 8 --------
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d28b3a0..a2846f8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1506,7 +1506,7 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
struct packet_type *ptype;
#ifdef CONFIG_NET_CLS_ACT
- if (!(skb->tstamp.tv64 && (G_TC_FROM(skb->tc_verd) & AT_INGRESS)))
+ if (!skb->tstamp.tv64 || (G_TC_FROM(skb->tc_verd) & AT_INGRESS))
net_timestamp_set(skb);
#else
net_timestamp_set(skb);
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index e5593c0..1c29cc0 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -281,14 +281,6 @@ static struct sk_buff *netem_dequeue(struct Qdisc *sch)
if (unlikely(!skb))
return NULL;
-#ifdef CONFIG_NET_CLS_ACT
- /*
- * If it's at ingress let's pretend the delay is
- * from the network (tstamp will be updated).
- */
- if (G_TC_FROM(skb->tc_verd) & AT_INGRESS)
- skb->tstamp.tv64 = 0;
-#endif
pr_debug("netem_dequeue: return skb=%p\n", skb);
sch->q.qlen--;
return skb;
^ permalink raw reply related
* Re: [PATCH 2/3] net: sunrpc: kill unused macros
From: J. Bruce Fields @ 2010-12-15 15:52 UTC (permalink / raw)
To: Shan Wei
Cc: neilb-l3A5Bk7waGM, Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
steved-H+wXaHxf7aLQT0dZR+AlfA, tj-DgEjT+Ai2ygdnm+yROfE0A,
David Miller, linux-nfs-u79uwXL29TY76Z2rM5mHXA, Network-Maillist
In-Reply-To: <4D086478.7090106-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Wed, Dec 15, 2010 at 02:47:20PM +0800, Shan Wei wrote:
> These macros never be used for several years.
Applying for 2.6.38.--b.
>
>
> Signed-off-by: Shan Wei <shanwei-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> ---
> net/sunrpc/auth_gss/svcauth_gss.c | 2 --
> net/sunrpc/svcauth.c | 1 -
> net/sunrpc/svcauth_unix.c | 2 --
> 3 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
> index dec2a6f..bcdae78 100644
> --- a/net/sunrpc/auth_gss/svcauth_gss.c
> +++ b/net/sunrpc/auth_gss/svcauth_gss.c
> @@ -67,7 +67,6 @@ static int netobj_equal(struct xdr_netobj *a, struct xdr_netobj *b)
>
> #define RSI_HASHBITS 6
> #define RSI_HASHMAX (1<<RSI_HASHBITS)
> -#define RSI_HASHMASK (RSI_HASHMAX-1)
>
> struct rsi {
> struct cache_head h;
> @@ -319,7 +318,6 @@ static struct rsi *rsi_update(struct rsi *new, struct rsi *old)
>
> #define RSC_HASHBITS 10
> #define RSC_HASHMAX (1<<RSC_HASHBITS)
> -#define RSC_HASHMASK (RSC_HASHMAX-1)
>
> #define GSS_SEQ_WIN 128
>
> diff --git a/net/sunrpc/svcauth.c b/net/sunrpc/svcauth.c
> index 4e9393c..7963569 100644
> --- a/net/sunrpc/svcauth.c
> +++ b/net/sunrpc/svcauth.c
> @@ -118,7 +118,6 @@ EXPORT_SYMBOL_GPL(svc_auth_unregister);
>
> #define DN_HASHBITS 6
> #define DN_HASHMAX (1<<DN_HASHBITS)
> -#define DN_HASHMASK (DN_HASHMAX-1)
>
> static struct hlist_head auth_domain_table[DN_HASHMAX];
> static spinlock_t auth_domain_lock =
> diff --git a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c
> index 560677d..a04ac91 100644
> --- a/net/sunrpc/svcauth_unix.c
> +++ b/net/sunrpc/svcauth_unix.c
> @@ -85,7 +85,6 @@ static void svcauth_unix_domain_release(struct auth_domain *dom)
> */
> #define IP_HASHBITS 8
> #define IP_HASHMAX (1<<IP_HASHBITS)
> -#define IP_HASHMASK (IP_HASHMAX-1)
>
> struct ip_map {
> struct cache_head h;
> @@ -497,7 +496,6 @@ svcauth_unix_info_release(struct svc_xprt *xpt)
> */
> #define GID_HASHBITS 8
> #define GID_HASHMAX (1<<GID_HASHBITS)
> -#define GID_HASHMASK (GID_HASHMAX - 1)
>
> struct unix_gid {
> struct cache_head h;
> --
> 1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] sctp: fix the return value of getting the sctp partial delivery point
From: Vladislav Yasevich @ 2010-12-15 15:53 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, linux-sctp, netdev@vger.kernel.org
In-Reply-To: <4D0823A1.6080307@cn.fujitsu.com>
On 12/14/2010 09:10 PM, Wei Yongjun wrote:
> Get the sctp partial delivery point using SCTP_PARTIAL_DELIVERY_POINT
> socket option should return 0 if success, not -ENOTSUPP.
>
Ack.
-vlad
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
> net/sctp/socket.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 1bc5203..8628e8e 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -5050,7 +5050,7 @@ static int sctp_getsockopt_partial_delivery_point(struct sock *sk, int len,
> if (copy_to_user(optval, &val, len))
> return -EFAULT;
>
> - return -ENOTSUPP;
> + return 0;
> }
>
> /*
^ permalink raw reply
* pull request: wireless-2.6 2010-12-15
From: John W. Linville @ 2010-12-15 15:56 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
This is a batch of fixes intended for 2.6.37.
The biggest changes fix an issue where the iwlagn driver will misread
the EEPROM information for some devices that will soon be in the wild.
The initial impulse was to rewrite the EEPROM code, but I pushed back on
that for 2.6.37. The compromise is to add the new EEPROM reading code,
but only to invoke it for the new devices. Older devices will still use
the existing (and tested) EEPROM code. Note that all devices will use
the new code in 2.6.38 and beyond.
This also includes a pull of bluetooth fixes from Gustavo Padovan. That
includes a null pointer fix and a fix for a regression that broke the
DUN profile -- say goodbye to your emergency cell-phone Internet
connection without that!
Other patches include some device ID additions for p54usb, a fix to
avoid log spam resulting from suspend/resume with USB-based wireless
devices that don't define their own suspend hook, a null ptr fix for the
libertas driver, and another null pointer fix related to IBSS merges.
Please let me know if there are problems!
John
---
The following changes since commit 2a27a03d3a891e87ca33d27a858b4db734a4cbab:
pppoe.c: Fix kernel panic caused by __pppoe_xmit (2010-12-12 15:06:16 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Christian Lamparter (1):
p54usb: add 5 more USBIDs
Eduardo Costa (1):
p54usb: New USB ID for Gemtek WUBI-100GW
Herton Ronaldo Krzesinski (1):
mac80211: avoid calling ieee80211_work_work unconditionally
Johan Hedberg (1):
Bluetooth: Fix initial RFCOMM DLC security level
Johannes Berg (1):
iwlagn: rename enhanced txpower fields
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-2.6
Jun Nie (1):
Bluetooth: add NULL pointer check in HCI
Sven Neumann (1):
libertas: fix potential NULL-pointer dereference
Tim Harvey (1):
mac80211: Fix NULL-pointer deference on ibss merge when not ready
Wey-Yi Guy (1):
iwlagn: implement layout-agnostic EEPROM reading
drivers/bluetooth/hci_ldisc.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +
drivers/net/wireless/iwlwifi/iwl-6000.c | 12 ++++
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 88 ++++++++++++++++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 6 ++
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 25 ++++++-
drivers/net/wireless/libertas/cfg.c | 2 +-
drivers/net/wireless/p54/p54usb.c | 6 ++
net/bluetooth/rfcomm/core.c | 1 +
net/mac80211/ibss.c | 4 +
net/mac80211/work.c | 5 +-
12 files changed, 148 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 7201482..3c6cabc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -311,8 +311,10 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (test_and_clear_bit(HCI_UART_PROTO_SET, &hu->flags)) {
hu->proto->close(hu);
- hci_unregister_dev(hdev);
- hci_free_dev(hdev);
+ if (hdev) {
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+ }
}
}
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index db54091..0e027f7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -315,6 +315,7 @@ struct iwl_cfg iwl100_bgn_cfg = {
.mod_params = &iwlagn_mod_params,
.base_params = &iwl1000_base_params,
.ht_params = &iwl1000_ht_params,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl100_bg_cfg = {
@@ -330,6 +331,7 @@ struct iwl_cfg iwl100_bg_cfg = {
.ops = &iwl1000_ops,
.mod_params = &iwlagn_mod_params,
.base_params = &iwl1000_base_params,
+ .use_new_eeprom_reading = true,
};
MODULE_FIRMWARE(IWL1000_MODULE_FIRMWARE(IWL1000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 11e6532..0ceeaac 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -561,6 +561,7 @@ struct iwl_cfg iwl6000g2a_2agn_cfg = {
.ht_params = &iwl6000_ht_params,
.need_dc_calib = true,
.need_temp_offset_calib = true,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2a_2abg_cfg = {
@@ -578,6 +579,7 @@ struct iwl_cfg iwl6000g2a_2abg_cfg = {
.base_params = &iwl6000_base_params,
.need_dc_calib = true,
.need_temp_offset_calib = true,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2a_2bg_cfg = {
@@ -595,6 +597,7 @@ struct iwl_cfg iwl6000g2a_2bg_cfg = {
.base_params = &iwl6000_base_params,
.need_dc_calib = true,
.need_temp_offset_calib = true,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2b_2agn_cfg = {
@@ -616,6 +619,7 @@ struct iwl_cfg iwl6000g2b_2agn_cfg = {
.need_temp_offset_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2b_2abg_cfg = {
@@ -636,6 +640,7 @@ struct iwl_cfg iwl6000g2b_2abg_cfg = {
.need_temp_offset_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2b_2bgn_cfg = {
@@ -657,6 +662,7 @@ struct iwl_cfg iwl6000g2b_2bgn_cfg = {
.need_temp_offset_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2b_2bg_cfg = {
@@ -677,6 +683,7 @@ struct iwl_cfg iwl6000g2b_2bg_cfg = {
.need_temp_offset_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2b_bgn_cfg = {
@@ -698,6 +705,7 @@ struct iwl_cfg iwl6000g2b_bgn_cfg = {
.need_temp_offset_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6000g2b_bg_cfg = {
@@ -718,6 +726,7 @@ struct iwl_cfg iwl6000g2b_bg_cfg = {
.need_temp_offset_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
/*
@@ -804,6 +813,7 @@ struct iwl_cfg iwl6050g2_bgn_cfg = {
.base_params = &iwl6050_base_params,
.ht_params = &iwl6000_ht_params,
.need_dc_calib = true,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl6050_2abg_cfg = {
@@ -857,6 +867,7 @@ struct iwl_cfg iwl130_bgn_cfg = {
.need_dc_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
struct iwl_cfg iwl130_bg_cfg = {
@@ -876,6 +887,7 @@ struct iwl_cfg iwl130_bg_cfg = {
.need_dc_calib = true,
/* Due to bluetooth, we transmit 2.4 GHz probes only on antenna A */
.scan_tx_antennas[IEEE80211_BAND_2GHZ] = ANT_A,
+ .use_new_eeprom_reading = true,
};
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index a650bab..9eeeda1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -392,7 +392,7 @@ static s8 iwl_update_channel_txpower(struct iwl_priv *priv,
/**
* iwlcore_eeprom_enhanced_txpower: process enhanced tx power info
*/
-void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
+static void iwlcore_eeprom_enhanced_txpower_old(struct iwl_priv *priv)
{
int eeprom_section_count = 0;
int section, element;
@@ -419,7 +419,8 @@ void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
* always check for valid entry before process
* the information
*/
- if (!enhanced_txpower->common || enhanced_txpower->reserved)
+ if (!(enhanced_txpower->flags || enhanced_txpower->channel) ||
+ enhanced_txpower->delta_20_in_40)
continue;
for (element = 0; element < eeprom_section_count; element++) {
@@ -452,3 +453,86 @@ void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
}
}
}
+
+static void
+iwlcore_eeprom_enh_txp_read_element(struct iwl_priv *priv,
+ struct iwl_eeprom_enhanced_txpwr *txp,
+ s8 max_txpower_avg)
+{
+ int ch_idx;
+ bool is_ht40 = txp->flags & IWL_EEPROM_ENH_TXP_FL_40MHZ;
+ enum ieee80211_band band;
+
+ band = txp->flags & IWL_EEPROM_ENH_TXP_FL_BAND_52G ?
+ IEEE80211_BAND_5GHZ : IEEE80211_BAND_2GHZ;
+
+ for (ch_idx = 0; ch_idx < priv->channel_count; ch_idx++) {
+ struct iwl_channel_info *ch_info = &priv->channel_info[ch_idx];
+
+ /* update matching channel or from common data only */
+ if (txp->channel != 0 && ch_info->channel != txp->channel)
+ continue;
+
+ /* update matching band only */
+ if (band != ch_info->band)
+ continue;
+
+ if (ch_info->max_power_avg < max_txpower_avg && !is_ht40) {
+ ch_info->max_power_avg = max_txpower_avg;
+ ch_info->curr_txpow = max_txpower_avg;
+ ch_info->scan_power = max_txpower_avg;
+ }
+
+ if (is_ht40 && ch_info->ht40_max_power_avg < max_txpower_avg)
+ ch_info->ht40_max_power_avg = max_txpower_avg;
+ }
+}
+
+#define EEPROM_TXP_OFFS (0x00 | INDIRECT_ADDRESS | INDIRECT_TXP_LIMIT)
+#define EEPROM_TXP_ENTRY_LEN sizeof(struct iwl_eeprom_enhanced_txpwr)
+#define EEPROM_TXP_SZ_OFFS (0x00 | INDIRECT_ADDRESS | INDIRECT_TXP_LIMIT_SIZE)
+
+static void iwlcore_eeprom_enhanced_txpower_new(struct iwl_priv *priv)
+{
+ struct iwl_eeprom_enhanced_txpwr *txp_array, *txp;
+ int idx, entries;
+ __le16 *txp_len;
+ s8 max_txp_avg, max_txp_avg_halfdbm;
+
+ BUILD_BUG_ON(sizeof(struct iwl_eeprom_enhanced_txpwr) != 8);
+
+ /* the length is in 16-bit words, but we want entries */
+ txp_len = (__le16 *) iwlagn_eeprom_query_addr(priv, EEPROM_TXP_SZ_OFFS);
+ entries = le16_to_cpup(txp_len) * 2 / EEPROM_TXP_ENTRY_LEN;
+
+ txp_array = (void *) iwlagn_eeprom_query_addr(priv, EEPROM_TXP_OFFS);
+ for (idx = 0; idx < entries; idx++) {
+ txp = &txp_array[idx];
+
+ /* skip invalid entries */
+ if (!(txp->flags & IWL_EEPROM_ENH_TXP_FL_VALID))
+ continue;
+
+ max_txp_avg = iwl_get_max_txpower_avg(priv, txp_array, idx,
+ &max_txp_avg_halfdbm);
+
+ /*
+ * Update the user limit values values to the highest
+ * power supported by any channel
+ */
+ if (max_txp_avg > priv->tx_power_user_lmt)
+ priv->tx_power_user_lmt = max_txp_avg;
+ if (max_txp_avg_halfdbm > priv->tx_power_lmt_in_half_dbm)
+ priv->tx_power_lmt_in_half_dbm = max_txp_avg_halfdbm;
+
+ iwlcore_eeprom_enh_txp_read_element(priv, txp, max_txp_avg);
+ }
+}
+
+void iwlcore_eeprom_enhanced_txpower(struct iwl_priv *priv)
+{
+ if (priv->cfg->use_new_eeprom_reading)
+ iwlcore_eeprom_enhanced_txpower_new(priv);
+ else
+ iwlcore_eeprom_enhanced_txpower_old(priv);
+}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index b555edd..554afb7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -569,6 +569,12 @@ static u32 eeprom_indirect_address(const struct iwl_priv *priv, u32 address)
case INDIRECT_REGULATORY:
offset = iwl_eeprom_query16(priv, EEPROM_LINK_REGULATORY);
break;
+ case INDIRECT_TXP_LIMIT:
+ offset = iwl_eeprom_query16(priv, EEPROM_LINK_TXP_LIMIT);
+ break;
+ case INDIRECT_TXP_LIMIT_SIZE:
+ offset = iwl_eeprom_query16(priv, EEPROM_LINK_TXP_LIMIT_SIZE);
+ break;
case INDIRECT_CALIBRATION:
offset = iwl_eeprom_query16(priv, EEPROM_LINK_CALIBRATION);
break;
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 64527de..954ecc2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -390,6 +390,7 @@ struct iwl_cfg {
const bool need_temp_offset_calib; /* if used set to true */
u8 scan_rx_antennas[IEEE80211_NUM_BANDS];
u8 scan_tx_antennas[IEEE80211_NUM_BANDS];
+ const bool use_new_eeprom_reading; /* temporary, remove later */
};
/***************************
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index d9b5906..e3a279d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -120,6 +120,17 @@ struct iwl_eeprom_channel {
s8 max_power_avg; /* max power (dBm) on this chnl, limit 31 */
} __packed;
+enum iwl_eeprom_enhanced_txpwr_flags {
+ IWL_EEPROM_ENH_TXP_FL_VALID = BIT(0),
+ IWL_EEPROM_ENH_TXP_FL_BAND_52G = BIT(1),
+ IWL_EEPROM_ENH_TXP_FL_OFDM = BIT(2),
+ IWL_EEPROM_ENH_TXP_FL_40MHZ = BIT(3),
+ IWL_EEPROM_ENH_TXP_FL_HT_AP = BIT(4),
+ IWL_EEPROM_ENH_TXP_FL_RES1 = BIT(5),
+ IWL_EEPROM_ENH_TXP_FL_RES2 = BIT(6),
+ IWL_EEPROM_ENH_TXP_FL_COMMON_TYPE = BIT(7),
+};
+
/**
* iwl_eeprom_enhanced_txpwr structure
* This structure presents the enhanced regulatory tx power limit layout
@@ -127,21 +138,23 @@ struct iwl_eeprom_channel {
* Enhanced regulatory tx power portion of eeprom image can be broken down
* into individual structures; each one is 8 bytes in size and contain the
* following information
- * @common: (desc + channel) not used by driver, should _NOT_ be "zero"
+ * @flags: entry flags
+ * @channel: channel number
* @chain_a_max_pwr: chain a max power in 1/2 dBm
* @chain_b_max_pwr: chain b max power in 1/2 dBm
* @chain_c_max_pwr: chain c max power in 1/2 dBm
- * @reserved: not used, should be "zero"
+ * @delta_20_in_40: 20-in-40 deltas (hi/lo)
* @mimo2_max_pwr: mimo2 max power in 1/2 dBm
* @mimo3_max_pwr: mimo3 max power in 1/2 dBm
*
*/
struct iwl_eeprom_enhanced_txpwr {
- __le16 common;
+ u8 flags;
+ u8 channel;
s8 chain_a_max;
s8 chain_b_max;
s8 chain_c_max;
- s8 reserved;
+ u8 delta_20_in_40;
s8 mimo2_max;
s8 mimo3_max;
} __packed;
@@ -186,6 +199,8 @@ struct iwl_eeprom_enhanced_txpwr {
#define EEPROM_LINK_CALIBRATION (2*0x67)
#define EEPROM_LINK_PROCESS_ADJST (2*0x68)
#define EEPROM_LINK_OTHERS (2*0x69)
+#define EEPROM_LINK_TXP_LIMIT (2*0x6a)
+#define EEPROM_LINK_TXP_LIMIT_SIZE (2*0x6b)
/* agn regulatory - indirect access */
#define EEPROM_REG_BAND_1_CHANNELS ((0x08)\
@@ -389,6 +404,8 @@ struct iwl_eeprom_calib_info {
#define INDIRECT_CALIBRATION 0x00040000
#define INDIRECT_PROCESS_ADJST 0x00050000
#define INDIRECT_OTHERS 0x00060000
+#define INDIRECT_TXP_LIMIT 0x00070000
+#define INDIRECT_TXP_LIMIT_SIZE 0x00080000
#define INDIRECT_ADDRESS 0x00100000
/* General */
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 373930a..113f4f2 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -619,7 +619,7 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned long dummy,
print_ssid(ssid_buf, ssid, ssid_len),
LBS_SCAN_RSSI_TO_MBM(rssi)/100);
- if (channel ||
+ if (channel &&
!(channel->flags & IEEE80211_CHAN_DISABLED))
cfg80211_inform_bss(wiphy, channel,
bssid, le64_to_cpu(*(__le64 *)tsfdesc),
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index d5bc21e..2325e56 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -43,6 +43,7 @@ MODULE_FIRMWARE("isl3887usb");
static struct usb_device_id p54u_table[] __devinitdata = {
/* Version 1 devices (pci chip + net2280) */
+ {USB_DEVICE(0x0411, 0x0050)}, /* Buffalo WLI2-USB2-G54 */
{USB_DEVICE(0x045e, 0x00c2)}, /* Microsoft MN-710 */
{USB_DEVICE(0x0506, 0x0a11)}, /* 3COM 3CRWE254G72 */
{USB_DEVICE(0x06b9, 0x0120)}, /* Thomson SpeedTouch 120g */
@@ -56,9 +57,13 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x0846, 0x4220)}, /* Netgear WG111 */
{USB_DEVICE(0x09aa, 0x1000)}, /* Spinnaker Proto board */
{USB_DEVICE(0x0cde, 0x0006)}, /* Medion 40900, Roper Europe */
+ {USB_DEVICE(0x0db0, 0x6826)}, /* MSI UB54G (MS-6826) */
{USB_DEVICE(0x107b, 0x55f2)}, /* Gateway WGU-210 (Gemtek) */
{USB_DEVICE(0x124a, 0x4023)}, /* Shuttle PN15, Airvast WM168g, IOGear GWU513 */
+ {USB_DEVICE(0x1435, 0x0210)}, /* Inventel UR054G */
+ {USB_DEVICE(0x15a9, 0x0002)}, /* Gemtek WUBI-100GW 802.11g */
{USB_DEVICE(0x1630, 0x0005)}, /* 2Wire 802.11g USB (v1) / Z-Com */
+ {USB_DEVICE(0x182d, 0x096b)}, /* Sitecom WL-107 */
{USB_DEVICE(0x1915, 0x2234)}, /* Linksys WUSB54G OEM */
{USB_DEVICE(0x1915, 0x2235)}, /* Linksys WUSB54G Portable OEM */
{USB_DEVICE(0x2001, 0x3701)}, /* DLink DWL-G120 Spinnaker */
@@ -94,6 +99,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x1435, 0x0427)}, /* Inventel UR054G */
{USB_DEVICE(0x1668, 0x1050)}, /* Actiontec 802UIG-1 */
{USB_DEVICE(0x2001, 0x3704)}, /* DLink DWL-G122 rev A2 */
+ {USB_DEVICE(0x2001, 0x3705)}, /* D-Link DWL-G120 rev C1 */
{USB_DEVICE(0x413c, 0x5513)}, /* Dell WLA3310 USB Wireless Adapter */
{USB_DEVICE(0x413c, 0x8102)}, /* Spinnaker DUT */
{USB_DEVICE(0x413c, 0x8104)}, /* Cohiba Proto board */
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index fa642aa..432a9a6 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -311,6 +311,7 @@ static void rfcomm_dlc_clear_state(struct rfcomm_dlc *d)
d->state = BT_OPEN;
d->flags = 0;
d->mscex = 0;
+ d->sec_level = BT_SECURITY_LOW;
d->mtu = RFCOMM_DEFAULT_MTU;
d->v24_sig = RFCOMM_V24_RTC | RFCOMM_V24_RTR | RFCOMM_V24_DV;
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 239c483..077a93d 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -780,6 +780,9 @@ void ieee80211_ibss_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
mutex_lock(&sdata->u.ibss.mtx);
+ if (!sdata->u.ibss.ssid_len)
+ goto mgmt_out; /* not ready to merge yet */
+
switch (fc & IEEE80211_FCTL_STYPE) {
case IEEE80211_STYPE_PROBE_REQ:
ieee80211_rx_mgmt_probe_req(sdata, mgmt, skb->len);
@@ -797,6 +800,7 @@ void ieee80211_ibss_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
break;
}
+ mgmt_out:
mutex_unlock(&sdata->u.ibss.mtx);
}
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index ae344d1..146097c 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -1051,11 +1051,13 @@ void ieee80211_work_purge(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct ieee80211_work *wk;
+ bool cleanup = false;
mutex_lock(&local->mtx);
list_for_each_entry(wk, &local->work_list, list) {
if (wk->sdata != sdata)
continue;
+ cleanup = true;
wk->type = IEEE80211_WORK_ABORT;
wk->started = true;
wk->timeout = jiffies;
@@ -1063,7 +1065,8 @@ void ieee80211_work_purge(struct ieee80211_sub_if_data *sdata)
mutex_unlock(&local->mtx);
/* run cleanups etc. */
- ieee80211_work_work(&local->work_work);
+ if (cleanup)
+ ieee80211_work_work(&local->work_work);
mutex_lock(&local->mtx);
list_for_each_entry(wk, &local->work_list, list) {
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH] net_sched: sch_sfq: fix allot handling
From: Patrick McHardy @ 2010-12-15 16:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Jarek Poplawski
In-Reply-To: <1292421783.3427.232.camel@edumazet-laptop>
On 15.12.2010 15:03, Eric Dumazet wrote:
> When deploying SFQ/IFB here at work, I found the allot management was
> pretty wrong in sfq, even changing allot from short to int...
>
> We should init allot for each new flow turn, not using a previous value,
> or else small packets can easily make allot overflow.
>
> Before patch, I saw burst of several packets per flow, apparently
> denying the "allot 1514" limit I had on my SFQ class.
>
> class sfq 11:1 parent 11:
> (dropped 0, overlimits 0 requeues 0)
> backlog 0b 7p requeues 0
> allot 11546
>
> class sfq 11:46 parent 11:
> (dropped 0, overlimits 0 requeues 0)
> backlog 0b 1p requeues 0
> allot -23873
>
> class sfq 11:78 parent 11:
> (dropped 0, overlimits 0 requeues 0)
> backlog 0b 5p requeues 0
> allot 11393
These values definitely look wrong.
> diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> index 3cf478d..8c8a190 100644
> --- a/net/sched/sch_sfq.c
> +++ b/net/sched/sch_sfq.c
> @@ -270,7 +270,7 @@ static unsigned int sfq_drop(struct Qdisc *sch)
> /* It is difficult to believe, but ALL THE SLOTS HAVE LENGTH 1. */
> d = q->next[q->tail];
> q->next[q->tail] = q->next[d];
> - q->allot[q->next[d]] += q->quantum;
> + q->allot[q->next[d]] = q->quantum;
> skb = q->qs[d].prev;
> len = qdisc_pkt_len(skb);
> __skb_unlink(skb, &q->qs[d]);
I'm not sure about this part, but lets ignore that for now since it
shouldn't affect your testcase unless you're using CBQ.
> @@ -321,14 +321,13 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> sfq_inc(q, x);
> if (q->qs[x].qlen == 1) { /* The flow is new */
> if (q->tail == SFQ_DEPTH) { /* It is the first flow */
> - q->tail = x;
> q->next[x] = x;
> - q->allot[x] = q->quantum;
> } else {
> q->next[x] = q->next[q->tail];
> q->next[q->tail] = x;
> - q->tail = x;
> }
> + q->tail = x;
> + q->allot[x] = q->quantum;
> }
This looks correct, for new flows allot should be initialized from
scratch.
> if (++sch->q.qlen <= q->limit) {
> sch->bstats.bytes += qdisc_pkt_len(skb);
> @@ -382,11 +381,11 @@ sfq_dequeue(struct Qdisc *sch)
> return skb;
> }
> q->next[q->tail] = a;
> - q->allot[a] += q->quantum;
> + q->allot[a] = q->quantum;
The allot initialization doesn't seem necessary anymore at all
now that you're reinitalizing allot for flows that became active
unconditionally in sfq_enqueue().
> } else if ((q->allot[a] -= qdisc_pkt_len(skb)) <= 0) {
> q->tail = a;
> a = q->next[a];
> - q->allot[a] += q->quantum;
> + q->allot[a] = q->quantum;
This seems to break long-term fairness for active flows by not
accounting for overshooting the allotment in the next round
anymore.
I think either the change in sfq_enqueue() or the first change
in sfq_dequeue() should be enough to fix the problem you're seeing.
Basically what needs to be done is initialize allot once from
scratch when the flow becomes active, then add one quantum per
round while it stays active.
^ permalink raw reply
* Re: |PATCH net-next-2.6] ifb: use netif_receive_skb() instead of netif_rx()
From: Stephen Hemminger @ 2010-12-15 16:14 UTC (permalink / raw)
To: hadi
Cc: Eric Dumazet, Changli Gao, David S. Miller, Tom Herbert,
Jiri Pirko, netdev, netem
In-Reply-To: <1292417363.2067.17.camel@mojatatu>
On Wed, 15 Dec 2010 07:49:23 -0500
jamal <hadi@cyberus.ca> wrote:
> On Wed, 2010-12-15 at 09:39 +0100, Eric Dumazet wrote:
> > In ri_tasklet(), we run from softirq, so can directly handle packet
> > through netif_receive_skb() instead of netif_rx().
> > There is no risk of recursion.
>
> Eric, did you do at least a simple test on this one?
> It used to be problematic (I cant remember why or
> what use case was problematic).
Only risk is stack overflow.
^ permalink raw reply
* Re: [PATCH 5/5 v2] net: add old_queue_mapping into skb->cb
From: Stephen Hemminger @ 2010-12-15 16:19 UTC (permalink / raw)
To: Changli Gao
Cc: Jamal Hadi Salim, David S. Miller, Eric Dumazet, Tom Herbert,
Jiri Pirko, netdev, netem
In-Reply-To: <1292390636-3156-1-git-send-email-xiaosuo@gmail.com>
On Wed, 15 Dec 2010 13:23:56 +0800
Changli Gao <xiaosuo@gmail.com> wrote:
> For the skbs returned from ifb, we should use the queue_mapping
> saved before ifb.
>
> We save old queue_mapping in old_queue_mapping just before calling
> dev_queue_xmit, and restore the old_queue_mapping to queue_mapping
> just before reinjecting the skb.
>
> dev_pick_tx() use the current queue_mapping for the skbs reinjected
> by ifb.
>
> A new struct dev_skb_cb is added, and valid in qdisc and gso layer.
> The original qdisc_skb_cb and DEV_GSO_CB are placed after dev_skb_cb.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
What about a more general mechanism that lets a layer push
some amount of data onto the skb and then pop it off.
Kind of link notes to self, maybe even encode them as netlink
(except netlink messages have excess padding).
This would allow nesting, and avoid cb[] clobbering.
The existing usage of cb[] is only because there wasn't a better
solution.
--
^ 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