headers
Matt Carlson | 1 Sep 2011 04:02
Favicon

[PATCH] ethtool: Uncook tg3 regdump output

tg3 devices have changed a lot since the bcm5700 days.  Register blocks
have been added, removed and redefined.  The existing tg3 register dump
code has not kept up.

This patch changes the tg3_dump_regs() function to be more simplistic.
Rather than attempting to locate where meaningful data is, it will
instead print the registers as 32-bit values, omitting all registers
that have a value of zero.  By performing the output this way, we hope
to future-proof the interface.

Signed-off-by: Matt Carlson <mcarlson <at> broadcom.com>
---
 tg3.c |   30 +++++++-----------------------
 1 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/tg3.c b/tg3.c
index 1ce07a8..4868504 100644
--- a/tg3.c
+++ b/tg3.c
 <at>  <at>  -26,32 +26,16  <at>  <at>  tg3_dump_eeprom(struct ethtool_drvinfo *info, struct ethtool_eeprom *ee)
 int
 tg3_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
 {
-	int i, j;
-	int reg_boundaries[] = { 0x015c, 0x0200, 0x0400, 0x0400, 0x08f0, 0x0c00,
-	       			 0x0ce0, 0x1000, 0x1004, 0x1400, 0x1480, 0x1800,
-				 0x1848, 0x1c00, 0x1c04, 0x2000, 0x225c, 0x2400,
-				 0x24c4, 0x2800, 0x2804, 0x2c00, 0x2c20, 0x3000,
-				 0x3014, 0x3400, 0x3408, 0x3800, 0x3808, 0x3c00,
-				 0x3d00, 0x4000, 0x4010, 0x4400, 0x4458, 0x4800,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joe Perches | 1 Sep 2011 01:59

Re: [PATCH net-next 8/8] tg3: Code movement

On Wed, 2011-08-31 at 14:44 -0700, Matt Carlson wrote:
> This patch just moves some code around for better organization.
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
[]
>  <at>  <at>  -15541,7 +15542,7  <at>  <at>  static int __devinit tg3_init_one(struct pci_dev *pdev,
>  		tnapi->tx_pending = TG3_DEF_TX_RING_PENDING;
>  
>  		tnapi->int_mbox = intmbx;
> -		if (i < 4)
> +		if (i <= 4)
>  			intmbx += 0x8;
>  		else
>  			intmbx += 0x4;

Not just code movement.
Permalink | Reply | 0 comments |
headers
David Lamparter | 1 Sep 2011 02:10
Gravatar

Re: RFC - should network devices trim frames > soft mtu

On Wed, Aug 31, 2011 at 03:27:31PM -0700, Michael Chan wrote:
> > This means that for non-VLAN tagged frames, the device drops received
> > packets if the length is greater than the MTU.  I don't see that in
> > other devices. What is the correct method? IMHO the bnx2 driver is
> > wrong here and if the policy is desired it should be enforced at
> > the next level (netif_receive_skb).  Hardcoding a protocol value is
> > kind of a giveaway that something is fishy.
> > 
> 
> I guess the reasoning is that we program the RX MTU in our chip to
> automatically discard packets bigger than the RX MTU and count them as
> over-size packets.  We add 4 bytes to the RX MTU to account for the VLAN
> tag which may be stripped or not stripped by the chip depending on
> settings.  The extra 4 bytes in the RX MTU setting will allow over-size
> packets by up to 4 bytes to get through.
> 
> I agree we should move this to the next level.

802.3ac allows both unconditionally raising the MTU to 1522 as well as
checking the protocol and only accepting 802.1Q frames at 1522 while
restricting everything else to 1518.

802.3as raises the bar to 2000 bytes, but explicitly states that the
actual payload - without encapsulation headers from 802.1Q, 1ad, 1ah,
MPLS & co. - should keep the 1500 byte limit.

I think the sensible approach would be to move the MTU check as close
as possible to the border between ethernet and the upper layer
protocols, i.e. the driver shouldn't check this at all and try to tx/rx
as much as the hardware supports. This is needed for QinQ, 802.1ah & co.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Lamparter | 1 Sep 2011 02:16
Gravatar

Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups

On Wed, Aug 31, 2011 at 01:49:04PM -0700, Stephen Hemminger wrote:
> On Wed, 31 Aug 2011 21:41:26 +0100
> Nick Carter <ncarter100 <at> gmail.com> wrote:
> 
> > On 15 August 2011 19:25, Stephen Hemminger
> > <shemminger <at> linux-foundation.org> wrote:
> > > On Mon, 15 Aug 2011 17:27:12 +0100
> > > Nick Carter <ncarter100 <at> gmail.com> wrote:
> > >
> > >> On 28 July 2011 16:41, Stephen Hemminger
> > >> <shemminger <at> linux-foundation.org> wrote:
> > >> > On Wed, 27 Jul 2011 13:17:15 +0200
> > >> > David Lamparter <equinox <at> diac24.net> wrote:
> > >> >
> > >> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > >> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > >> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > >> >> > > > On 12 July 2011 12:36, David Lamparter <equinox <at> diac24.net> wrote:
> > >> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > >> >> > > > >> I am still undecided on this. Understand the need, but don't like idea
> > >> >> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
> > >> >> > > > >> has any input.
> > >> >> > > > >
> > >> >> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
> > >> >> > > > > is 0, which just keeps the old behaviour.
> > >> >> >
> > >> >> > P.S.: I'd like to once more stress this. In my opinion the patch should
> > >> >> > be merged because it provides desireable functionality at a small cost
> > >> >> > (one test, one knob) and __does not change any default behaviour__.
> > >> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
System Administrator | 1 Sep 2011 03:24
Favicon

Warning Increase Your Mailbox Quota Now


Your Mail Quota Has Exceeded The Set Quota/Limit. You Are Currently
Running On 23GB Due To Hidden Files And Folder On Your Mailbox,
you may not be able to receive or send new mails until you re-validate.

Please Click the Link Below To Validate Your Mailbox And Increase Your Quota.

http://buzurl.com/bc74

Failure To Validate Your Quota May Result In Loss Of Important Information
In Your Mailbox Or Cause Limited Access To It.

Mail Quota alert -Error Code #1997142DDE
System Administrator
Permalink | Reply | 0 comments |
headers
Adrian Chadd | 1 Sep 2011 04:44
Picon
Favicon

Re: BQL crap and wireless

I think there's enough interesting ideas here to keep people busy
experimenting for a while.

I'm going to refrain from chiming in further until I've got the
FreeBSD 11n TX code at the point where I can begin tinkering with
adaptive queue management in the driver and rate control layer.

Thanks for the pointers and interesting discussion,

Adrian
Permalink | Reply | 0 comments |
headers
Glauber Costa | 1 Sep 2011 04:43
Favicon

[RFMC] per-container tcp buffer limitation

Hello People,

[ For the ones in linux-mm that are receiving this for the first time,
   this is a follow up of
   http://thread.gmane.org/gmane.linux.kernel.containers/21295 ]

Here is a new, a bit more mature version of my previous RFC. Now I 
Request For More Comments from you guys in this new version of the patch.

Highlights:

* Although I do intend to experiment with more scenarios (suggestions 
welcome), there does not seem to be a (huge) performance hit with this 
patch applied, at least in a basic latency benchmark. That indicates 
that even if we can demonstrate a performance hit, it won't be too hard 
to optimize it away (famous last words?)

Since the patch touches both rcv and snd sides, I benchmarked it with 
netperf against localhost. Command line: netperf -t TCP_RR -H localhost.

Without the patch
=================

Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

16384  87380  1        1       10.00    26996.35
16384  87380
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Hutchings | 1 Sep 2011 05:55
Picon

Re: [linux-firmware v3 1/2] rtl_nic: update firmware for RTL8111E-VL

On Wed, 2011-08-31 at 18:35 +0100, Hayes Wang wrote:
> Updated firmware with stability fixes.
> Version: 0.0.2
> 
> Signed-off-by: Hayes Wang <hayeswang <at> realtek.com>
> ---
>  WHENCE                |    2 +-
>  rtl_nic/rtl8168e-3.fw |  Bin 2804 -> 3552 bytes
>  2 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/WHENCE b/WHENCE
> index a47b307..eb7bdfd 100644
> --- a/WHENCE
> +++ b/WHENCE
>  <at>  <at>  -1657,7 +1657,7  <at>  <at>  File: rtl_nic/rtl8168d-2.fw
>  File: rtl_nic/rtl8105e-1.fw
>  File: rtl_nic/rtl8168e-1.fw
>  File: rtl_nic/rtl8168e-2.fw
> -File: rtl_nic/rtl8168e-3.fw
> +File: rtl_nic/rtl8168e-3.fw (version: 0.0.2)
[...]

Like I said before, the version belongs on a separate line:

File: rtl_nic/rtl8168e-3.fw
Version: 0.0.2

Ben.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jiri Pirko | 1 Sep 2011 07:44
Picon
Favicon

Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs

Wed, Aug 31, 2011 at 10:48:22PM CEST, greearb <at> candelatech.com wrote:
>On 08/31/2011 01:31 PM, Nicolas de Pesloüan wrote:
>>Le 31/08/2011 22:12, Ben Hutchings a écrit :
>>>On Wed, 2011-08-31 at 22:03 +0200, Nicolas de Pesloüan wrote:
>>>>Le 31/08/2011 10:45, Jiri Pirko a écrit :
>>>>
>>>>>>>>Do you expect drivers using implementation different than just calling
>>>>>>>>netif_carrier_on/off? Or is it supposed to also e.g. power down PHYs?
>>>>>>>Yes, generally it can be used also for en/disable phy, for testing
>>>>>>>purposes if hw and driver would support it.
>>>>>>
>>>>>>I'd like to see this working for GRE tunnel devices (for keepalive
>>>>>>daemon to be able to indicate to routing daemons whether tunnel is
>>>>>>really working) - implementation would be identical to dummy's case.
>>>>>>Should I prepare a patch or can I leave it to you?
>>>>>
>>>>>Ok, I can include it to this patchset (I'm going to repost first patch
>>>>>anyway)
>>>>
>>>>Can't we assume that the dummy's case is the default behavior and
>>>>register this default
>>>>ndo_change_carrier callback for every device ?
>>>
>>>You have got to be joking. No device driver that has real link
>>>monitoring should use this implementation.
>>
>>Well, why not? Arguably, this is probably not the feature one would use every day, but...
>>
>>Testing a cluster reaction to a link down event would be easier if one doesn't need to unplug the cable for
the test. I understand that one can turn off the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jiri Pirko | 1 Sep 2011 07:46
Picon
Favicon

Re: [patch net-next-2.6 1/2] net: allow to change carrier via sysfs

Wed, Aug 31, 2011 at 11:40:23PM CEST, shemminger <at> vyatta.com wrote:
>On Wed, 31 Aug 2011 22:36:45 +0100
>Ben Hutchings <bhutchings <at> solarflare.com> wrote:
>
>> On Wed, 2011-08-31 at 13:48 -0700, Ben Greear wrote:
>> > On 08/31/2011 01:31 PM, Nicolas de Pesloüan wrote:
>> > > Le 31/08/2011 22:12, Ben Hutchings a écrit :
>> > >> On Wed, 2011-08-31 at 22:03 +0200, Nicolas de Pesloüan wrote:
>> > >>> Le 31/08/2011 10:45, Jiri Pirko a écrit :
>> > >>>
>> > >>>>>>> Do you expect drivers using implementation different than just calling
>> > >>>>>>> netif_carrier_on/off? Or is it supposed to also e.g. power down PHYs?
>> > >>>>>> Yes, generally it can be used also for en/disable phy, for testing
>> > >>>>>> purposes if hw and driver would support it.
>> > >>>>>
>> > >>>>> I'd like to see this working for GRE tunnel devices (for keepalive
>> > >>>>> daemon to be able to indicate to routing daemons whether tunnel is
>> > >>>>> really working) - implementation would be identical to dummy's case.
>> > >>>>> Should I prepare a patch or can I leave it to you?
>> > >>>>
>> > >>>> Ok, I can include it to this patchset (I'm going to repost first patch
>> > >>>> anyway)
>> > >>>
>> > >>> Can't we assume that the dummy's case is the default behavior and
>> > >>> register this default
>> > >>> ndo_change_carrier callback for every device ?
>> > >>
>> > >> You have got to be joking. No device driver that has real link
>> > >> monitoring should use this implementation.
>> > >
(Continue reading)

Permalink | Reply | 0 comments |

Gmane