* RE: [stable] [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Amit Salecha @ 2011-04-14 5:22 UTC (permalink / raw)
To: Greg KH; +Cc: David Miller, netdev, Anirban Chakraborty, stable, Ameen Rahman
In-Reply-To: <20110413161534.GA20578@kroah.com>
> > Footer will present in my reply to this email. But footer should not
> be there in patches sent by me.
> > Can you verify patch version 2 again ? Here
> http://patchwork.ozlabs.org/patch/90938/ I don't see any footer.
> > If you see footer with patch version 2, please send me that.
>
> Your footer was not in your patch, correct. But it was in this email.
>
> And that's the issue, you can't have that footer on emails you send to
> a
> public list where you are going to be collaborating on a public
> project,
> otherwise no one can use anything you say.
>
> Now if you only think that people will just accept your patches,
> without
> being able to have you participate in development and maintance of
> those
> patches (which is required to be done through email), you are mistaken.
>
> So please fix your email issue, otherwise it is not going to work.
>
> Note, other people at qualcomm have fixed this, so you are not alone.
>
Ok.
Our IT has fixed the footer issue. Sending this email to verify.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Hiroaki SHIMODA @ 2011-04-14 4:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, David Miller, lkml, netdev
In-Reply-To: <1302752263.3549.41.camel@edumazet-laptop>
On Thu, 14 Apr 2011 05:37:43 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Indeed good catch, but should we return 0 or -EINVAL so that caller can
> drop packet ?
>
> @@ -606,7 +606,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
> if (!opt->srr)
> return 0;
>
> - if (skb->pkt_type != PACKET_HOST)
> + if (skb->pkt_type != PACKET_HOST || !rt)
> return -EINVAL;
> if (rt->rt_type == RTN_UNICAST) {
> if (!opt->is_strictroute)
>
As your patch does we don't treat an skb without rt as error
on bridge/netfilter context.
So, I think returning 0 would be better off.
But thinking of ip_options_rcv_srr() is called from another context again
adding an extra check in br_parse_ip_options() is safer ?
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index f3bc322..10ac127 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -263,7 +263,7 @@ static int br_parse_ip_options(struct sk_buff *skb)
if (in_dev && !IN_DEV_SOURCE_ROUTE(in_dev))
goto drop;
- if (ip_options_rcv_srr(skb))
+ if (skb_rtable(skb) && ip_options_rcv_srr(skb))
goto drop;
}
Thanks.
^ permalink raw reply related
* RE: SMSC 8720a/MDIO/PHY help.
From: ANDY KENNEDY @ 2011-04-14 4:08 UTC (permalink / raw)
To: netdev
In-Reply-To: <9AC3F0E75060224C8BBC5BA2DDC8853A1FA8E8D4@EXV1.corp.adtran.com>
> > -----Original Message-----
> > From: Michael Riesch [mailto:michael@riesch.at]
> > Sent: Wednesday, April 13, 2011 4:19 PM
> > To: netdev@vger.kernel.org
> > Cc: ANDY KENNEDY
> > Subject: Re: SMSC 8720a/MDIO/PHY help.
> >
> >
> > > If you have an idea of something for me to try, I'd love to
> > entertain
> > > it.
> >
> > I am rather new to PHYLIB, but these are my ideas:
> >
> > 1) make sure phy_connect is executed (AFIAK called by MDIO bus
> > driver)
Along this line of though: phy_connect requires struct net_device, which has a struct net_device_ops within it. When I do a phy_connect am I supposed to provide the minimal functions for netdev_ops (correct this list if I am mistaken):
ndo_open
ndo_stop
ndo_start_xmit
ndo_get_stats
ndo_set_multicast_list
As well as populate the dev->dev_addr within the struct net_device.
The part that confuses me is that the smsc.c ??driver?? under drivers/net/phy/smsc.c doesn’t do any of this. This is a phy supported by this file, so should I have to do all this to get the device up?
Spinning,
Andy
^ permalink raw reply
* Re: [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Eric Dumazet @ 2011-04-14 3:37 UTC (permalink / raw)
To: Hiroaki SHIMODA; +Cc: Stephen Hemminger, David Miller, lkml, netdev
In-Reply-To: <20110414123058.d4ffe7fb.shimoda.hiroaki@gmail.com>
Le jeudi 14 avril 2011 à 12:30 +0900, Hiroaki SHIMODA a écrit :
> On Thu, 14 Apr 2011 05:03:34 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le mercredi 13 avril 2011 à 19:54 -0700, Stephen Hemminger a écrit :
> >
> > > I like this because it lets the bridge be transparent.
> > > The existing options code adds entry in record route, and which
> > > is not desirable.
> >
> > OK then, I realize I should have submitted a full patch, here it is.
> >
> > Thanks !
> >
> > [PATCH] ip: ip_options_compile() resilient to NULL skb route
> >
> > Scot Doyle demonstrated ip_options_compile() could be called with an skb
> > without an attached route, using a setup involving a bridge, netfilter,
> > and forged IP packets.
> >
> > Let's make ip_options_compile() a bit more robust, instead of changing
> > bridge/netfilter code.
>
> And ip_options_rcv_srr() in br_parse_ip_options() also
> expects an skb with attached route, so below patch is needed ?
>
> diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
> index 28a736f..3af1968 100644
> --- a/net/ipv4/ip_options.c
> +++ b/net/ipv4/ip_options.c
> @@ -603,7 +603,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
> unsigned long orefdst;
> int err;
>
> - if (!opt->srr)
> + if (!opt->srr || !rt)
> return 0;
>
> if (skb->pkt_type != PACKET_HOST)
>
> Thanks.
Indeed good catch, but should we return 0 or -EINVAL so that caller can
drop packet ?
@@ -606,7 +606,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
if (!opt->srr)
return 0;
- if (skb->pkt_type != PACKET_HOST)
+ if (skb->pkt_type != PACKET_HOST || !rt)
return -EINVAL;
if (rt->rt_type == RTN_UNICAST) {
if (!opt->is_strictroute)
^ permalink raw reply
* Re: [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Hiroaki SHIMODA @ 2011-04-14 3:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, David Miller, lkml, netdev
In-Reply-To: <1302750214.3549.34.camel@edumazet-laptop>
On Thu, 14 Apr 2011 05:03:34 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 13 avril 2011 à 19:54 -0700, Stephen Hemminger a écrit :
>
> > I like this because it lets the bridge be transparent.
> > The existing options code adds entry in record route, and which
> > is not desirable.
>
> OK then, I realize I should have submitted a full patch, here it is.
>
> Thanks !
>
> [PATCH] ip: ip_options_compile() resilient to NULL skb route
>
> Scot Doyle demonstrated ip_options_compile() could be called with an skb
> without an attached route, using a setup involving a bridge, netfilter,
> and forged IP packets.
>
> Let's make ip_options_compile() a bit more robust, instead of changing
> bridge/netfilter code.
And ip_options_rcv_srr() in br_parse_ip_options() also
expects an skb with attached route, so below patch is needed ?
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 28a736f..3af1968 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -603,7 +603,7 @@ int ip_options_rcv_srr(struct sk_buff *skb)
unsigned long orefdst;
int err;
- if (!opt->srr)
+ if (!opt->srr || !rt)
return 0;
if (skb->pkt_type != PACKET_HOST)
Thanks.
^ permalink raw reply related
* [PATCH] ip: ip_options_compile() resilient to NULL skb route
From: Eric Dumazet @ 2011-04-14 3:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, lkml, shimoda.hiroaki, netdev
In-Reply-To: <20110413195424.1d2393c6@s6510>
Le mercredi 13 avril 2011 à 19:54 -0700, Stephen Hemminger a écrit :
> I like this because it lets the bridge be transparent.
> The existing options code adds entry in record route, and which
> is not desirable.
OK then, I realize I should have submitted a full patch, here it is.
Thanks !
[PATCH] ip: ip_options_compile() resilient to NULL skb route
Scot Doyle demonstrated ip_options_compile() could be called with an skb
without an attached route, using a setup involving a bridge, netfilter,
and forged IP packets.
Let's make ip_options_compile() a bit more robust, instead of changing
bridge/netfilter code.
Reported-by: Scot Doyle <lkml@scotdoyle.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
---
net/ipv4/ip_options.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 28a736f..c10ad63 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -329,7 +329,7 @@ int ip_options_compile(struct net *net,
pp_ptr = optptr + 2;
goto error;
}
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
opt->is_changed = 1;
}
@@ -371,7 +371,7 @@ int ip_options_compile(struct net *net,
goto error;
}
opt->ts = optptr - iph;
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
timeptr = (__be32*)&optptr[optptr[2]+3];
}
^ permalink raw reply related
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Stephen Hemminger @ 2011-04-14 2:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, lkml, shimoda.hiroaki, netdev
In-Reply-To: <1302748276.3549.20.camel@edumazet-laptop>
On Thu, 14 Apr 2011 04:31:16 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 13 avril 2011 à 14:48 -0700, David Miller a écrit :
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 13 Apr 2011 17:28:07 +0200
> >
> > > Dont worry, Stephen or me will send it asap.
> >
> > I'm looking forward to it :)
>
> I was considering another way to handle this problem,
> patching ip_options_compile() to take care of null skb_dst() in slow
> path instead ?
>
> What would be the best thing ?
>
> diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
> index 28a736f..c10ad63 100644
> --- a/net/ipv4/ip_options.c
> +++ b/net/ipv4/ip_options.c
> @@ -329,7 +329,7 @@ int ip_options_compile(struct net *net,
> pp_ptr = optptr + 2;
> goto error;
> }
> - if (skb) {
> + if (rt) {
> memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
> opt->is_changed = 1;
> }
> @@ -371,7 +371,7 @@ int ip_options_compile(struct net *net,
> goto error;
> }
> opt->ts = optptr - iph;
> - if (skb) {
> + if (rt) {
> memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
> timeptr = (__be32*)&optptr[optptr[2]+3];
> }
>
I like this because it lets the bridge be transparent.
The existing options code adds entry in record route, and which
is not desirable.
^ permalink raw reply
* [net-next-2.6 00/26 v2][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-04-14 2:38 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
The following series contains updates to e1000e, igb and ixgbe.
- e1000e has two conversion, one to use usleep_range and the other
to the new VLAN model. There is also a fix for a debug statement as
well as a fix for ASPM.
- igb has a documentation update, comment fix, and the introduction
of thermal sensor checking.
- ixgbe contains the majority of the changes, with several cleanups
and fixes. As well as a conversion to use usleep_range().
-v2 Drop the e1000 patch to convert to the new set_phys_id interface
The following are changes since commit c326de88b8ac7ed1cd1027017ba6079dbe91be49:
net: allow shifted access in smsc911x V2
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Bruce Allan (3):
e1000e: convert short duration msleep() to usleep_range()
e1000e: PCIe link speed in GT/s, not GB/s
e1000e: If ASPM L0s needs to be disabled, do it prior to enabling
device
Don Skidmore (1):
ixgbe: cleanup short msleep's (<20ms) to use usleep_range
Emil Tantilov (10):
ixgbe: fix return value checks
ixgbe: correct function number for some 82598 parts
ixgbe: fix namespacecheck issue
ixgbe: refactor common start_hw code for 82599 and x540
ixgbe: move disabling of relaxed ordering in start_hw()
ixgbe: fix 82599 KR downshift coexistence with LESM FW module
ixgbe: fix semaphores in eeprom routines for x540
ixgbe: add support for new HW
ixgbe: explicitly disable 100H for x540
ixgbe: make device_caps() generic
Flavio Leitner (1):
e1000e: fix stats locking in e1000_watchdog_task
Greg Rose (1):
igb: Add anti-spoofing feature documentation
Jeff Kirsher (2):
e1000e: convert to new VLAN model
ixgbe: update version string for Dell CEM use
John Fastabend (3):
ixgbe: DCB, further cleanups to app configuration
ixgbe: DCB, misallocated packet buffer size with X540 device
ixgbe: DCB, X540 devices do not respond to pause frames
Stefan Assmann (2):
igb: fix typo in igb_validate_nvm_checksum_82580
igb: introduce igb_thermal_sensor_event for sensor checking
Documentation/networking/igb.txt | 13 ++
drivers/net/e1000e/82571.c | 20 ++--
drivers/net/e1000e/e1000.h | 6 +-
drivers/net/e1000e/es2lan.c | 4 +-
drivers/net/e1000e/ethtool.c | 46 ++++++--
drivers/net/e1000e/ich8lan.c | 12 +-
drivers/net/e1000e/lib.c | 10 +-
drivers/net/e1000e/netdev.c | 211 ++++++++++++++++++++---------------
drivers/net/e1000e/phy.c | 4 +-
drivers/net/igb/e1000_82575.c | 3 +-
drivers/net/igb/igb_main.c | 67 ++++++------
drivers/net/ixgbe/ixgbe_82598.c | 60 ++++++++++-
drivers/net/ixgbe/ixgbe_82599.c | 104 ++++++++++++------
drivers/net/ixgbe/ixgbe_common.c | 112 ++++++++++++++++++-
drivers/net/ixgbe/ixgbe_common.h | 4 +-
drivers/net/ixgbe/ixgbe_dcb_82599.c | 77 ++++++++-----
drivers/net/ixgbe/ixgbe_dcb_82599.h | 2 +
drivers/net/ixgbe/ixgbe_dcb_nl.c | 109 ++++--------------
drivers/net/ixgbe/ixgbe_ethtool.c | 14 +-
drivers/net/ixgbe/ixgbe_main.c | 22 ++--
drivers/net/ixgbe/ixgbe_phy.c | 7 +-
drivers/net/ixgbe/ixgbe_type.h | 12 ++
drivers/net/ixgbe/ixgbe_x540.c | 192 +++++++++++++++++++++++---------
23 files changed, 718 insertions(+), 393 deletions(-)
--
1.7.4.2
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Eric Dumazet @ 2011-04-14 2:31 UTC (permalink / raw)
To: David Miller; +Cc: lkml, shemminger, shimoda.hiroaki, netdev
In-Reply-To: <20110413.144812.116375845.davem@davemloft.net>
Le mercredi 13 avril 2011 à 14:48 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 13 Apr 2011 17:28:07 +0200
>
> > Dont worry, Stephen or me will send it asap.
>
> I'm looking forward to it :)
I was considering another way to handle this problem,
patching ip_options_compile() to take care of null skb_dst() in slow
path instead ?
What would be the best thing ?
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index 28a736f..c10ad63 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -329,7 +329,7 @@ int ip_options_compile(struct net *net,
pp_ptr = optptr + 2;
goto error;
}
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
opt->is_changed = 1;
}
@@ -371,7 +371,7 @@ int ip_options_compile(struct net *net,
goto error;
}
opt->ts = optptr - iph;
- if (skb) {
+ if (rt) {
memcpy(&optptr[optptr[2]-1], &rt->rt_spec_dst, 4);
timeptr = (__be32*)&optptr[optptr[2]+3];
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Michio Honda @ 2011-04-14 2:28 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, lksctp-developers
In-Reply-To: <4DA65AEF.70800@cn.fujitsu.com>
Ah, OK, if so, this patch is unnecessary.
Sorry for missing to read the code.
Thanks,
- Michio
On Apr 14, 2011, at 11:24 , Wei Yongjun wrote:
>
>> Hi,
>>
>> I implemented that functionality for following situations.
>> 1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
>
> Yes, but the addr list of assoc A and B is independent, see
> asoc->base.bind_addr, which is per asoc.
>
> endpoint hold the bind list for new create assoc. when assoc
> is created, the bind list will be copy from ep, by
> sctp_assoc_set_bind_addr_from_ep().
>
>> 2. After the address addition event, A and B will send an ASCONF.
>> 3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
>> 4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
>> 5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
>> This patch achieves that only A uses that new address in this moment.
>>
>> Am I missing something?
>>
>> Thanks,
>> - Michio
>>
>> On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>>
>>>
>>>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>>>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>>> The new adding address is marked SCTP_ADDR_NEW, and cannot use
>>> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
>>> So, add this valid address list is unnecessary.
>>>
>>> I guess you want to fix the route lookup issue?
>>>
>>> If it is, the only thing we need to fix is the lookup of route. If we can not
>>> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Wei Yongjun @ 2011-04-14 2:24 UTC (permalink / raw)
To: Michio Honda; +Cc: netdev, lksctp-developers
In-Reply-To: <EB560391-3EE8-43BB-83A4-DD55352CFEAF@sfc.wide.ad.jp>
> Hi,
>
> I implemented that functionality for following situations.
> 1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
Yes, but the addr list of assoc A and B is independent, see
asoc->base.bind_addr, which is per asoc.
endpoint hold the bind list for new create assoc. when assoc
is created, the bind list will be copy from ep, by
sctp_assoc_set_bind_addr_from_ep().
> 2. After the address addition event, A and B will send an ASCONF.
> 3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
> 4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
> 5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
> This patch achieves that only A uses that new address in this moment.
>
> Am I missing something?
>
> Thanks,
> - Michio
>
> On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>
>>
>>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>> The new adding address is marked SCTP_ADDR_NEW, and cannot use
>> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
>> So, add this valid address list is unnecessary.
>>
>> I guess you want to fix the route lookup issue?
>>
>> If it is, the only thing we need to fix is the lookup of route. If we can not
>> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Eric Dumazet @ 2011-04-14 2:17 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <20110413.120929.28806842.davem@davemloft.net>
Le mercredi 13 avril 2011 à 12:09 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 13 Apr 2011 05:00:08 +0200
>
> > Le mercredi 13 avril 2011 à 04:55 +0200, Eric Dumazet a écrit :
> >
> >> Since SO_REUSEPORT is not a 'stable fix', I suggest we revert the patch,
> >> and eventually work on SO_REUSEPORT on net-next-2.6
> >>
> >> What do you think ?
> >>
> >
> > Sorry, I should have mentioned commit id : c191a836a908d1dd6
> > (tcp: disallow bind() to reuse addr/port)
>
> I'm commiting the revert as follows to net-2.6, and will queue
> it up for -stable as well:
>
> --------------------
> Revert "tcp: disallow bind() to reuse addr/port"
>
> This reverts commit c191a836a908d1dd6b40c503741f91b914de3348.
>
> It causes known regressions for programs that expect to be able to use
> SO_REUSEADDR to shutdown a socket, then successfully rebind another
> socket to the same ID.
>
> Programs such as haproxy and amavisd expect this to work.
>
> This should fix kernel bugzilla 32832.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
Thanks David, I was planning to submit this revert this morning, you
beat me ;)
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Michio Honda @ 2011-04-14 2:01 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, lksctp-developers
In-Reply-To: <4DA64EF0.30506@cn.fujitsu.com>
Hi,
I implemented that functionality for following situations.
1. Suppose two associations A and B directed to different destination that belong to the same endpoint. (one-to-many socket).
2. After the address addition event, A and B will send an ASCONF.
3. Suppose only A receives ASCONF-ACK, and B has not received one yet.
4. In this moment, A can use the new address as the source address for regular chunk, but B can't.
5. But I think both A and B use the new address even after only A receives ASCONF-ACK in current SCTP implementation,
This patch achieves that only A uses that new address in this moment.
Am I missing something?
Thanks,
- Michio
On Apr 14, 2011, at 10:33 , Wei Yongjun wrote:
>
>
>> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
>> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
>
> The new adding address is marked SCTP_ADDR_NEW, and cannot use
> in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
> So, add this valid address list is unnecessary.
>
> I guess you want to fix the route lookup issue?
>
> If it is, the only thing we need to fix is the lookup of route. If we can not
> found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Simon Horman @ 2011-04-14 1:53 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Vasiliy Kulikov, linux-kernel, netdev, Pavel Kankovsky,
Solar Designer, Kees Cook, Dan Rosenberg, Eugene Teo,
Nelson Elhage, David S. Miller, Alexey Kuznetsov, Pekka Savola,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <BANLkTi=ogJg_uJqsJFpnwnnr6LS+SFT3Vg@mail.gmail.com>
On Wed, Apr 13, 2011 at 01:29:49PM +0300, Alexey Dobriyan wrote:
> On Sat, Apr 9, 2011 at 1:15 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
[snip]
> > @@ -714,8 +790,22 @@ static __net_init int ipv4_sysctl_init_net(struct net *net)
> > &net->ipv4.sysctl_icmp_ratemask;
> > table[6].data =
> > &net->ipv4.sysctl_rt_cache_rebuild_count;
> > +#ifdef CONFIG_IP_PING
> > + table[7].data =
> > + &net->ipv4.sysctl_ping_group_range;
> > +#endif
>
> Now I understand it's not related, but next sysctl will have
> "table[8].data = ..." line which is off-by-one if CONFIG_IP_PING=n.
Another good reason for the code to be non-optoinal
and not to have CONFIG_IP_PING.
^ permalink raw reply
* [PATCH] Clean up 'FLAG_POINTTOPOINT' and 'FLAG_MULTI_PACKET' overlaps in usbnet.h
From: huajun li @ 2011-04-14 1:43 UTC (permalink / raw)
To: David Miller; +Cc: Gottfried Haider, netdev
USB tethering does not work anymore since 2.6.39-rc2, but it's okay in
-rc1. The root cause is the new added mask code 'FLAG_POINTTOPOINT'
overlaps 'FLAG_MULTI_PACKET' in include/linux/usb/usbnet.h, this
causes logic issue in rx_process(). This patch cleans up the overlap.
Reported-and-Tested-by: Gottfried Haider <gottfried.haider@gmail.com>
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
---
include/linux/usb/usbnet.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 3c7329b..0e18550 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -103,8 +103,8 @@ struct driver_info {
* Indicates to usbnet, that USB driver accumulates multiple IP packets.
* Affects statistic (counters) and short packet handling.
*/
-#define FLAG_MULTI_PACKET 0x1000
-#define FLAG_RX_ASSEMBLE 0x2000 /* rx packets may span >1 frames */
+#define FLAG_MULTI_PACKET 0x2000
+#define FLAG_RX_ASSEMBLE 0x4000 /* rx packets may span >1 frames */
/* init device ... can sleep, or cause probe() failure */
int (*bind)(struct usbnet *, struct usb_interface *);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 3/3] sctp: Add a valid address list in association local
From: Wei Yongjun @ 2011-04-14 1:33 UTC (permalink / raw)
To: Michio Honda; +Cc: netdev, lksctp-developers
In-Reply-To: <115A4380-6E63-4014-BD24-04A29472ACCD@sfc.wide.ad.jp>
> When the SCTP association transmits an ASCONF with ADD_IP_ADDRESS, that association cannot use the adding address until it receives ASCONF-ACK.
> This patch prevents that associations that do not receive ASCONF-ACK use the adding address.
The new adding address is marked SCTP_ADDR_NEW, and cannot use
in LKSCTP until received ASCONF-ACK and marked as SCTP_ADDR_SRC.
So, add this valid address list is unnecessary.
I guess you want to fix the route lookup issue?
If it is, the only thing we need to fix is the lookup of route. If we can not
found a valid dst for transport, we can try address marked with SCTP_ADDR_NEW.
^ permalink raw reply
* [PATCH 3/3] net-bonding: Adding support for throughputs larger than 65536 Mbps
From: David Decotigny @ 2011-04-14 1:22 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel; +Cc: David Decotigny
In-Reply-To: <1302744151-12452-1-git-send-email-decot@google.com>
This updates the bonding driver to support v2.6.27-rc3 enhancements
(b11f8d8c aka. "ethtool: Expand ethtool_cmd.speed to 32 bits") which
allow to encode the Mbps link speed on 32-bits (Max 4 Pbps) instead of
16 (Max 65536 Mbps).
This patch also attempts to compact struct slave by reordering its
fields.
Signed-off-by: David Decotigny <decot@google.com>
---
drivers/net/bonding/bond_main.c | 12 +++++++-----
drivers/net/bonding/bonding.h | 6 +++---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 145f9be..c5d8ac2 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -631,7 +631,8 @@ down:
static int bond_update_speed_duplex(struct slave *slave)
{
struct net_device *slave_dev = slave->dev;
- struct ethtool_cmd etool;
+ struct ethtool_cmd etool = { .cmd = ETHTOOL_GSET };
+ u32 slave_speed;
int res;
/* Fake speed and duplex */
@@ -645,7 +646,8 @@ static int bond_update_speed_duplex(struct slave *slave)
if (res < 0)
return -1;
- switch (etool.speed) {
+ slave_speed = ethtool_cmd_speed(&etool);
+ switch (slave_speed) {
case SPEED_10:
case SPEED_100:
case SPEED_1000:
@@ -663,7 +665,7 @@ static int bond_update_speed_duplex(struct slave *slave)
return -1;
}
- slave->speed = etool.speed;
+ slave->speed = slave_speed;
slave->duplex = etool.duplex;
return 0;
@@ -2493,7 +2495,7 @@ static void bond_miimon_commit(struct bonding *bond)
bond_update_speed_duplex(slave);
- pr_info("%s: link status definitely up for interface %s, %d Mbps %s duplex.\n",
+ pr_info("%s: link status definitely up for interface %s, %u Mbps %s duplex.\n",
bond->dev->name, slave->dev->name,
slave->speed, slave->duplex ? "full" : "half");
@@ -3339,7 +3341,7 @@ static int bond_slave_netdev_event(unsigned long event,
slave = bond_get_slave_by_dev(bond, slave_dev);
if (slave) {
- u16 old_speed = slave->speed;
+ u32 old_speed = slave->speed;
u8 old_duplex = slave->duplex;
bond_update_speed_duplex(slave);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 3ca503e..553c764 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -196,12 +196,12 @@ struct slave {
u8 backup:1, /* indicates backup slave. Value corresponds with
BOND_STATE_ACTIVE and BOND_STATE_BACKUP */
inactive:1; /* indicates inactive slave */
+ u8 duplex;
u32 original_mtu;
u32 link_failure_count;
- u8 perm_hwaddr[ETH_ALEN];
- u16 speed;
- u8 duplex;
+ u32 speed;
u16 queue_id;
+ u8 perm_hwaddr[ETH_ALEN];
struct ad_slave_info ad_info; /* HUGE - better to dynamically alloc */
struct tlb_slave_info tlb_info;
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/3] net-bonding: Fix minor/cosmetic type inconsistencies
From: David Decotigny @ 2011-04-14 1:22 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel; +Cc: David Decotigny
In-Reply-To: <1302744151-12452-1-git-send-email-decot@google.com>
The __get_link_speed() function returns a u16 value which was stored
in a u32 local variable. This patch uses the return value directly,
thus fixing that minor type consistency.
The 'duplex' field in struct slave being encoded on 8 bits, to be more
consistent we use a u8 integer (instead of u16) whenever we copy it to
local variables.
Signed-off-by: David Decotigny <decot@google.com>
---
drivers/net/bonding/bond_3ad.c | 4 +---
drivers/net/bonding/bond_main.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index 494bf96..123dd60 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -716,11 +716,9 @@ static void __set_agg_ports_ready(struct aggregator *aggregator, int val)
static u32 __get_agg_bandwidth(struct aggregator *aggregator)
{
u32 bandwidth = 0;
- u32 basic_speed;
if (aggregator->num_of_ports) {
- basic_speed = __get_link_speed(aggregator->lag_ports);
- switch (basic_speed) {
+ switch (__get_link_speed(aggregator->lag_ports)) {
case AD_LINK_SPEED_BITMASK_1MBPS:
bandwidth = aggregator->num_of_ports;
break;
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8264ed7..145f9be 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3340,7 +3340,7 @@ static int bond_slave_netdev_event(unsigned long event,
slave = bond_get_slave_by_dev(bond, slave_dev);
if (slave) {
u16 old_speed = slave->speed;
- u16 old_duplex = slave->duplex;
+ u8 old_duplex = slave->duplex;
bond_update_speed_duplex(slave);
--
1.7.3.1
^ permalink raw reply related
* [PATCH 1/3] net-bonding: Fix minor sparse complaints
From: David Decotigny @ 2011-04-14 1:22 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel; +Cc: David Decotigny
This gets rid of minor sparse complaints:
drivers/net/bonding/bond_main.c:4361:4: warning: do-while statement is not a compound statement
drivers/net/bonding/bond_main.c:243:12: warning: symbol 'bond_mode_name' was not declared. Should it be static?
Signed-off-by: David Decotigny <decot@google.com>
---
drivers/net/bonding/bond_main.c | 4 ++--
drivers/net/bonding/bond_procfs.c | 2 --
drivers/net/bonding/bonding.h | 1 +
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 16d6fe9..8264ed7 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4357,9 +4357,9 @@ static u16 bond_select_queue(struct net_device *dev, struct sk_buff *skb)
u16 txq = skb_rx_queue_recorded(skb) ? skb_get_rx_queue(skb) : 0;
if (unlikely(txq >= dev->real_num_tx_queues)) {
- do
+ do {
txq -= dev->real_num_tx_queues;
- while (txq >= dev->real_num_tx_queues);
+ } while (txq >= dev->real_num_tx_queues);
}
return txq;
}
diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
index c32ff55..c97307d 100644
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -4,8 +4,6 @@
#include "bonding.h"
-extern const char *bond_mode_name(int mode);
-
static void *bond_info_seq_start(struct seq_file *seq, loff_t *pos)
__acquires(RCU)
__acquires(&bond->lock)
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 90736cb..3ca503e 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -416,6 +416,7 @@ void bond_destroy_debugfs(void);
void bond_debug_register(struct bonding *bond);
void bond_debug_unregister(struct bonding *bond);
void bond_debug_reregister(struct bonding *bond);
+const char *bond_mode_name(int mode);
struct bond_net {
struct net * net; /* Associated network namespace */
--
1.7.3.1
^ permalink raw reply related
* RE: [net-next-2.6 04/24] e1000: convert to set_phys_id
From: Jeff Kirsher @ 2011-04-14 1:18 UTC (permalink / raw)
To: Allan, Bruce W
Cc: davem@davemloft.net, stephen hemminger, netdev@vger.kernel.org,
gospo@redhat.com, bphilips@novell.com
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90018A3428DE@orsmsx509.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]
On Wed, 2011-04-13 at 18:12 -0700, Allan, Bruce W wrote:
> >-----Original Message-----
> >From:
> netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >Behalf Of Jeff Kirsher
> >Sent: Wednesday, April 13, 2011 6:02 PM
> >To: davem@davemloft.net
> >Cc: stephen hemminger; netdev@vger.kernel.org; gospo@redhat.com;
> >bphilips@novell.com; Kirsher, Jeffrey T
> >Subject: [net-next-2.6 04/24] e1000: convert to set_phys_id
> >
> >From: stephen hemminger <shemminger@vyatta.com>
> >
> >Convert to new LED control infrastucture and remove no longer
> >necessary bits.
> >
> >Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> >Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >---
> > drivers/net/e1000/e1000.h | 3 --
> > drivers/net/e1000/e1000_ethtool.c | 50
> ++++++++++++-------------------------
> > 2 files changed, 16 insertions(+), 37 deletions(-)
> >
> >diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
> >index a881dd0..f96475c 100644
> >--- a/drivers/net/e1000/e1000.h
> >+++ b/drivers/net/e1000/e1000.h
> >@@ -238,9 +238,6 @@ struct e1000_adapter {
> > struct work_struct reset_task;
> > u8 fc_autoneg;
> >
> >- struct timer_list blink_timer;
> >- unsigned long led_status;
> >-
> > /* TX */
> > struct e1000_tx_ring *tx_ring; /* One per active queue */
> > unsigned int restart_queue;
> >diff --git a/drivers/net/e1000/e1000_ethtool.c
> >b/drivers/net/e1000/e1000_ethtool.c
> >index dd70738..5c998a9 100644
> >--- a/drivers/net/e1000/e1000_ethtool.c
> >+++ b/drivers/net/e1000/e1000_ethtool.c
> >@@ -1753,46 +1753,28 @@ static int e1000_set_wol(struct net_device
> *netdev,
> >struct ethtool_wolinfo *wol)
> > return 0;
> > }
> >
> >-/* toggle LED 4 times per second = 2 "blinks" per second */
> >-#define E1000_ID_INTERVAL (HZ/4)
> >-
> >-/* bit defines for adapter->led_status */
> >-#define E1000_LED_ON 0
> >-
> >-static void e1000_led_blink_callback(unsigned long data)
> >+static int e1000_set_phys_id(struct net_device *netdev,
> >+ enum ethtool_phys_id_state state)
> > {
> >- struct e1000_adapter *adapter = (struct e1000_adapter *) data;
> >+ struct e1000_adapter *adapter = netdev_priv(netdev);
> > struct e1000_hw *hw = &adapter->hw;
> >
> >- if (test_and_change_bit(E1000_LED_ON, &adapter->led_status))
> >- e1000_led_off(hw);
> >- else
> >- e1000_led_on(hw);
> >-
> >- mod_timer(&adapter->blink_timer, jiffies + E1000_ID_INTERVAL);
> >-}
> >+ switch (state) {
> >+ case ETHTOOL_ID_ACTIVE:
> >+ e1000_setup_led(hw);
> >+ return -EINVAL;
>
> This conflicts with the patch I submitted a few hours ago - with it,
> this
> feature is broken for e1000.
Dave - I will remove this patch from my tree and send you an updated
pull request when my tree is updated.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [net-next-2.6 04/24] e1000: convert to set_phys_id
From: Allan, Bruce W @ 2011-04-14 1:12 UTC (permalink / raw)
To: Kirsher, Jeffrey T, davem@davemloft.net
Cc: stephen hemminger, netdev@vger.kernel.org, gospo@redhat.com,
bphilips@novell.com, Kirsher, Jeffrey T
In-Reply-To: <1302742940-22141-5-git-send-email-jeffrey.t.kirsher@intel.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Jeff Kirsher
>Sent: Wednesday, April 13, 2011 6:02 PM
>To: davem@davemloft.net
>Cc: stephen hemminger; netdev@vger.kernel.org; gospo@redhat.com;
>bphilips@novell.com; Kirsher, Jeffrey T
>Subject: [net-next-2.6 04/24] e1000: convert to set_phys_id
>
>From: stephen hemminger <shemminger@vyatta.com>
>
>Convert to new LED control infrastucture and remove no longer
>necessary bits.
>
>Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>Tested-by: Aaron Brown <aaron.f.brown@intel.com>
>Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>---
> drivers/net/e1000/e1000.h | 3 --
> drivers/net/e1000/e1000_ethtool.c | 50 ++++++++++++-------------------------
> 2 files changed, 16 insertions(+), 37 deletions(-)
>
>diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
>index a881dd0..f96475c 100644
>--- a/drivers/net/e1000/e1000.h
>+++ b/drivers/net/e1000/e1000.h
>@@ -238,9 +238,6 @@ struct e1000_adapter {
> struct work_struct reset_task;
> u8 fc_autoneg;
>
>- struct timer_list blink_timer;
>- unsigned long led_status;
>-
> /* TX */
> struct e1000_tx_ring *tx_ring; /* One per active queue */
> unsigned int restart_queue;
>diff --git a/drivers/net/e1000/e1000_ethtool.c
>b/drivers/net/e1000/e1000_ethtool.c
>index dd70738..5c998a9 100644
>--- a/drivers/net/e1000/e1000_ethtool.c
>+++ b/drivers/net/e1000/e1000_ethtool.c
>@@ -1753,46 +1753,28 @@ static int e1000_set_wol(struct net_device *netdev,
>struct ethtool_wolinfo *wol)
> return 0;
> }
>
>-/* toggle LED 4 times per second = 2 "blinks" per second */
>-#define E1000_ID_INTERVAL (HZ/4)
>-
>-/* bit defines for adapter->led_status */
>-#define E1000_LED_ON 0
>-
>-static void e1000_led_blink_callback(unsigned long data)
>+static int e1000_set_phys_id(struct net_device *netdev,
>+ enum ethtool_phys_id_state state)
> {
>- struct e1000_adapter *adapter = (struct e1000_adapter *) data;
>+ struct e1000_adapter *adapter = netdev_priv(netdev);
> struct e1000_hw *hw = &adapter->hw;
>
>- if (test_and_change_bit(E1000_LED_ON, &adapter->led_status))
>- e1000_led_off(hw);
>- else
>- e1000_led_on(hw);
>-
>- mod_timer(&adapter->blink_timer, jiffies + E1000_ID_INTERVAL);
>-}
>+ switch (state) {
>+ case ETHTOOL_ID_ACTIVE:
>+ e1000_setup_led(hw);
>+ return -EINVAL;
This conflicts with the patch I submitted a few hours ago - with it, this
feature is broken for e1000.
>
>-static int e1000_phys_id(struct net_device *netdev, u32 data)
>-{
>- struct e1000_adapter *adapter = netdev_priv(netdev);
>- struct e1000_hw *hw = &adapter->hw;
>+ case ETHTOOL_ID_ON:
>+ e1000_led_on(hw);
>+ break;
>
>- if (!data)
>- data = INT_MAX;
>+ case ETHTOOL_ID_OFF:
>+ e1000_led_off(hw);
>+ break;
>
>- if (!adapter->blink_timer.function) {
>- init_timer(&adapter->blink_timer);
>- adapter->blink_timer.function = e1000_led_blink_callback;
>- adapter->blink_timer.data = (unsigned long)adapter;
>+ case ETHTOOL_ID_INACTIVE:
>+ e1000_cleanup_led(hw);
> }
>- e1000_setup_led(hw);
>- mod_timer(&adapter->blink_timer, jiffies);
>- msleep_interruptible(data * 1000);
>- del_timer_sync(&adapter->blink_timer);
>-
>- e1000_led_off(hw);
>- clear_bit(E1000_LED_ON, &adapter->led_status);
>- e1000_cleanup_led(hw);
>
> return 0;
> }
>@@ -1929,7 +1911,7 @@ static const struct ethtool_ops e1000_ethtool_ops = {
> .set_tso = e1000_set_tso,
> .self_test = e1000_diag_test,
> .get_strings = e1000_get_strings,
>- .phys_id = e1000_phys_id,
>+ .set_phys_id = e1000_set_phys_id,
> .get_ethtool_stats = e1000_get_ethtool_stats,
> .get_sset_count = e1000_get_sset_count,
> .get_coalesce = e1000_get_coalesce,
>--
>1.7.4.2
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-next-2.6 24/24] ixgbe: DCB, X540 devices do not respond to pause frames
From: Jeff Kirsher @ 2011-04-14 1:02 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1302742940-22141-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
DCB enabled X540 devices are not responding to pause frames
due to a missing register set that was added for these
devices that did not exist in other devices.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_dcb_82599.c | 9 +++++++--
drivers/net/ixgbe/ixgbe_type.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_dcb_82599.c b/drivers/net/ixgbe/ixgbe_dcb_82599.c
index 865ddd8..d50cf78 100644
--- a/drivers/net/ixgbe/ixgbe_dcb_82599.c
+++ b/drivers/net/ixgbe/ixgbe_dcb_82599.c
@@ -301,12 +301,17 @@ s32 ixgbe_dcb_config_pfc_82599(struct ixgbe_hw *hw, u8 pfc_en)
IXGBE_WRITE_REG(hw, IXGBE_FCCFG, reg);
/*
* Enable Receive PFC
- * We will always honor XOFF frames we receive when
- * we are in PFC mode.
+ * 82599 will always honor XOFF frames we receive when
+ * we are in PFC mode however X540 only honors enabled
+ * traffic classes.
*/
reg = IXGBE_READ_REG(hw, IXGBE_MFLCN);
reg &= ~IXGBE_MFLCN_RFCE;
reg |= IXGBE_MFLCN_RPFCE | IXGBE_MFLCN_DPF;
+
+ if (hw->mac.type == ixgbe_mac_X540)
+ reg |= pfc_en << IXGBE_MFLCN_RPFCE_SHIFT;
+
IXGBE_WRITE_REG(hw, IXGBE_MFLCN, reg);
} else {
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index 7d0b37d..f5bec97 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -1728,6 +1728,8 @@
#define IXGBE_MFLCN_RPFCE 0x00000004 /* Receive Priority FC Enable */
#define IXGBE_MFLCN_RFCE 0x00000008 /* Receive FC Enable */
+#define IXGBE_MFLCN_RPFCE_SHIFT 4
+
/* Multiple Receive Queue Control */
#define IXGBE_MRQC_RSSEN 0x00000001 /* RSS Enable */
#define IXGBE_MRQC_MRQE_MASK 0xF /* Bits 3:0 */
--
1.7.4.2
^ permalink raw reply related
* [net-next-2.6 22/24] ixgbe: make device_caps() generic
From: Jeff Kirsher @ 2011-04-14 1:02 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1302742940-22141-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
x540 has the same device capability word in the EEPROM as 82599.
This patch renames ixgbe_get_device_caps_82599 to
ixgbe_get_device_caps_generic, moves it to ixgbe_common.h and
sets up the function pointer for x540.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Evan Swanson <evan.swanson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 17 +----------------
drivers/net/ixgbe/ixgbe_common.c | 15 +++++++++++++++
drivers/net/ixgbe/ixgbe_common.h | 1 +
drivers/net/ixgbe/ixgbe_x540.c | 2 +-
4 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index 63b4da6..e432305 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -1973,21 +1973,6 @@ static s32 ixgbe_enable_rx_dma_82599(struct ixgbe_hw *hw, u32 regval)
}
/**
- * ixgbe_get_device_caps_82599 - Get additional device capabilities
- * @hw: pointer to hardware structure
- * @device_caps: the EEPROM word with the extra device capabilities
- *
- * This function will read the EEPROM location for the device capabilities,
- * and return the word through device_caps.
- **/
-static s32 ixgbe_get_device_caps_82599(struct ixgbe_hw *hw, u16 *device_caps)
-{
- hw->eeprom.ops.read(hw, IXGBE_DEVICE_CAPS, device_caps);
-
- return 0;
-}
-
-/**
* ixgbe_verify_fw_version_82599 - verify fw version for 82599
* @hw: pointer to hardware structure
*
@@ -2087,7 +2072,7 @@ static struct ixgbe_mac_operations mac_ops_82599 = {
.enable_rx_dma = &ixgbe_enable_rx_dma_82599,
.get_mac_addr = &ixgbe_get_mac_addr_generic,
.get_san_mac_addr = &ixgbe_get_san_mac_addr_generic,
- .get_device_caps = &ixgbe_get_device_caps_82599,
+ .get_device_caps = &ixgbe_get_device_caps_generic,
.get_wwn_prefix = &ixgbe_get_wwn_prefix_generic,
.stop_adapter = &ixgbe_stop_adapter_generic,
.get_bus_info = &ixgbe_get_bus_info_generic,
diff --git a/drivers/net/ixgbe/ixgbe_common.c b/drivers/net/ixgbe/ixgbe_common.c
index fc31e02..cb2e8e1 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -2968,3 +2968,18 @@ void ixgbe_set_vlan_anti_spoofing(struct ixgbe_hw *hw, bool enable, int vf)
pfvfspoof &= ~(1 << vf_target_shift);
IXGBE_WRITE_REG(hw, IXGBE_PFVFSPOOF(vf_target_reg), pfvfspoof);
}
+
+/**
+ * ixgbe_get_device_caps_generic - Get additional device capabilities
+ * @hw: pointer to hardware structure
+ * @device_caps: the EEPROM word with the extra device capabilities
+ *
+ * This function will read the EEPROM location for the device capabilities,
+ * and return the word through device_caps.
+ **/
+s32 ixgbe_get_device_caps_generic(struct ixgbe_hw *hw, u16 *device_caps)
+{
+ hw->eeprom.ops.read(hw, IXGBE_DEVICE_CAPS, device_caps);
+
+ return 0;
+}
diff --git a/drivers/net/ixgbe/ixgbe_common.h b/drivers/net/ixgbe/ixgbe_common.h
index e18dc13..e850adb 100644
--- a/drivers/net/ixgbe/ixgbe_common.h
+++ b/drivers/net/ixgbe/ixgbe_common.h
@@ -90,6 +90,7 @@ s32 ixgbe_blink_led_start_generic(struct ixgbe_hw *hw, u32 index);
s32 ixgbe_blink_led_stop_generic(struct ixgbe_hw *hw, u32 index);
void ixgbe_set_mac_anti_spoofing(struct ixgbe_hw *hw, bool enable, int pf);
void ixgbe_set_vlan_anti_spoofing(struct ixgbe_hw *hw, bool enable, int vf);
+s32 ixgbe_get_device_caps_generic(struct ixgbe_hw *hw, u16 *device_caps);
#define IXGBE_WRITE_REG(a, reg, value) writel((value), ((a)->hw_addr + (reg)))
diff --git a/drivers/net/ixgbe/ixgbe_x540.c b/drivers/net/ixgbe/ixgbe_x540.c
index 5433f15..05f8e9c 100644
--- a/drivers/net/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ixgbe/ixgbe_x540.c
@@ -754,7 +754,7 @@ static struct ixgbe_mac_operations mac_ops_X540 = {
.enable_rx_dma = &ixgbe_enable_rx_dma_generic,
.get_mac_addr = &ixgbe_get_mac_addr_generic,
.get_san_mac_addr = &ixgbe_get_san_mac_addr_generic,
- .get_device_caps = NULL,
+ .get_device_caps = &ixgbe_get_device_caps_generic,
.get_wwn_prefix = &ixgbe_get_wwn_prefix_generic,
.stop_adapter = &ixgbe_stop_adapter_generic,
.get_bus_info = &ixgbe_get_bus_info_generic,
--
1.7.4.2
^ permalink raw reply related
* [net-next-2.6 23/24] ixgbe: DCB, misallocated packet buffer size with X540 device
From: Jeff Kirsher @ 2011-04-14 1:02 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1302742940-22141-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
The X540 device has a smaller packet buffer but the DCB configuration
never took this into account. Under stress this can result in the DMA
engine hanging and TX Unit hang occurring to reset the device. This
patch reworks the packet buffer allocation routine used for DCB on
82599 and X540 devices to account for RX packet buffer sizes.
This fixes the immediate hang. We should consolidate the various
hardware specific routines for configuring features into a single
routine. This will make it much harder to miss feature cases like
this.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Tested-by: Evan Swanson <evan.swanson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82598.c | 3 ++
drivers/net/ixgbe/ixgbe_82599.c | 2 +
drivers/net/ixgbe/ixgbe_dcb_82599.c | 68 +++++++++++++++++++++-------------
drivers/net/ixgbe/ixgbe_dcb_82599.h | 2 +
drivers/net/ixgbe/ixgbe_type.h | 1 +
drivers/net/ixgbe/ixgbe_x540.c | 3 +-
6 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82598.c b/drivers/net/ixgbe/ixgbe_82598.c
index af4054a..7a64f50 100644
--- a/drivers/net/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ixgbe/ixgbe_82598.c
@@ -37,6 +37,7 @@
#define IXGBE_82598_RAR_ENTRIES 16
#define IXGBE_82598_MC_TBL_SIZE 128
#define IXGBE_82598_VFT_TBL_SIZE 128
+#define IXGBE_82598_RX_PB_SIZE 512
static s32 ixgbe_setup_copper_link_82598(struct ixgbe_hw *hw,
ixgbe_link_speed speed,
@@ -224,6 +225,8 @@ static s32 ixgbe_start_hw_82598(struct ixgbe_hw *hw)
IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
}
+ hw->mac.rx_pb_size = IXGBE_82598_RX_PB_SIZE;
+
/* set the completion timeout for interface */
if (ret_val == 0)
ixgbe_set_pcie_completion_timeout(hw);
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index e432305..b341ed8 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -38,6 +38,7 @@
#define IXGBE_82599_RAR_ENTRIES 128
#define IXGBE_82599_MC_TBL_SIZE 128
#define IXGBE_82599_VFT_TBL_SIZE 128
+#define IXGBE_82599_RX_PB_SIZE 512
static void ixgbe_disable_tx_laser_multispeed_fiber(struct ixgbe_hw *hw);
static void ixgbe_enable_tx_laser_multispeed_fiber(struct ixgbe_hw *hw);
@@ -1765,6 +1766,7 @@ static s32 ixgbe_start_hw_82599(struct ixgbe_hw *hw)
/* We need to run link autotry after the driver loads */
hw->mac.autotry_restart = true;
+ hw->mac.rx_pb_size = IXGBE_82599_RX_PB_SIZE;
if (ret_val == 0)
ret_val = ixgbe_verify_fw_version_82599(hw);
diff --git a/drivers/net/ixgbe/ixgbe_dcb_82599.c b/drivers/net/ixgbe/ixgbe_dcb_82599.c
index 025af8c..865ddd8 100644
--- a/drivers/net/ixgbe/ixgbe_dcb_82599.c
+++ b/drivers/net/ixgbe/ixgbe_dcb_82599.c
@@ -39,36 +39,52 @@
*/
static s32 ixgbe_dcb_config_packet_buffers_82599(struct ixgbe_hw *hw, u8 rx_pba)
{
- s32 ret_val = 0;
- u32 value = IXGBE_RXPBSIZE_64KB;
+ int num_tcs = IXGBE_MAX_PACKET_BUFFERS;
+ u32 rx_pb_size = hw->mac.rx_pb_size << IXGBE_RXPBSIZE_SHIFT;
+ u32 rxpktsize;
+ u32 txpktsize;
+ u32 txpbthresh;
u8 i = 0;
- /* Setup Rx packet buffer sizes */
- switch (rx_pba) {
- case pba_80_48:
- /* Setup the first four at 80KB */
- value = IXGBE_RXPBSIZE_80KB;
- for (; i < 4; i++)
- IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), value);
- /* Setup the last four at 48KB...don't re-init i */
- value = IXGBE_RXPBSIZE_48KB;
- /* Fall Through */
- case pba_equal:
- default:
- for (; i < IXGBE_MAX_PACKET_BUFFERS; i++)
- IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), value);
-
- /* Setup Tx packet buffer sizes */
- for (i = 0; i < IXGBE_MAX_PACKET_BUFFERS; i++) {
- IXGBE_WRITE_REG(hw, IXGBE_TXPBSIZE(i),
- IXGBE_TXPBSIZE_20KB);
- IXGBE_WRITE_REG(hw, IXGBE_TXPBTHRESH(i),
- IXGBE_TXPBTHRESH_DCB);
- }
- break;
+ /*
+ * This really means configure the first half of the TCs
+ * (Traffic Classes) to use 5/8 of the Rx packet buffer
+ * space. To determine the size of the buffer for each TC,
+ * we are multiplying the average size by 5/4 and applying
+ * it to half of the traffic classes.
+ */
+ if (rx_pba == pba_80_48) {
+ rxpktsize = (rx_pb_size * 5) / (num_tcs * 4);
+ rx_pb_size -= rxpktsize * (num_tcs / 2);
+ for (; i < (num_tcs / 2); i++)
+ IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), rxpktsize);
+ }
+
+ /* Divide the remaining Rx packet buffer evenly among the TCs */
+ rxpktsize = rx_pb_size / (num_tcs - i);
+ for (; i < num_tcs; i++)
+ IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), rxpktsize);
+
+ /*
+ * Setup Tx packet buffer and threshold equally for all TCs
+ * TXPBTHRESH register is set in K so divide by 1024 and subtract
+ * 10 since the largest packet we support is just over 9K.
+ */
+ txpktsize = IXGBE_TXPBSIZE_MAX / num_tcs;
+ txpbthresh = (txpktsize / 1024) - IXGBE_TXPKT_SIZE_MAX;
+ for (i = 0; i < num_tcs; i++) {
+ IXGBE_WRITE_REG(hw, IXGBE_TXPBSIZE(i), txpktsize);
+ IXGBE_WRITE_REG(hw, IXGBE_TXPBTHRESH(i), txpbthresh);
}
- return ret_val;
+ /* Clear unused TCs, if any, to zero buffer size*/
+ for (; i < MAX_TRAFFIC_CLASS; i++) {
+ IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), 0);
+ IXGBE_WRITE_REG(hw, IXGBE_TXPBSIZE(i), 0);
+ IXGBE_WRITE_REG(hw, IXGBE_TXPBTHRESH(i), 0);
+ }
+
+ return 0;
}
/**
diff --git a/drivers/net/ixgbe/ixgbe_dcb_82599.h b/drivers/net/ixgbe/ixgbe_dcb_82599.h
index 148fd8b..2de71a5 100644
--- a/drivers/net/ixgbe/ixgbe_dcb_82599.h
+++ b/drivers/net/ixgbe/ixgbe_dcb_82599.h
@@ -92,8 +92,10 @@
#define IXGBE_RXPBSIZE_64KB 0x00010000 /* 64KB Packet Buffer */
#define IXGBE_RXPBSIZE_80KB 0x00014000 /* 80KB Packet Buffer */
#define IXGBE_RXPBSIZE_128KB 0x00020000 /* 128KB Packet Buffer */
+#define IXGBE_TXPBSIZE_MAX 0x00028000 /* 160KB Packet Buffer*/
#define IXGBE_TXPBTHRESH_DCB 0xA /* THRESH value for DCB mode */
+#define IXGBE_TXPKT_SIZE_MAX 0xA /* Max Tx Packet size */
/* SECTXMINIFG DCB */
#define IXGBE_SECTX_DCB 0x00001F00 /* DCB TX Buffer IFG */
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index 15580d6..7d0b37d 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -2606,6 +2606,7 @@ struct ixgbe_mac_info {
u32 vft_size;
u32 num_rar_entries;
u32 rar_highwater;
+ u32 rx_pb_size;
u32 max_tx_queues;
u32 max_rx_queues;
u32 max_msix_vectors;
diff --git a/drivers/net/ixgbe/ixgbe_x540.c b/drivers/net/ixgbe/ixgbe_x540.c
index 05f8e9c..932394f 100644
--- a/drivers/net/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ixgbe/ixgbe_x540.c
@@ -37,6 +37,7 @@
#define IXGBE_X540_RAR_ENTRIES 128
#define IXGBE_X540_MC_TBL_SIZE 128
#define IXGBE_X540_VFT_TBL_SIZE 128
+#define IXGBE_X540_RX_PB_SIZE 384
static s32 ixgbe_update_flash_X540(struct ixgbe_hw *hw);
static s32 ixgbe_poll_flash_update_done_X540(struct ixgbe_hw *hw);
@@ -242,7 +243,7 @@ static s32 ixgbe_start_hw_X540(struct ixgbe_hw *hw)
goto out;
ret_val = ixgbe_start_hw_gen2(hw);
-
+ hw->mac.rx_pb_size = IXGBE_X540_RX_PB_SIZE;
out:
return ret_val;
}
--
1.7.4.2
^ permalink raw reply related
* [net-next-2.6 21/24] ixgbe: explicitly disable 100H for x540
From: Jeff Kirsher @ 2011-04-14 1:02 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1302742940-22141-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
100H is not supported on this HW, but the bit is set on the PHY.
This can result in link at 100F when advertising only 1000F.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Evan Swanson <evan.swanson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_phy.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_phy.c b/drivers/net/ixgbe/ixgbe_phy.c
index 31cc29e..fd381ea 100644
--- a/drivers/net/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ixgbe/ixgbe_phy.c
@@ -449,7 +449,8 @@ s32 ixgbe_setup_phy_link_generic(struct ixgbe_hw *hw)
MDIO_MMD_AN,
&autoneg_reg);
- autoneg_reg &= ~ADVERTISE_100FULL;
+ autoneg_reg &= ~(ADVERTISE_100FULL |
+ ADVERTISE_100HALF);
if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_100_FULL)
autoneg_reg |= ADVERTISE_100FULL;
--
1.7.4.2
^ permalink raw reply related
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