* [RFC] SFQ planned changes
From: Eric Dumazet @ 2012-01-03 10:40 UTC (permalink / raw)
To: Dave Taht; +Cc: Michal Kubeček, netdev, John A. Sullivan III
In-Reply-To: <CAA93jw5NYChp+hKWjOWiw7SnGhNe+REofr2KM-85GnKNVpkw6w@mail.gmail.com>
Le mardi 03 janvier 2012 à 10:36 +0100, Dave Taht a écrit :
> I note that (as of yesterday) sfq is performing as well as qfq did
> under most workloads, and is considerably simpler than qfq, but
> what I have in mind for shaping in a asymmetric scenario
> *may* involve 'weighting' - rather than strictly prioritizing -
> small acks... and it may not - I'd like to be able to benchmark
> the various AQM approaches against a variety of workloads
> before declaring victory.
A QFQ setup with more than 1024 classes/qdisc is way too slow at init
time, and consume ~384 bytes per class : ~12582912 bytes for 32768
classes.
We also are limited to 65536 qdisc per device, so QFQ setup using hash
is limited to a 32768 divisor.
Now SFQ as implemented in Linux is very limited, with at most 127 flows
and limit of 127 packets. [ So if 127 flows are active, we have one
packet per flow ]
I plan to add to SFQ following features :
- Ability to specify a per flow limit
Its what is called the 'depth',
currently hardcoded to min(127, limit)
- Ability to have up to 65535 flows (instead of 127)
- Ability to have a head drop (to drop old packets from a flow)
example of use : No more than 20 packets per flow, max 8000 flows, max
20000 packets in SFQ qdisc, hash table of 65536 slots.
tc qdisc add ... sfq \
flows 8000 \
depth 20 \
headdrop \
limit 20000 divisor 65536
Ram usage : 32 bytes per flow, instead of 384 for QFQ, so much better
cache hit ratio. 2 bytes per hash table slots, instead of 8 for QFQ.
(perturb timer for a huge SFQ setup would be not recommended)
^ permalink raw reply
* Re: [PATCH net-next v2] net_sched: qdisc_alloc_handle() can be too slow
From: Dave Taht @ 2012-01-03 10:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1325584811.2320.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, Jan 3, 2012 at 11:00 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> When trying to allocate ~32768 qdiscs using autohandle mechanism, we can
> fill the space managed by kernel (handles in [8000-FFFF]:0000 range)
>
> But O(N^2) qdisc_alloc_handle() loops 0x10000 times instead of 0x8000
>
> time tc add qdisc add dev eth0 parent 10:7fff pfifo limit 10
> RTNETLINK answers: Cannot allocate memory
> real 1m54.826s
> user 0m0.000s
> sys 0m0.004s
>
> INFO: rcu_sched_state detected stall on CPU 0 (t=60000 jiffies)
>
> Half number of loops, and add a cond_resched() call.
> We hold rtnl at this point.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Dave Taht <dave.taht@gmail.com>
> ---
> v2: With the patch itself :)
>
> Next move is using rb-tree instead of a linked list, to speedup
> qdisc_lookup(). A complex qdisc setup is way too slow.
>
> net/sched/sch_api.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index dca6c1a..3d8981f 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -618,20 +618,24 @@ void qdisc_class_hash_remove(struct Qdisc_class_hash *clhash,
> }
> EXPORT_SYMBOL(qdisc_class_hash_remove);
>
> -/* Allocate an unique handle from space managed by kernel */
> -
> +/* Allocate an unique handle from space managed by kernel
> + * Possible range is [8000-FFFF]:0000 (0x8000 values)
> + */
> static u32 qdisc_alloc_handle(struct net_device *dev)
> {
> - int i = 0x10000;
> + int i = 0x8000;
> static u32 autohandle = TC_H_MAKE(0x80000000U, 0);
>
> do {
> autohandle += TC_H_MAKE(0x10000U, 0);
> if (autohandle == TC_H_MAKE(TC_H_ROOT, 0))
> autohandle = TC_H_MAKE(0x80000000U, 0);
> - } while (qdisc_lookup(dev, autohandle) && --i > 0);
> + if (!qdisc_lookup(dev, autohandle))
> + return autohandle;
> + cond_resched();
> + } while (--i > 0);
>
> - return i > 0 ? autohandle : 0;
> + return 0;
> }
>
> void qdisc_tree_decrease_qlen(struct Qdisc *sch, unsigned int n)
>
>
I take it this is from you trying to allocate XXk bins in staqfq.lua
and watching it
go boom? I'll gladly go and try to break more stuff if you like. :)
I ran yesterday's patches for sfq, and qfq on net-next all night on an x86 box,
successfully, on e1000e to ag71xx.
I'm not willing to declare victory on QFQ yet, it was a really
hard problem to trigger... give me a day on it...
I'm testing the backport of those two patches to 3.1.6
(no porting needed, they just apply) on cerowrt now, then I'm going to setup
a fairly complex scenario (wireless,wired, 7-8 machines) in bloatlab #2
The wireless data I got a couple days back is rather noisy but the
median is promising.
http://www.teklibre.com/~d/bloat/wireless.qfqvspfifofast10iperfs.png
I'll get a lot more over the next few days and smooth it out.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* RE: [PATCH net-next] igb: Add support for byte queue limits.
From: Jeff Kirsher @ 2012-01-03 10:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Wyborny, Carolyn, David Miller, netdev@vger.kernel.org,
Duyck, Alexander H
In-Reply-To: <1325570866.2874.10.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]
On Tue, 2012-01-03 at 07:07 +0100, Eric Dumazet wrote:
> Le mercredi 21 décembre 2011 à 21:17 +0000, Wyborny, Carolyn a écrit :
> >
> > >-----Original Message-----
> > >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> > >On Behalf Of David Miller
> > >Sent: Wednesday, December 21, 2011 11:42 AM
> > >To: eric.dumazet@gmail.com
> > >Cc: netdev@vger.kernel.org; Kirsher, Jeffrey T; Duyck, Alexander H
> > >Subject: Re: [PATCH net-next] igb: Add support for byte queue limits.
> > >
> > >From: Eric Dumazet <eric.dumazet@gmail.com>
> > >Date: Wed, 21 Dec 2011 16:18:15 +0100
> > >
> > >> This adds support for byte queue limits (BQL)
> > >>
> > >> Since this driver collects bytes count in 'bytecount' field, use it
> > >also
> > >> in igb_tx_map()
> > >>
> > >> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > >> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > >> CC: Alexander Duyck <alexander.h.duyck@intel.com>
> > >
> > >Intel folks, you got this?
> > >--
> > >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
> >
> > Yes, although many are out for the holidays.
> >
> > ACK. We'll get it into our queue for testing.
>
> Any news on this patch ?
>
> I would like it being added for next merge window.
>
> By the way I did test it on my machine.
>
> Thanks
>
Yes, it passed testing, so I will push it in my next series of patches.
Just waiting on the current series to be accepted before I push it.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH net-next v2] net_sched: qdisc_alloc_handle() can be too slow
From: Eric Dumazet @ 2012-01-03 10:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dave Taht
In-Reply-To: <1325584697.2320.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
When trying to allocate ~32768 qdiscs using autohandle mechanism, we can
fill the space managed by kernel (handles in [8000-FFFF]:0000 range)
But O(N^2) qdisc_alloc_handle() loops 0x10000 times instead of 0x8000
time tc add qdisc add dev eth0 parent 10:7fff pfifo limit 10
RTNETLINK answers: Cannot allocate memory
real 1m54.826s
user 0m0.000s
sys 0m0.004s
INFO: rcu_sched_state detected stall on CPU 0 (t=60000 jiffies)
Half number of loops, and add a cond_resched() call.
We hold rtnl at this point.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Dave Taht <dave.taht@gmail.com>
---
v2: With the patch itself :)
Next move is using rb-tree instead of a linked list, to speedup
qdisc_lookup(). A complex qdisc setup is way too slow.
net/sched/sch_api.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index dca6c1a..3d8981f 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -618,20 +618,24 @@ void qdisc_class_hash_remove(struct Qdisc_class_hash *clhash,
}
EXPORT_SYMBOL(qdisc_class_hash_remove);
-/* Allocate an unique handle from space managed by kernel */
-
+/* Allocate an unique handle from space managed by kernel
+ * Possible range is [8000-FFFF]:0000 (0x8000 values)
+ */
static u32 qdisc_alloc_handle(struct net_device *dev)
{
- int i = 0x10000;
+ int i = 0x8000;
static u32 autohandle = TC_H_MAKE(0x80000000U, 0);
do {
autohandle += TC_H_MAKE(0x10000U, 0);
if (autohandle == TC_H_MAKE(TC_H_ROOT, 0))
autohandle = TC_H_MAKE(0x80000000U, 0);
- } while (qdisc_lookup(dev, autohandle) && --i > 0);
+ if (!qdisc_lookup(dev, autohandle))
+ return autohandle;
+ cond_resched();
+ } while (--i > 0);
- return i > 0 ? autohandle : 0;
+ return 0;
}
void qdisc_tree_decrease_qlen(struct Qdisc *sch, unsigned int n)
^ permalink raw reply related
* [PATCH net-next] net_sched: qdisc_alloc_handle() can be too slow
From: Eric Dumazet @ 2012-01-03 9:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dave Taht
When trying to allocate ~32768 qdiscs using autohandle mechanism, we can
fill the space managed by kernel (handles in [8000-FFFF]:0000 range)
But O(N^2) qdisc_alloc_handle() loops 0x10000 times instead of 0x8000
time tc add qdisc add dev eth0 parent 10:7fff pfifo limit 10
RTNETLINK answers: Cannot allocate memory
real 1m54.826s
user 0m0.000s
sys 0m0.004s
INFO: rcu_sched_state detected stall on CPU 0 (t=60000 jiffies)
Half number of loops, and add a cond_resched() call.
We hold rtnl at this point.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Dave Taht <dave.taht@gmail.com>
---
Next move is using rb-tree instead of a linked list, to speedup
qdisc_lookup(). A complex qdisc setup is way too slow.
net/sched/sch_api.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
^ permalink raw reply
* RE: [PATCH 0/4] skb paged fragment destructors
From: David Laight @ 2012-01-03 9:36 UTC (permalink / raw)
To: Ian Campbell, David Miller; +Cc: eric.dumazet, jesse.brandeburg, netdev
In-Reply-To: <1324632922.7877.103.camel@zakaz.uk.xensource.com>
> -#if (65536/PAGE_SIZE + 2) < 16
> +#if (65536/PAGE_SIZE + 1) < 16
> #define MAX_SKB_FRAGS 16UL
> #else
> -#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)
> +#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1)
> #endif
Wouldn't it be better to only have the expression once?
Either using a MAX() define or maybe:
#define MAX_SKB_FRAGS (65536UL/PAGE_SIZE + 1)
#if MAX_SKB_FRAGS < 16UL
#undef MAX_SKB_FRAGS
#define MAX_SKB_FRAGS 16UL
#endif
Although that replicates the 16 instead :-(
David
^ permalink raw reply
* Re: tc filter mask for ACK packets off?
From: Dave Taht @ 2012-01-03 9:36 UTC (permalink / raw)
To: Michal Kubeček; +Cc: netdev, John A. Sullivan III
In-Reply-To: <21734335.uCtjXOcSpA@alaris>
On Tue, Jan 3, 2012 at 8:31 AM, Michal Kubeček <mkubecek@suse.cz> wrote:
> On Saturday 31 of December 2011 21:30EN, John A. Sullivan III wrote:
>> Hello, all. I've been noticing that virtually all the documentation
>> says we should prioritize ACK only packets and that they can be
>> identified with match u8 0x10 0xff. However, isn't the actual flag
Most of that invalid documentation was derived from the original
'wondershaper' effort, and became 'canon', elsewhere.
I'm hoping that we get a chance to correct the documentation
on the new wiki and remove the old, incorrect info from the web...
wshaper's (2001) assumptions were gradually invalidated over the
years. It was a suitable shaper for a 200k-800k download link
at the time, when web sites were 70k in size, and people still
used things like ssh heavily, men were men, and javascript
scarce....
Good follow on work was the esfq and adsl-shaper efforts,
but these publications have also been obsoleted by events.
ESFQ's core features got incorporated in sfq, and adsl-shaper
sort of made it in, genericaly.
The stories of those two shaping efforts are useful bits of history
worth reading about, to gain context about the problems they
were trying to solve.
>> field only 6 bits longs and the first two belong to a previous 6 bit
>> reserved field?
>i
> It's even worse, those two bits are in fact used for ECN (RFC 3168).
I had submitted a patch to openwrt to fix this issue with wondershaper
a while back. I don't know if it got taken up or not...
and either way, wshaper's approach doesn't work well on
modern bandwidths. The core idea (prioritizing small acks
somewhat) retains some value, but the implementation is
unworkable.
>> If that is true, if ever those bits are set, our filters will
>> unnecessarily break. Shouldn't it be match u8 0x10 0x3f?
>
> I think so.
Yes, the old-style, 'canonical', filters break ECN, and have
been breaking it everywhere for a decade.
Also: most, TCP's timestamp so the ack size is larger.
And alas... none of the shapers mentioned above do ipv6 properly.
There are innumerable other limitations... notably prioritizing
dns, syn, synack also can help. They are unable to detect or
prioritize voip packets (sip or skype), either.
> However, by a "ACK only" packet (worth prioritizing), I would rather
> understand a packet with ACK flag without any payload, not a packet with
> ACK as the only flag. For many TCP connections, all packets except
> initial SYN and SYN-ACK and two FIN packets have ACK as the only flag.
> So my guess is you should rather prioritize all TCP packets with no
> application layer data.
No. :)
I'd go into more detail, but after what I hope are the final two
fixes to sfq and qfq land in the net-next kernel (after some more
testing), I like to think I have a more valid approach than this
in the works, but that too will require some more development
and testing.
http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_linear.png
If you are interested in seeing that work in progress
git clone git://github.com/dtaht/deBloat.git
see the src/staqfq.lua script for a start at a general purpose new
age shaper...
and src/qmodels/*4mbit* for some prototypes of a 'soft bandwidth'
one.
(regrettably net-next + some patches is required at present)
I note that (as of yesterday) sfq is performing as well as qfq did
under most workloads, and is considerably simpler than qfq, but
what I have in mind for shaping in a asymmetric scenario
*may* involve 'weighting' - rather than strictly prioritizing -
small acks... and it may not - I'd like to be able to benchmark
the various AQM approaches against a variety of workloads
before declaring victory. Could use some help with all that....
>
> Michal Kubecek
>
>
> --
> 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
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Eric Dumazet @ 2012-01-03 8:06 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: netdev
In-Reply-To: <CAL8zT=htsVAJotATQ5Lqidea5dEqCkZOgTT6t4-fFjjDzcVviw@mail.gmail.com>
Le mardi 03 janvier 2012 à 08:36 +0100, Jean-Michel Hautbois a écrit :
> After looking to the results, I can't see really bad values or
> anything which would explain such a behaviour...
no tcp problems, so your board seems to be slow
> Maybe is there some limits in the driver ? My board is a leopardboard (dm368).
> Any idea ?
Just to have any idea of the inter frame timings, could you post the
~200 first frames taken on x86 ?
tcpdump -p -n -s 0 -i eth0 host arm_ip -c 200
^ permalink raw reply
* Re: [BUG] SIOCSIFFLAGS returns -EIO on SMSC LAN911x
From: Javier Martinez Canillas @ 2012-01-03 7:44 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Enric Balletbo i Serra
In-Reply-To: <1325533505.13595.246.camel@deadeye>
On Mon, Jan 2, 2012 at 8:45 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2012-01-02 at 19:37 +0100, Javier Martinez Canillas wrote:
> [...]
>> Thanks for your help.
>>
>> Finally, what I did was to bring to operational mode the integrated
>> PHY chip by disabling the energy detect power-down mode before doing a
>> software reset and re-enabling after it.
>>
>> Does that solution make sense to you? I've sent the patch-set to the
>> list for review. The patch-set is composed of the following patches:
> [...]
>
> I think that if the data sheet says the power-down bit is reserved on
> the 9221i then it is better not to set it at all. However, given that
> you actually have hardware to test on, you are in a better position to
> say what actually works.
>
> Ben.
>
Hello Ben,
I didn't find on the LAN9221/LAN9221i data-sheet where it says that
this bit 0x17.13 is reserved.
In fact if you look at Section 5.5 "PHY Registers" (page 117) you will
see that the PHY register 0x17 "Mode Control/Status Register" (page
122) is a valid PHY register address and can be used to enable and
disable the Energy Detect Power-Down mode by writing to the bit-field
13 (EDPWRDOWN). Also a functional description of this behavior is
explanied in Section "3.10.3.2 Energy Detect Power-Down" (page 47).
Since in drivers/net/phy/smsc.c the phy is initialized with:
#define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
#define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */
static int smsc_phy_config_init(struct phy_device *phydev)
{
int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
if (rc < 0)
return rc;
/* Enable energy detect mode for this SMSC Transceivers */
rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
rc | MII_LAN83C185_EDPWRDOWN);
if (rc < 0)
return rc;
return smsc_phy_ack_interrupt (phydev);
}
I think that the enabling of the Energy Detect Power-Down mode is correct.
On section 5.3.9 "HW_CFG—Hardware Configuration Register" it says that:
"Soft Reset Timeout (SRST_TO). If a software reset is attempted when
the PHY is not in the operational state (RX_CLK and TX_CLK running),
the reset will not
complete and the soft reset operation will timeout and this bit will
be set to a ‘1’."
Is exactly the behavior we have when the PHY is in low power mode
because the energy detect power-down mode is enabled and no energy is
detected.
That's why I thought to use the bit-field EDPWRDOWN to disable the
energy detect power-down mode before making the software reset. This
brings the PHY to operational mode so the software reset never fails.
After the software reset was successful we can re-enable the energy
detect power-down mode to take advantage of the automatic energy
detection supported by the device.
I have tested on the hardware and seems to work properly, but I don't
know if is the best approach.
Best regards,
--
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
^ permalink raw reply
* Re: TCP communication for raw image transmission
From: Jean-Michel Hautbois @ 2012-01-03 7:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <CAL8zT=h=mDNiDRVDo=jjcCjkyRGZ79iQiQLT3ZVRLb2PuC2ugg@mail.gmail.com>
2012/1/2 Jean-Michel Hautbois <jhautbois@gmail.com>:
> 2012/1/2 Jean-Michel Hautbois <jhautbois@gmail.com>:
>> 2012/1/2 Eric Dumazet <eric.dumazet@gmail.com>:
>>> Le lundi 02 janvier 2012 à 18:20 +0100, Jean-Michel Hautbois a écrit :
>>>
>>>> Here we go...
>>>>
>>>> Recv Send Send
>>>> Socket Socket Message Elapsed
>>>> Size Size Size Time Throughput
>>>> bytes bytes bytes secs. 10^6bits/sec
>>>>
>>>> 87380 16384 16384 60.01 21.79
>>>>
>>>> It is not very good, AFAIK.
>>>> CPU usage is between 17 and 35%.
>>>
>>> Ouch...
>>>
>>> Better find out what is happening before even starting coding
>>> anything...
>>>
>>> checkout "netstat -s" on both sender/receiver
>>
After looking to the results, I can't see really bad values or
anything which would explain such a behaviour...
Maybe is there some limits in the driver ? My board is a leopardboard (dm368).
Any idea ?
JM
^ permalink raw reply
* Re: tc filter mask for ACK packets off?
From: Michal Kubeček @ 2012-01-03 7:31 UTC (permalink / raw)
To: netdev; +Cc: John A. Sullivan III
In-Reply-To: <1325385056.4174.51.camel@denise.theartistscloset.com>
On Saturday 31 of December 2011 21:30EN, John A. Sullivan III wrote:
> Hello, all. I've been noticing that virtually all the documentation
> says we should prioritize ACK only packets and that they can be
> identified with match u8 0x10 0xff. However, isn't the actual flag
> field only 6 bits longs and the first two belong to a previous 6 bit
> reserved field?
It's even worse, those two bits are in fact used for ECN (RFC 3168).
> If that is true, if ever those bits are set, our filters will
> unnecessarily break. Shouldn't it be match u8 0x10 0x3f?
I think so.
However, by a "ACK only" packet (worth prioritizing), I would rather
understand a packet with ACK flag without any payload, not a packet with
ACK as the only flag. For many TCP connections, all packets except
initial SYN and SYN-ACK and two FIN packets have ACK as the only flag.
So my guess is you should rather prioritize all TCP packets with no
application layer data.
Michal Kubecek
^ permalink raw reply
* RE: [PATCH net-next] igb: Add support for byte queue limits.
From: Eric Dumazet @ 2012-01-03 6:07 UTC (permalink / raw)
To: Wyborny, Carolyn
Cc: David Miller, netdev@vger.kernel.org, Kirsher, Jeffrey T,
Duyck, Alexander H
In-Reply-To: <9BBC4E0CF881AA4299206E2E1412B626011AB6@ORSMSX102.amr.corp.intel.com>
Le mercredi 21 décembre 2011 à 21:17 +0000, Wyborny, Carolyn a écrit :
>
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> >On Behalf Of David Miller
> >Sent: Wednesday, December 21, 2011 11:42 AM
> >To: eric.dumazet@gmail.com
> >Cc: netdev@vger.kernel.org; Kirsher, Jeffrey T; Duyck, Alexander H
> >Subject: Re: [PATCH net-next] igb: Add support for byte queue limits.
> >
> >From: Eric Dumazet <eric.dumazet@gmail.com>
> >Date: Wed, 21 Dec 2011 16:18:15 +0100
> >
> >> This adds support for byte queue limits (BQL)
> >>
> >> Since this driver collects bytes count in 'bytecount' field, use it
> >also
> >> in igb_tx_map()
> >>
> >> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> >> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >> CC: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> >Intel folks, you got this?
> >--
> >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
>
> Yes, although many are out for the holidays.
>
> ACK. We'll get it into our queue for testing.
Any news on this patch ?
I would like it being added for next merge window.
By the way I did test it on my machine.
Thanks
^ permalink raw reply
* Re: [PATCH 01/11] SYSCTL: export root and set handling routines
From: Eric W. Biederman @ 2012-01-03 3:49 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, James Bottomley,
bfields@fieldses.org, davem@davemloft.net, devel@openvz.org
In-Reply-To: <4EEF7364.8000407-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
> 19.12.2011 20:37, Eric W. Biederman пишет:
>> Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
>>
>> Doing that independently of the rest of the sysctls is pretty horrible
>> and confusing to users. What I am planning might suit your needs and
>> if not we need to talk some more about how to get the vfs to do
>> something reasonable.
>>
>
> Ok, Eric. Would be glad to discuss your sysctls plans.
> But actually you already know my needs: I would like to make sysctls work in the
> way like sysfs does: i.e. content of files depends on mount maker -
> not viewer.
What drives the desire to have sysctls depend on the mount maker?
Especially what drives that desire not to have it have a /proc/<pid>/sys
directory that reflects the sysctls for a given process.
Eric
--
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
* [net-next 7/7] ixgbe: add support for new 82599 device.
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
This device uses an already existing DevID but since it supports
WoL we need to add the Sub DevID. It's support of WoL is limited
to the first port.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 15 ++++++++++++---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++++++++--
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 91f871b..da7e580 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1955,12 +1955,21 @@ static int ixgbe_wol_exclusion(struct ixgbe_adapter *adapter,
/* WOL not supported except for the following */
switch(hw->device_id) {
case IXGBE_DEV_ID_82599_SFP:
- /* Only this subdevice supports WOL */
- if (hw->subsystem_device_id != IXGBE_SUBDEV_ID_82599_SFP) {
+ /* Only these subdevices could supports WOL */
+ switch (hw->subsystem_device_id) {
+ case IXGBE_SUBDEV_ID_82599_560FLR:
+ /* only support first port */
+ if (hw->bus.func != 0) {
+ wol->supported = 0;
+ break;
+ }
+ case IXGBE_SUBDEV_ID_82599_SFP:
+ retval = 0;
+ break;
+ default:
wol->supported = 0;
break;
}
- retval = 0;
break;
case IXGBE_DEV_ID_82599_COMBO_BACKPLANE:
/* All except this subdevice support WOL */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index e27e4d1..74669a8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7605,9 +7605,16 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
adapter->wol = 0;
switch (pdev->device) {
case IXGBE_DEV_ID_82599_SFP:
- /* Only this subdevice supports WOL */
- if (pdev->subsystem_device == IXGBE_SUBDEV_ID_82599_SFP)
+ /* Only these subdevice supports WOL */
+ switch (pdev->subsystem_device) {
+ case IXGBE_SUBDEV_ID_82599_560FLR:
+ /* only support first port */
+ if (hw->bus.func != 0)
+ break;
+ case IXGBE_SUBDEV_ID_82599_SFP:
adapter->wol = IXGBE_WUFC_MAG;
+ break;
+ }
break;
case IXGBE_DEV_ID_82599_COMBO_BACKPLANE:
/* All except this subdevice support WOL */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 7c5817f..802bfa0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -57,6 +57,7 @@
#define IXGBE_DEV_ID_82599_BACKPLANE_FCOE 0x152a
#define IXGBE_DEV_ID_82599_SFP_FCOE 0x1529
#define IXGBE_SUBDEV_ID_82599_SFP 0x11A9
+#define IXGBE_SUBDEV_ID_82599_560FLR 0x17D0
#define IXGBE_DEV_ID_82599_SFP_EM 0x1507
#define IXGBE_DEV_ID_82599_SFP_SF2 0x154D
#define IXGBE_DEV_ID_82599EN_SFP 0x1557
--
1.7.7.4
^ permalink raw reply related
* [net-next 5/7] ixgbe: add write flush in ixgbe_clock_out_i2c_byte()
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
I2C access is timing critical. Always do a write flush after writing
to the I2CCTL register.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index 8b113e3..7cf1e1f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -1457,6 +1457,7 @@ static s32 ixgbe_clock_out_i2c_byte(struct ixgbe_hw *hw, u8 data)
i2cctl = IXGBE_READ_REG(hw, IXGBE_I2CCTL);
i2cctl |= IXGBE_I2C_DATA_OUT;
IXGBE_WRITE_REG(hw, IXGBE_I2CCTL, i2cctl);
+ IXGBE_WRITE_FLUSH(hw);
return status;
}
--
1.7.7.4
^ permalink raw reply related
* [net-next 6/7] ixgbe: add support for new 82599 device id
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Support for new 82599 based quad port adapter.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 4ae26a7..7720721 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -356,6 +356,7 @@ static enum ixgbe_media_type ixgbe_get_media_type_82599(struct ixgbe_hw *hw)
case IXGBE_DEV_ID_82599_SFP_FCOE:
case IXGBE_DEV_ID_82599_SFP_EM:
case IXGBE_DEV_ID_82599_SFP_SF2:
+ case IXGBE_DEV_ID_82599_SFP_SF_QP:
case IXGBE_DEV_ID_82599EN_SFP:
media_type = ixgbe_media_type_fiber;
break;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cd1f893..e27e4d1 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -106,6 +106,7 @@ static DEFINE_PCI_DEVICE_TABLE(ixgbe_pci_tbl) = {
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_SFP_SF2), board_82599 },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_LS), board_82599 },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599EN_SFP), board_82599 },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_SFP_SF_QP), board_82599 },
/* required last entry */
{0, }
};
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 242643a..7c5817f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -65,6 +65,7 @@
#define IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ 0x000C
#define IXGBE_DEV_ID_82599_LS 0x154F
#define IXGBE_DEV_ID_X540T 0x1528
+#define IXGBE_DEV_ID_82599_SFP_SF_QP 0x154A
/* VF Device IDs */
#define IXGBE_DEV_ID_82599_VF 0x10ED
--
1.7.7.4
^ permalink raw reply related
* [net-next 4/7] ixgbe: fix typo's
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Stephen Hemminger, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Saw typo in one message, so decided to run spell checker.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fcf8d4e..cd1f893 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -146,7 +146,7 @@ static void ixgbe_service_event_complete(struct ixgbe_adapter *adapter)
{
BUG_ON(!test_bit(__IXGBE_SERVICE_SCHED, &adapter->state));
- /* flush memory to make sure state is correct before next watchog */
+ /* flush memory to make sure state is correct before next watchdog */
smp_mb__before_clear_bit();
clear_bit(__IXGBE_SERVICE_SCHED, &adapter->state);
}
@@ -2156,7 +2156,7 @@ static irqreturn_t ixgbe_intr(int irq, void *data)
IXGBE_WRITE_REG(hw, IXGBE_EIMC, IXGBE_IRQ_CLEAR_MASK);
/* for NAPI, using EIAM to auto-mask tx/rx interrupt bits on read
- * therefore no explict interrupt disable is necessary */
+ * therefore no explicit interrupt disable is necessary */
eicr = IXGBE_READ_REG(hw, IXGBE_EICR);
if (!eicr) {
/*
@@ -3606,7 +3606,7 @@ static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
static void ixgbe_sfp_link_config(struct ixgbe_adapter *adapter)
{
/*
- * We are assuming the worst case scenerio here, and that
+ * We are assuming the worst case scenario here, and that
* is that an SFP was inserted/removed after the reset
* but before SFP detection was enabled. As such the best
* solution is to just start searching as soon as we start
@@ -3828,7 +3828,7 @@ void ixgbe_reset(struct ixgbe_adapter *adapter)
case IXGBE_ERR_EEPROM_VERSION:
/* We are running on a pre-production device, log a warning */
e_dev_warn("This device is a pre-production adapter/LOM. "
- "Please be aware there may be issuesassociated with "
+ "Please be aware there may be issues associated with "
"your hardware. If you are experiencing problems "
"please contact your Intel or hardware "
"representative who provided you with this "
@@ -5792,9 +5792,9 @@ static void ixgbe_fdir_reinit_subtask(struct ixgbe_adapter *adapter)
* @adapter - pointer to the device adapter structure
*
* This function serves two purposes. First it strobes the interrupt lines
- * in order to make certain interrupts are occuring. Secondly it sets the
+ * in order to make certain interrupts are occurring. Secondly it sets the
* bits needed to check for TX hangs. As a result we should immediately
- * determine if a hang has occured.
+ * determine if a hang has occurred.
*/
static void ixgbe_check_hang_subtask(struct ixgbe_adapter *adapter)
{
@@ -7132,7 +7132,7 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
return -EINVAL;
/* Hardware has to reinitialize queues and interrupts to
- * match packet buffer alignment. Unfortunantly, the
+ * match packet buffer alignment. Unfortunately, the
* hardware is not flexible enough to do this dynamically.
*/
if (netif_running(dev))
--
1.7.7.4
^ permalink raw reply related
* [net-next 2/7] igb: Add flow control advertising to ethtool setting.
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Carolyn Wyborny, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
Added pause flag for bi-directional flow control advertising to ethtool
settings.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index e9335ef..f1206be 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -148,7 +148,8 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
SUPPORTED_1000baseT_Full|
SUPPORTED_Autoneg |
SUPPORTED_TP);
- ecmd->advertising = ADVERTISED_TP;
+ ecmd->advertising = (ADVERTISED_TP |
+ ADVERTISED_Pause);
if (hw->mac.autoneg == 1) {
ecmd->advertising |= ADVERTISED_Autoneg;
@@ -165,7 +166,8 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
ecmd->advertising = (ADVERTISED_1000baseT_Full |
ADVERTISED_FIBRE |
- ADVERTISED_Autoneg);
+ ADVERTISED_Autoneg |
+ ADVERTISED_Pause);
ecmd->port = PORT_FIBRE;
}
--
1.7.7.4
^ permalink raw reply related
* [net-next 3/7] ixgbe: fix incorrect PHY register reads
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Fix some register reads that had the opcode and register parameters swapped.
Also use define instead of a magic (0x3) number.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index bdf535a..a3aa633 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -266,10 +266,10 @@ s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw)
if (hw->mac.type == ixgbe_mac_X540) {
if (hw->phy.id == 0)
hw->phy.ops.identify(hw);
- hw->phy.ops.read_reg(hw, 0x3, IXGBE_PCRC8ECL, &i);
- hw->phy.ops.read_reg(hw, 0x3, IXGBE_PCRC8ECH, &i);
- hw->phy.ops.read_reg(hw, 0x3, IXGBE_LDPCECL, &i);
- hw->phy.ops.read_reg(hw, 0x3, IXGBE_LDPCECH, &i);
+ hw->phy.ops.read_reg(hw, IXGBE_PCRC8ECL, MDIO_MMD_PCS, &i);
+ hw->phy.ops.read_reg(hw, IXGBE_PCRC8ECH, MDIO_MMD_PCS, &i);
+ hw->phy.ops.read_reg(hw, IXGBE_LDPCECL, MDIO_MMD_PCS, &i);
+ hw->phy.ops.read_reg(hw, IXGBE_LDPCECH, MDIO_MMD_PCS, &i);
}
return 0;
--
1.7.7.4
^ permalink raw reply related
* [net-next 1/7] ixgbevf: Fix register defines to correctly handle complex expressions
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1325555451-4697-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch is meant to address possible issues with the IXGBEVF register
defines generating incorrect values when given a complex expression for the
register offset.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 +-
drivers/net/ethernet/intel/ixgbevf/regs.h | 42 ++++++++++++++--------------
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index ea393eb..9d38a94 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -47,8 +47,8 @@
#define IXGBE_VFMAILBOX_RSTD 0x00000080 /* PF has indicated reset done */
#define IXGBE_VFMAILBOX_R2C_BITS 0x000000B0 /* All read to clear bits */
-#define IXGBE_PFMAILBOX(x) (0x04B00 + (4 * x))
-#define IXGBE_PFMBMEM(vfn) (0x13000 + (64 * vfn))
+#define IXGBE_PFMAILBOX(x) (0x04B00 + (4 * (x)))
+#define IXGBE_PFMBMEM(vfn) (0x13000 + (64 * (vfn)))
#define IXGBE_PFMAILBOX_STS 0x00000001 /* Initiate message send to VF */
#define IXGBE_PFMAILBOX_ACK 0x00000002 /* Ack message recv'd from VF */
diff --git a/drivers/net/ethernet/intel/ixgbevf/regs.h b/drivers/net/ethernet/intel/ixgbevf/regs.h
index 189200e..5e4d5e5 100644
--- a/drivers/net/ethernet/intel/ixgbevf/regs.h
+++ b/drivers/net/ethernet/intel/ixgbevf/regs.h
@@ -39,29 +39,29 @@
#define IXGBE_VTEIMC 0x0010C
#define IXGBE_VTEIAC 0x00110
#define IXGBE_VTEIAM 0x00114
-#define IXGBE_VTEITR(x) (0x00820 + (4 * x))
-#define IXGBE_VTIVAR(x) (0x00120 + (4 * x))
+#define IXGBE_VTEITR(x) (0x00820 + (4 * (x)))
+#define IXGBE_VTIVAR(x) (0x00120 + (4 * (x)))
#define IXGBE_VTIVAR_MISC 0x00140
-#define IXGBE_VTRSCINT(x) (0x00180 + (4 * x))
-#define IXGBE_VFRDBAL(x) (0x01000 + (0x40 * x))
-#define IXGBE_VFRDBAH(x) (0x01004 + (0x40 * x))
-#define IXGBE_VFRDLEN(x) (0x01008 + (0x40 * x))
-#define IXGBE_VFRDH(x) (0x01010 + (0x40 * x))
-#define IXGBE_VFRDT(x) (0x01018 + (0x40 * x))
-#define IXGBE_VFRXDCTL(x) (0x01028 + (0x40 * x))
-#define IXGBE_VFSRRCTL(x) (0x01014 + (0x40 * x))
-#define IXGBE_VFRSCCTL(x) (0x0102C + (0x40 * x))
+#define IXGBE_VTRSCINT(x) (0x00180 + (4 * (x)))
+#define IXGBE_VFRDBAL(x) (0x01000 + (0x40 * (x)))
+#define IXGBE_VFRDBAH(x) (0x01004 + (0x40 * (x)))
+#define IXGBE_VFRDLEN(x) (0x01008 + (0x40 * (x)))
+#define IXGBE_VFRDH(x) (0x01010 + (0x40 * (x)))
+#define IXGBE_VFRDT(x) (0x01018 + (0x40 * (x)))
+#define IXGBE_VFRXDCTL(x) (0x01028 + (0x40 * (x)))
+#define IXGBE_VFSRRCTL(x) (0x01014 + (0x40 * (x)))
+#define IXGBE_VFRSCCTL(x) (0x0102C + (0x40 * (x)))
#define IXGBE_VFPSRTYPE 0x00300
-#define IXGBE_VFTDBAL(x) (0x02000 + (0x40 * x))
-#define IXGBE_VFTDBAH(x) (0x02004 + (0x40 * x))
-#define IXGBE_VFTDLEN(x) (0x02008 + (0x40 * x))
-#define IXGBE_VFTDH(x) (0x02010 + (0x40 * x))
-#define IXGBE_VFTDT(x) (0x02018 + (0x40 * x))
-#define IXGBE_VFTXDCTL(x) (0x02028 + (0x40 * x))
-#define IXGBE_VFTDWBAL(x) (0x02038 + (0x40 * x))
-#define IXGBE_VFTDWBAH(x) (0x0203C + (0x40 * x))
-#define IXGBE_VFDCA_RXCTRL(x) (0x0100C + (0x40 * x))
-#define IXGBE_VFDCA_TXCTRL(x) (0x0200c + (0x40 * x))
+#define IXGBE_VFTDBAL(x) (0x02000 + (0x40 * (x)))
+#define IXGBE_VFTDBAH(x) (0x02004 + (0x40 * (x)))
+#define IXGBE_VFTDLEN(x) (0x02008 + (0x40 * (x)))
+#define IXGBE_VFTDH(x) (0x02010 + (0x40 * (x)))
+#define IXGBE_VFTDT(x) (0x02018 + (0x40 * (x)))
+#define IXGBE_VFTXDCTL(x) (0x02028 + (0x40 * (x)))
+#define IXGBE_VFTDWBAL(x) (0x02038 + (0x40 * (x)))
+#define IXGBE_VFTDWBAH(x) (0x0203C + (0x40 * (x)))
+#define IXGBE_VFDCA_RXCTRL(x) (0x0100C + (0x40 * (x)))
+#define IXGBE_VFDCA_TXCTRL(x) (0x0200c + (0x40 * (x)))
#define IXGBE_VFGPRC 0x0101C
#define IXGBE_VFGPTC 0x0201C
#define IXGBE_VFGORC_LSB 0x01020
--
1.7.7.4
^ permalink raw reply related
* [net-next 0/7][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-01-03 1:50 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
The following series contains updates to igb, ixgbe and ixgbevf. Most of
the changes are adding support of some kind. There are 3 fixes, one fix
for ixgbevf to fix register defines. The other two fixes are for ixgbe,
one being a minor comment spelling fix and the other is to fix register
reads.
Here is a list of the new support added:
- 2 new device id's in ixgbe
- igb flow control advertising to ethtool
v2: Dropped the 2 patches to 'add thermal data sensor' to ixgbe while Don/PJ
review and potentially fix-up the patches based on community feedback.
The following are changes since commit 455ffa607f0efa90c9fec99604553b7cdd5274b2:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander Duyck (1):
ixgbevf: Fix register defines to correctly handle complex expressions
Carolyn Wyborny (1):
igb: Add flow control advertising to ethtool setting.
Don Skidmore (1):
ixgbe: add support for new 82599 device.
Emil Tantilov (3):
ixgbe: fix incorrect PHY register reads
ixgbe: add write flush in ixgbe_clock_out_i2c_byte()
ixgbe: add support for new 82599 device id
Stephen Hemminger (1):
ixgbe: fix typo's
drivers/net/ethernet/intel/igb/igb_ethtool.c | 6 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 8 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 15 ++++++--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 26 +++++++++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 +
drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 +-
drivers/net/ethernet/intel/ixgbevf/regs.h | 42 +++++++++++-----------
9 files changed, 64 insertions(+), 41 deletions(-)
--
1.7.7.4
^ permalink raw reply
* Re: [PATCH net-next V2 0/2] igb: ptp hardware clock
From: Jeff Kirsher @ 2012-01-03 1:20 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, e1000-devel, Jacob Keller, John Ronciak, John Stultz,
Thomas Gleixner
In-Reply-To: <cover.1324901880.git.richardcochran@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]
On Mon, 2011-12-26 at 13:26 +0100, Richard Cochran wrote:
> * ChangeLog V2
> - Fixed wrong bit shifting in the 82576 code.
> - Explained the timestamp locking with a comment in the code.
> - Preserved the comments from the original timecompare implementation.
> - Added an additional test within the overflow counter code to fix
> a race condition. Details of the problem are given in the commit
> message.
>
> This patch series implements a PHC driver for the Intel 82576 and
> 82580 devices, as part of the igb driver.
>
> The first patch adds the PHC driver code as a new source module but
> does not link it into the main igb driver. Because the system time
> counter is not so very wide, the code implements an overflow counter
> in software. Every read operation maintains the overflow counter, as
> does a "delayed work" watchdog. Only the base clock operations are
> implemented. The hardware does have some ancillary features, but these
> can be easily added later.
>
> The second patch removes the timecompare code and links in the new
> functions.
>
> I have tested the 82580 with good results. However, I don't have the
> 82576 and so would appreciate testing and feedback.
>
> Thanks,
> Richard
>
>
> Richard Cochran (2):
> igb: add PTP Hardware Clock code
> igb: offer a PTP Hardware Clock instead of the timecompare method
>
> drivers/net/ethernet/intel/igb/Makefile | 2 +-
> drivers/net/ethernet/intel/igb/igb.h | 21 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 167 +----------
> drivers/net/ethernet/intel/igb/igb_ptp.c | 486 +++++++++++++++++++++++++++++
> 4 files changed, 505 insertions(+), 171 deletions(-)
> create mode 100644 drivers/net/ethernet/intel/igb/igb_ptp.c
>
We found an issue with this series of patches, if we did not have
CONFIG_PTP_1588_CLOCK enabled in the kernel, the igb driver would not
compile.
So I would suggest wrapping the portions of code with #ifdef
CONFIG_PTP_1588_CLOCK.
I will await v3 of the series, thanks Richard for this work!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* skge warning
From: Daniel Halperin @ 2012-01-03 0:01 UTC (permalink / raw)
To: netdev
I'm using Linus' current branch.
drivers/net/ethernet/marvell/skge.c:4046: warning: ‘skge_suspend’
defined but not used
drivers/net/ethernet/marvell/skge.c:4071: warning: ‘skge_resume’
defined but not used
It appears to be the use of the wrong CONFIG option. (The code
curently uses CONFIG_PM to see whether these functions are used).
Here's the relevant section of my .config:
#
# Power management and ACPI options
#
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
Thanks,
Dan
^ permalink raw reply
* RE: e1000e interface hang on 82574L
From: Wyborny, Carolyn @ 2012-01-03 0:02 UTC (permalink / raw)
To: Chris Boot, netdev, lkml, e1000-devel@lists.sourceforge.net
In-Reply-To: <FCF3184D-CE4F-471C-B66C-0F671795FD3C@bootc.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Chris Boot
>Sent: Saturday, December 31, 2011 1:32 AM
>To: netdev; lkml; e1000-devel@lists.sourceforge.net
>Subject: Re: e1000e interface hang on 82574L
>
>On 27 Dec 2011, at 22:01, Chris Boot wrote:
>
>> Hi folks,
>>
>> Another networking issue I've run into, this time with e1000e (Intel
>Corporation 82574L Gigabit). My new VM cluster appears to drop a NIC -
>the port stops responding within Linux and shows the link as being down
>with ethtool. My ISP says 'Ports running Half Duplex or reduced speed'
>on the port.
>>
>> When the port stops working I see this in dmesg:
>>
>> [35481.659629] ------------[ cut here ]------------
>> [35481.667837] WARNING: at net/sched/sch_generic.c:255
>dev_watchdog+0xe9/0x148()
>> [35481.676370] Hardware name: X9SCL/X9SCM
>> [35481.684793] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed
>out
>> [35481.684795] Modules linked in: hmac sha256_generic dlm configfs
>ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats
>cpufreq_conservative cpufreq_userspace cpufreq_powersave microcode
>xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow cls_fw cls_u32
>sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_connlimit
>xt_realm xt_addrtype ip_set_hash_ip iptable_raw xt_comment xt_recent
>ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN
>ipt_ecn ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic
>nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
>nf_nat_h323 nf_nat_ftp ip6_queue nf_nat_amanda xt_set ip_set
>nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane
>nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp
>nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
>nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323
>nf_conntrack_ftp ts_kmp nf_conntrack_amanda xt_TPROXY xt_NFLOG
>nfnetlink_log nf_tproxy_core xt_time xt_TCPMSS xt_tcpmss xt_sctp
>xt_policy xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_multiport xt_mark
>xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP
>xt_dscp xt_dccp xt_connmark xt_CLASSIFY xt_AUDIT ip6t_LOG ip6t_REJECT
>nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip6table_raw ipt_LOG
>xt_tcpudp ip6table_mangle xt_state iptable_nat nf_nat nf_conntrack_ipv4
>nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter
>ip_tables ip6table_filter ip6_tables x_tables bridge stp bonding
>w83627ehf hwmon_vid coretemp sha1_ssse3 sha1_generic crc32c_intel
>aesni_intel cryptd aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf
>ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache cn
>loop kvm_intel kvm snd_pcm snd_timer snd iTCO_wdt soundcore psmouse
>snd_page_alloc i2c_i801 i2c_core cdc_acm iTCO_vendor_support joydev
>evdev serio_raw processor button pcspkr thermal_sys ext4 mbcache jbd2
>crc16 dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas usbhid hid
>ahci libahci libata igb ehci_hcd scsi_mod usbcore e1000e dca usb_common
>[last unloaded: scsi_wait_scan]
>> [35481.685740] Pid: 0, comm: swapper/4 Not tainted 3.2.0-rc6+ #4
>> [35481.685744] Call Trace:
>> [35481.685746] <IRQ> [<ffffffff810467ed>] ?
>warn_slowpath_common+0x78/0x8c
>> [35481.685849] [<ffffffff81046899>] ? warn_slowpath_fmt+0x45/0x4a
>> [35481.685875] [<ffffffff810aeaa0>] ?
>perf_event_task_tick+0x166/0x1ab
>> [35481.686018] [<ffffffff81294219>] ? netif_tx_lock+0x40/0x72
>> [35481.686090] [<ffffffff8129437a>] ? dev_watchdog+0xe9/0x148
>> [35481.686136] [<ffffffff81051e58>] ? run_timer_softirq+0x19a/0x261
>> [35481.686176] [<ffffffff81294291>] ? netif_tx_unlock+0x46/0x46
>> [35481.686215] [<ffffffff810659bb>] ? timekeeping_get_ns+0xd/0x2a
>> [35481.686286] [<ffffffff8104bdd4>] ? __do_softirq+0xb9/0x177
>> [35481.686365] [<ffffffff81341d6c>] ? call_softirq+0x1c/0x30
>> [35481.686530] [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
>> [35481.686580] [<ffffffff8104c03c>] ? irq_exit+0x3c/0x9a
>> [35481.686742] [<ffffffff81023e58>] ?
>smp_apic_timer_interrupt+0x74/0x82
>> [35481.686820] [<ffffffff813405de>] ? apic_timer_interrupt+0x6e/0x80
>> [35481.686826] <EOI> [<ffffffff811ddf49>] ? intel_idle+0xea/0x119
>> [35481.686991] [<ffffffff811ddf28>] ? intel_idle+0xc9/0x119
>> [35481.687051] [<ffffffff8125dce3>] ? cpuidle_idle_call+0xec/0x179
>> [35481.687089] [<ffffffff8100d255>] ? cpu_idle+0xa1/0xe8
>> [35481.687143] [<ffffffff810706ee>] ? arch_local_irq_restore+0x2/0x8
>> [35481.687189] [<ffffffff8132d191>] ? start_secondary+0x1d5/0x1db
>> [35481.687234] ---[ end trace 01e9907674757948 ]---
>> [35481.687817] e1000e 0000:05:00.0: eth2: Reset adapter
>>
>> To try to regain connectivity I bring down the bond and the interface
>(eth2), then unload e1000e. Upon loading the module again:
>>
>> [36021.888962] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
>> [36021.900258] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
>> [36021.911446] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -
>> IRQ 20
>> [36021.923204] e1000e 0000:00:19.0: setting latency timer to 64
>> [36021.923372] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>> [36022.202737] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width
>x1) 00:25:90:56:ac:75
>> [36022.214480] e1000e 0000:00:19.0: eth3: Intel(R) PRO/1000 Network
>Connection
>> [36022.227506] e1000e 0000:00:19.0: eth3: MAC: 10, PHY: 11, PBA No:
>FFFFFF-0FF
>> [36022.239789] e1000e 0000:05:00.0: Disabling ASPM L0s
>> [36022.239805] e1000e 0000:05:00.0: enabling device (0000 -> 0002)
>> [36022.239829] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -
>> IRQ 16
>> [36022.239921] e1000e 0000:05:00.0: setting latency timer to 64
>> [36022.240963] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
>> [36022.240995] e1000e 0000:05:00.0: irq 65 for MSI/MSI-X
>> [36022.241028] e1000e 0000:05:00.0: irq 66 for MSI/MSI-X
>> [36022.241596] e1000e 0000:05:00.0: PCI INT A disabled
>> [36022.241606] e1000e: probe of 0000:05:00.0 failed with error -2
>> [36022.304706] udevd[3634]: renamed network interface eth2 to eth3
>>
>> I then don't get an eth2 interface. Only a reboot brings the interface
>back. This has happened twice so far on this server in the past week,
>both times using v3.2-rc7-3-g4962516.
>>
>> lspci -vnn shows:
>>
>> 05:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit
>Network Connection [8086:10d3]
>> Subsystem: Super Micro Computer Inc Device [15d9:0000]
>> Flags: bus master, fast devsel, latency 0, IRQ 16
>> Memory at fbd00000 (32-bit, non-prefetchable) [size=128K]
>> I/O ports at e000 [size=32]
>> Memory at fbd20000 (32-bit, non-prefetchable) [size=16K]
>> Capabilities: [c8] Power Management version 2
>> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
>> Capabilities: [e0] Express Endpoint, MSI 00
>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [140] Device Serial Number 00-25-90-ff-ff-56-ac-
>74
>> Kernel driver in use: e1000e
>
>I've just had this happen on my other (identical) server with a nearly
>identical trace. Is there anything I can do do avoid this at all or at
>least help narrow down the problem?
>
>Cheers,
>Chris
>
>--
>Chris Boot
>bootc@bootc.net
>
>--
>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
Hello,
Sorry for the delay in responding. We have seen some hang issues using MSI-X on 82574 parts. Can you try reloading the driver the IntMode module parameter. IntMode=1 (you'll need a setting for each device in the system so two adapters would be IntMode=1,1) See if that changes the symptom you are seeing with this part. That setting will make sure the adapter uses MSI interrupts instead of MSI-X.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next 1/2] mlx4_core: fix mtt range deallocation
From: Yinghai Lu @ 2012-01-02 22:05 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev, marcela
In-Reply-To: <4F01BA2B.1060605@mellanox.co.il>
On Mon, Jan 2, 2012 at 6:07 AM, Yevgeny Petrilin
<yevgenyp@mellanox.co.il> wrote:
> From: Marcel Apfelbaum <marcela@mellanox.co.il>
>
> The mtt range was allocated in mtt units but deallocated
> in segments. Among the rest, this caused crash during hotplug removal
>
> Reported-by: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
> Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> ---
> drivers/net/ethernet/mellanox/mlx4/mr.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
> index f7243b2..01df556 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mr.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
> @@ -239,8 +239,8 @@ void __mlx4_free_mtt_range(struct mlx4_dev *dev, u32 offset, int order)
> first_seg = offset / (1 << log_mtts_per_seg);
>
> mlx4_buddy_free(&mr_table->mtt_buddy, first_seg, seg_order);
> - mlx4_table_put_range(dev, &mr_table->mtt_table, first_seg,
> - first_seg + (1 << seg_order) - 1);
> + mlx4_table_put_range(dev, &mr_table->mtt_table, offset,
> + offset + (1 << order) - 1);
> }
>
> static void mlx4_free_mtt_range(struct mlx4_dev *dev, u32 offset, int order)
Tested-by: Yinghai Lu <yinghai@kernel.org>
^ 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