* Re: [PATCH 2/3] NET: fix phy init for Asix AX88178 USB (GigE)
From: David Miller @ 2011-10-04 20:26 UTC (permalink / raw)
To: grundler; +Cc: netdev, linux-kernel, allan, freddy
In-Reply-To: <1317758118-24052-2-git-send-email-grundler@chromium.org>
From: Grant Grundler <grundler@chromium.org>
Date: Tue, 4 Oct 2011 12:55:17 -0700
> Asix provided this patch and I've confirmed "Plugable USB2-E1000" and
> "Shenzhen Winstars NWU220G" USB dongles can get a link and TX/RX data.
>
> Signed-off-by: "Freddy Xin" <freddy@asix.com.tw>
> Signed-off-by: Grant Grundler <grundler@chromium.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 3/3] NET: white space/coding style cleanup of asix driver
From: David Miller @ 2011-10-04 20:26 UTC (permalink / raw)
To: grundler; +Cc: netdev, linux-kernel, allan
In-Reply-To: <1317758118-24052-3-git-send-email-grundler@chromium.org>
From: Grant Grundler <grundler@chromium.org>
Date: Tue, 4 Oct 2011 12:55:18 -0700
> check patch was complaining...mostly replaced:
> if ((ret = asix_foo(xx)) < 0) ...
> with
> ret = asix_foo(xx);
> if (ret < 0) ...
>
> Signed-off-by: Grant Grundler <grundler@chromium.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Thadeu Lima de Souza Cascardo @ 2011-10-04 20:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Yevgeny Petrilin, netdev@vger.kernel.org, Eli Cohen,
eli@dev.mellanox.co.il, linuxppc-dev
In-Reply-To: <1317708132.29415.213.camel@pasglop>
On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
>
> .../...
>
> > > Can you also send me the output of ethtool -i?
> > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > >
> > > Yevgeny
> >
> > Hello, Yevgeny.
> >
> > You will find the output of ethtool -i below.
> >
> > I am copying Ben and powerpc list, in case this is an issue with Power
> > processors. They can provide us some more insight into this.
>
> May I get some background please ? :-)
>
> I'm not aware of a specific issue with write combining but I'd need to
> know more about what you are doing and the code to do it to comment on
> whether it should work or not.
>
> Cheers,
> Ben.
>
>
Hello, Ben.
Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
added blue frame support, that does not require writing to the device
memory to indicate a new packet (the doorbell register as it is called).
Well, the ring is getting full with no interrupt or packets transmitted.
I simply added a write to the doorbell register and it works for me.
Yevgeny says this is not the right fix, claiming there is a problem with
write combining on POWER. The code uses memory barriers, so I don't know
why there is any problem.
I am posting the code here to show better what the situation is.
Yevgeny can tell more about the device and the driver.
The code below is the driver as of now, including a diff with what I
changed and had resulted OK for me. Before the blue frame support, the
only code executed was the else part. I can't tell much what the device
should be seeing and doing after the blue frame part of the code is
executed. But it does send the packet if I write to the doorbell
register.
Yevgeny, can you tell us what the device should be doing and why you
think this is a problem on POWER? Is it possible that this is simply a
problem with the firmware version?
Thanks,
Cascardo.
---
if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
!vlan_tag) {
*(u32 *) (&tx_desc->ctrl.vlan_tag) |=
ring->doorbell_qpn;
op_own |= htonl((bf_index & 0xffff) << 8);
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
wmb();
tx_desc->ctrl.owner_opcode = op_own;
wmb();
mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
long *) &tx_desc->ctrl,
desc_size);
wmb();
ring->bf.offset ^= ring->bf.buf_size;
} else {
/* Ensure new descirptor hits memory
* before setting ownership of this descriptor to HW */
wmb();
tx_desc->ctrl.owner_opcode = op_own;
- wmb();
- writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
}
+ wmb();
+ writel(ring->doorbell_qpn, ring->bf.uar->map +
MLX4_SEND_DOORBELL);
+
---
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Stephen Hemminger @ 2011-10-04 21:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: Kevin Wilson, netdev
In-Reply-To: <m27h4klmls.fsf@firstfloor.org>
On Tue, 04 Oct 2011 09:58:55 -0700
Andi Kleen <andi@firstfloor.org> wrote:
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
> > This adds a new 'br' command which is the bridging equivalent of
> > the ip command. More of a demo of how to use netlink and bridging
> > at this point.
>
> Please name it "bridge", not "br"
>
> -Andi
Ok, but it breaks the existing pattern.
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Stephen Hemminger @ 2011-10-04 21:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Kevin Wilson, netdev
In-Reply-To: <1317747490.2751.4.camel@bwh-desktop>
On Tue, 04 Oct 2011 17:58:10 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Tue, 2011-10-04 at 09:34 -0700, Stephen Hemminger wrote:
> > This adds a new 'br' command which is the bridging equivalent of
> > the ip command. More of a demo of how to use netlink and bridging
> > at this point.
> [...]
>
> This command name is already in use:
> http://packages.debian.org/sid/bottlerocket
Damn name squatters.
^ permalink raw reply
* Application brokne due to XFRMA_ALG_AUTH_TRUNC
From: Eduardo Panisset @ 2011-10-04 21:08 UTC (permalink / raw)
To: netdev
Hi All,
I have an application compiled against kernel 2.6.32 and which is
using XFRMA_MARK (value 20).
However the same aplication does not work anymore on kernel 2.6.38.8
due to XFRMA_MARK has now the value 21 because of a new attribute
XFRMA_ALG_AUTH_TRUNC inserted before it in the file linux/xfrm.h.
Now the only solution would be recompiling this application. Is
correct introducing a new parameter in the middle of an existing enum
in the kernel headers ?
Rgds,
Eduardo Panisset.
^ permalink raw reply
* Re: [PATCH 1/2] fix lockdep warning
From: Simon Horman @ 2011-10-04 21:14 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: ja, wensong, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1317639399-4522-1-git-send-email-hans.schillstrom@ericsson.com>
On Mon, Oct 03, 2011 at 12:56:38PM +0200, Hans Schillstrom wrote:
> From: Hans Schillstrom <hans@schillstrom.com>
>
> rs_lock needs a key to make lock dep happy.
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Hi Julian,
can I get an Ack or otherwise from you on this patch?
I already have one for
[PATCH 2/2] IPVS netns shutdown/startup dead-lock (Take III)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 2b771dc..a1af72f 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -57,6 +57,7 @@ static DEFINE_MUTEX(__ip_vs_mutex);
>
> /* lock for service table */
> static DEFINE_RWLOCK(__ip_vs_svc_lock);
> +static struct lock_class_key ip_vs_rs_key;
>
> /* sysctl variables */
>
> @@ -3680,6 +3681,7 @@ int __net_init ip_vs_control_net_init(struct net *net)
> struct netns_ipvs *ipvs = net_ipvs(net);
>
> ipvs->rs_lock = __RW_LOCK_UNLOCKED(ipvs->rs_lock);
> + __rwlock_init(&ipvs->rs_lock, "ipvs->rs_lock", &ip_vs_rs_key);
>
> /* Initialize rs_table */
> for (idx = 0; idx < IP_VS_RTAB_SIZE; idx++)
> --
> 1.7.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" 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 2/2] IPVS netns shutdown/startup dead-lock (Take III)
From: Simon Horman @ 2011-10-04 21:15 UTC (permalink / raw)
To: Julian Anastasov
Cc: Hans Schillstrom, wensong, lvs-devel, netdev, netfilter-devel,
hans
In-Reply-To: <alpine.LFD.2.00.1110041032520.1547@ja.ssi.bg>
On Tue, Oct 04, 2011 at 10:40:29AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 4 Oct 2011, Hans Schillstrom wrote:
>
> > From: Hans Schillstrom <hans@schillstrom.com>
> >
> > ip_vs_mutext is used by both netns shutdown code and startup
> > and both implicit uses sk_lock-AF_INET mutex.
> >
> > cleanup CPU-1 startup CPU-2
> > ip_vs_dst_event() ip_vs_genl_set_cmd()
> > sk_lock-AF_INET __ip_vs_mutex
> > sk_lock-AF_INET
> > __ip_vs_mutex
> > * DEAD LOCK *
> >
> > A new mutex placed in ip_vs netns struct called sync_mutex is added.
> >
> > Comments from Julian and Simon added.
> > This patch has been running for more than 3 month now and it seems to work.
> >
> > Ver. 3
> > IP_VS_SO_GET_DAEMON in do_ip_vs_get_ctl protected by sync_mutex
> > instead of __ip_vs_mutex as sugested by Julian.
> >
> > Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
>
> Looks good to me, with one extra empty line in
> start_sync_thread
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
Thanks, I will apply this change.
^ permalink raw reply
* Re: Application brokne due to XFRMA_ALG_AUTH_TRUNC
From: Ben Hutchings @ 2011-10-04 21:35 UTC (permalink / raw)
To: Eduardo Panisset; +Cc: netdev
In-Reply-To: <CADsjWXR66C2SdfmLP0wqRvbcDJkXbYBN=zzTZLP5_+pE0fenqQ@mail.gmail.com>
On Tue, 2011-10-04 at 18:08 -0300, Eduardo Panisset wrote:
> Hi All,
>
> I have an application compiled against kernel 2.6.32 and which is
> using XFRMA_MARK (value 20).
It was not defined in 2.6.32. Perhaps you are using a distribution that
backported this feature incorrectly?
> However the same aplication does not work anymore on kernel 2.6.38.8
> due to XFRMA_MARK has now the value 21 because of a new attribute
> XFRMA_ALG_AUTH_TRUNC inserted before it in the file linux/xfrm.h.
> Now the only solution would be recompiling this application. Is
> correct introducing a new parameter in the middle of an existing enum
> in the kernel headers ?
So far as I can see, in mainline Linux versions the value has always
been 21.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH ethtool 1/3] ethtool: file ethtool-copy.h update.
From: Ben Hutchings @ 2011-10-04 22:09 UTC (permalink / raw)
To: Sucheta Chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1316514695-17157-2-git-send-email-sucheta.chakraborty@qlogic.com>
On Tue, 2011-09-20 at 03:31 -0700, Sucheta Chakraborty wrote:
> Used linux-3.0.1-net-next tree for the update.
[...]
I'll update ethtool-copy.h using the current net-next.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH ethtool 2/3] ethtool: add support for external loopback.
From: Ben Hutchings @ 2011-10-04 22:12 UTC (permalink / raw)
To: Sucheta Chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1316514695-17157-3-git-send-email-sucheta.chakraborty@qlogic.com>
On Tue, 2011-09-20 at 03:31 -0700, Sucheta Chakraborty wrote:
> External loopback will be performed in addition to other offline tests.
> User need to pass new parameter "external_lb" for the same.
>
> Reqd. man page changes included.
Applied, but:
[...]
> @@ -1689,6 +1692,9 @@ static int dump_test(struct ethtool_drvinfo *info, struct ethtool_test *test,
>
> rc = test->flags & ETH_TEST_FL_FAILED;
> fprintf(stdout, "The test result is %s\n", rc ? "FAIL" : "PASS");
> + fprintf(stdout, "External loopback test is %s\n",
> + test->flags & ETH_TEST_FL_EXTERNAL_LB_DONE ? "executed" :
> + "not executed");
>
> if (info->testinfo_len)
> fprintf(stdout, "The test extra info:\n");
1. This message should say 'was', not 'is'.
2. There are undoubtedly scripts that parse the output of ethtool -t.
We might break them if we add a line to the output of existing commands.
I've made this conditional on test_type == EXTERNAL_LB.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Sridhar Samudrala @ 2011-10-04 22:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Andi Kleen, Kevin Wilson, netdev
In-Reply-To: <20111004140754.0e677941@nehalam.linuxnetplumber.net>
On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
> On Tue, 04 Oct 2011 09:58:55 -0700
> Andi Kleen <andi@firstfloor.org> wrote:
>
> > Stephen Hemminger <shemminger@vyatta.com> writes:
> >
> > > This adds a new 'br' command which is the bridging equivalent of
> > > the ip command. More of a demo of how to use netlink and bridging
> > > at this point.
> >
> > Please name it "bridge", not "br"
> >
> > -Andi
>
> Ok, but it breaks the existing pattern.
Is this supposed to replace brctl utility?
Can we add/delete a bridge and add/delete interfaces to a bridge using
this command?
If so, why not make it
ip bridge add/del <brname>
ip bridge addif/delif <brname> <ifname>
Thanks
Sridhar
^ permalink raw reply
* Re: [PATCH ethtool 3/3] ethtool: add ETHTOOL_{G,S}CHANNEL support.
From: Ben Hutchings @ 2011-10-04 22:21 UTC (permalink / raw)
To: Sucheta Chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1316514695-17157-4-git-send-email-sucheta.chakraborty@qlogic.com>
On Tue, 2011-09-20 at 03:31 -0700, Sucheta Chakraborty wrote:
> Used to configure number of rx and tx rings.
> Reqd. man page changes are included.
[...]
> @@ -754,6 +764,24 @@ lB l.
> Specify the location/ID to insert the rule. This will overwrite
> any rule present in that location and will not go through any
> of the rule ordering process.
> +.TP
> +.B \-l \-\-show\-channels
> +Queries the specified network device for channel parameter information.
> +.TP
> +.B \-L \-\-set\-channels
> +Changes the channel parameters of the specified network device.
I think the manual page needs to explain briefly what is meant by a
channel. (So should ethtool.h, really!)
[...]
> @@ -495,6 +512,13 @@ static struct cmdline_info cmdline_ring[] = {
> { "tx", CMDL_S32, &ring_tx_wanted, &ering.tx_pending },
> };
>
> +static struct cmdline_info cmdline_channels[] = {
> + { "rx_count", CMDL_S32, &channels_rx_wanted, &echannels.rx_count },
> + { "tx_count", CMDL_S32, &channels_tx_wanted, &echannels.tx_count },
> + { "other_count", CMDL_S32, &channels_other_wanted, &echannels.other_count },
> + { "combined_count", CMDL_S32, &channels_combined_wanted, &echannels.combined_count },
> +};
I don't think it's necessary to include '_count' in these keywords.
[...]
> @@ -1751,6 +1785,32 @@ static int dump_ring(void)
> return 0;
> }
>
> +static int dump_channels(void)
> +{
> + fprintf(stdout,
> + "Re-set maximums:\n"
Should 'Re-set' be 'Pre-set'?
> + "Max RX: %u\n"
> + "Max TX: %u\n"
> + "Max Other: %u\n"
> + "Max Combined: %u\n",
> + echannels.max_rx, echannels.max_tx,
> + echannels.max_other,
> + echannels.max_combined);
The heading says they are maximums, so I don't think it's necessary to
include 'Max' on each line.
> + fprintf(stdout,
> + "Current hardware settings:\n"
> + "RX Count: %u\n"
> + "TX Count: %u\n"
> + "Other Count: %u\n"
> + "Combined Count: %u\n",
I don't think it's necessary to include 'Count' on each line here,
either.
[...]
> @@ -2114,6 +2178,58 @@ static int do_gring(int fd, struct ifreq *ifr)
> return 0;
> }
>
> +static int do_schannels(int fd, struct ifreq *ifr)
> +{
> + int err, changed = 0;
> +
> + echannels.cmd = ETHTOOL_GCHANNELS;
> + ifr->ifr_data = (caddr_t)&echannels;
> + err = send_ioctl(fd, ifr);
> + if (err) {
> + perror("Cannot get device channels settings");
> + return 1;
> + }
> +
> + do_generic_set(cmdline_channels, ARRAY_SIZE(cmdline_channels),
> + &changed);
> +
> + if (!changed) {
> + fprintf(stderr, "no channels parameters changed, aborting\n");
> + return 1;
> + }
[...]
These messages (and others below) are not grammatical. They should say
'channel settings' or 'channel parameters'.
Actually, you could be more specific about what the parameters are, and
just write 'numbers of channels'.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Stephen Hemminger @ 2011-10-04 22:27 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: Andi Kleen, Kevin Wilson, netdev
In-Reply-To: <1317766638.21658.11.camel@w-sridhar.beaverton.ibm.com>
On Tue, 04 Oct 2011 15:17:18 -0700
Sridhar Samudrala <sri@us.ibm.com> wrote:
> On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
> > On Tue, 04 Oct 2011 09:58:55 -0700
> > Andi Kleen <andi@firstfloor.org> wrote:
> >
> > > Stephen Hemminger <shemminger@vyatta.com> writes:
> > >
> > > > This adds a new 'br' command which is the bridging equivalent of
> > > > the ip command. More of a demo of how to use netlink and bridging
> > > > at this point.
> > >
> > > Please name it "bridge", not "br"
> > >
> > > -Andi
> >
> > Ok, but it breaks the existing pattern.
>
> Is this supposed to replace brctl utility?
>
> Can we add/delete a bridge and add/delete interfaces to a bridge using
> this command?
>
> If so, why not make it
> ip bridge add/del <brname>
> ip bridge addif/delif <brname> <ifname>
>
You can already use 'ip link' to add/delete bridge, and add interface
to bridge by setting master.
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Con Kolivas @ 2011-10-04 22:32 UTC (permalink / raw)
To: Serge Belyshev
Cc: Christoph Lameter, Joe Perches, starlight, Eric Dumazet,
linux-kernel, netdev, Willy Tarreau, Peter Zijlstra
In-Reply-To: <87zkhg1ppl.fsf@depni.sinp.msu.ru>
On Wed, 5 Oct 2011 07:12:06 Serge Belyshev wrote:
> BFS FAQ writes:
> > NUMA aware?
> >
> > It is NOT NUMA aware in the sense that it does any fancy shit on NUMA,
> > but it will work on NUMA hardware just fine. Only the really big NUMA
> > hardware is likely to suffer in performance, and this is theoretically
> > only, since no one has that sort of hardware to prove it to me, but it
> > seems almost certain.
>
> This part of FAQ entry was written before 0.300, (i.e. more than 2 years
> ago)
>
> > v0.300 onwards have NUMA enhancements.
>
> And this was added after. =)
>
> As of now, BFS scheduling is NUMA-aware. (see resched_best_mask())
Admittedly the wording of this got confused as BFS developed. It originally
had no NUMA enhancements, but now it does. The code to benefit NUMA is quite
simple though, but then, so is everything in BFS.
Regards,
Con
--
-ck
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Michał Mirosław @ 2011-10-04 22:32 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: Stephen Hemminger, Andi Kleen, Kevin Wilson, netdev
In-Reply-To: <1317766638.21658.11.camel@w-sridhar.beaverton.ibm.com>
2011/10/5 Sridhar Samudrala <sri@us.ibm.com>:
> On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
>> On Tue, 04 Oct 2011 09:58:55 -0700
>> Andi Kleen <andi@firstfloor.org> wrote:
>> > Stephen Hemminger <shemminger@vyatta.com> writes:
>> > > This adds a new 'br' command which is the bridging equivalent of
>> > > the ip command. More of a demo of how to use netlink and bridging
>> > > at this point.
>> > Please name it "bridge", not "br"
>> Ok, but it breaks the existing pattern.
> Is this supposed to replace brctl utility?
>
> Can we add/delete a bridge and add/delete interfaces to a bridge using
> this command?
>
> If so, why not make it
> ip bridge add/del <brname>
> ip bridge addif/delif <brname> <ifname>
I'll add one more idea:
ip link add/del <brname> type bridge
ip bridge add/del <brname> <ifname>
ip bridge fdb ...
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH ethtool 3/3] ethtool: add ETHTOOL_{G,S}CHANNEL support.
From: Ben Hutchings @ 2011-10-04 22:36 UTC (permalink / raw)
To: Sucheta Chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1317766902.2751.25.camel@bwh-desktop>
On Tue, 2011-10-04 at 23:21 +0100, Ben Hutchings wrote:
> On Tue, 2011-09-20 at 03:31 -0700, Sucheta Chakraborty wrote:
> > Used to configure number of rx and tx rings.
> > Reqd. man page changes are included.
> [...]
> > @@ -754,6 +764,24 @@ lB l.
> > Specify the location/ID to insert the rule. This will overwrite
> > any rule present in that location and will not go through any
> > of the rule ordering process.
> > +.TP
> > +.B \-l \-\-show\-channels
> > +Queries the specified network device for channel parameter information.
> > +.TP
> > +.B \-L \-\-set\-channels
> > +Changes the channel parameters of the specified network device.
>
> I think the manual page needs to explain briefly what is meant by a
> channel. (So should ethtool.h, really!)
[...]
Perhaps something like this:
.TP
.B \-l \-\-show\-channels
Queries the specified network device for the numbers of channels it has.
A channel is an IRQ and the set of queues that can trigger that IRQ.
.TP
.B \-L \-\-set\-channels
Changes the numbers of channels of the specified network device.
.TP
.BI rx \ N
Changes the number of channels with only receive queues.
.TP
.BI tx \ N
Changes the number of channels with only transmit queues.
.TP
.BI other \ N
Changes the number of channels used only for other purposes e.g. link
interrupts or SR-IOV co-ordination.
.TP
.BI combined \ N
Changes the number of multi-purpose channels.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Stephen Hemminger @ 2011-10-04 22:42 UTC (permalink / raw)
To: Michał Mirosław
Cc: Sridhar Samudrala, Andi Kleen, Kevin Wilson, netdev
In-Reply-To: <CAHXqBF+gXg=EAOm4F_qGWhND6EsZHzoamE8fRX6eqe1p1zU-SQ@mail.gmail.com>
On Wed, 5 Oct 2011 00:32:31 +0200
Michał Mirosław <mirqus@gmail.com> wrote:
> 2011/10/5 Sridhar Samudrala <sri@us.ibm.com>:
> > On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
> >> On Tue, 04 Oct 2011 09:58:55 -0700
> >> Andi Kleen <andi@firstfloor.org> wrote:
> >> > Stephen Hemminger <shemminger@vyatta.com> writes:
> >> > > This adds a new 'br' command which is the bridging equivalent of
> >> > > the ip command. More of a demo of how to use netlink and bridging
> >> > > at this point.
> >> > Please name it "bridge", not "br"
> >> Ok, but it breaks the existing pattern.
> > Is this supposed to replace brctl utility?
> >
> > Can we add/delete a bridge and add/delete interfaces to a bridge using
> > this command?
> >
> > If so, why not make it
> > ip bridge add/del <brname>
> > ip bridge addif/delif <brname> <ifname>
>
> I'll add one more idea:
>
> ip link add/del <brname> type bridge
> ip bridge add/del <brname> <ifname>
> ip bridge fdb ...
In 3.0 you can already do:
# ip link add dev br3 type bridge
# ip link set dev eth3 master br3
I see no reason to add 'ip bridge' syntax wrappers.
^ permalink raw reply
* Re: [PATCH 1/2] fix lockdep warning
From: Julian Anastasov @ 2011-10-04 22:51 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: horms, wensong, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1317639399-4522-1-git-send-email-hans.schillstrom@ericsson.com>
Hello,
On Mon, 3 Oct 2011, Hans Schillstrom wrote:
> From: Hans Schillstrom <hans@schillstrom.com>
>
> rs_lock needs a key to make lock dep happy.
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 2b771dc..a1af72f 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -57,6 +57,7 @@ static DEFINE_MUTEX(__ip_vs_mutex);
>
> /* lock for service table */
> static DEFINE_RWLOCK(__ip_vs_svc_lock);
> +static struct lock_class_key ip_vs_rs_key;
ip_vs_rs_key remains unused without debugging. I don't
remember the reason why IPVS is the only place that calls
__rwlock_init instead of rwlock_init. Can we use rwlock_init?
> /* sysctl variables */
>
> @@ -3680,6 +3681,7 @@ int __net_init ip_vs_control_net_init(struct net *net)
> struct netns_ipvs *ipvs = net_ipvs(net);
>
> ipvs->rs_lock = __RW_LOCK_UNLOCKED(ipvs->rs_lock);
> + __rwlock_init(&ipvs->rs_lock, "ipvs->rs_lock", &ip_vs_rs_key);
>
> /* Initialize rs_table */
> for (idx = 0; idx < IP_VS_RTAB_SIZE; idx++)
> --
> 1.7.4.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Sridhar Samudrala @ 2011-10-04 22:54 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Michał Mirosław, Andi Kleen, Kevin Wilson, netdev
In-Reply-To: <20111004154244.3530f21c@nehalam.linuxnetplumber.net>
On Tue, 2011-10-04 at 15:42 -0700, Stephen Hemminger wrote:
> On Wed, 5 Oct 2011 00:32:31 +0200
> Michał Mirosław <mirqus@gmail.com> wrote:
>
> > 2011/10/5 Sridhar Samudrala <sri@us.ibm.com>:
> > > On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
> > >> On Tue, 04 Oct 2011 09:58:55 -0700
> > >> Andi Kleen <andi@firstfloor.org> wrote:
> > >> > Stephen Hemminger <shemminger@vyatta.com> writes:
> > >> > > This adds a new 'br' command which is the bridging equivalent of
> > >> > > the ip command. More of a demo of how to use netlink and bridging
> > >> > > at this point.
> > >> > Please name it "bridge", not "br"
> > >> Ok, but it breaks the existing pattern.
> > > Is this supposed to replace brctl utility?
> > >
> > > Can we add/delete a bridge and add/delete interfaces to a bridge using
> > > this command?
> > >
> > > If so, why not make it
> > > ip bridge add/del <brname>
> > > ip bridge addif/delif <brname> <ifname>
> >
> > I'll add one more idea:
> >
> > ip link add/del <brname> type bridge
> > ip bridge add/del <brname> <ifname>
> > ip bridge fdb ...
>
> In 3.0 you can already do:
> # ip link add dev br3 type bridge
> # ip link set dev eth3 master br3
I just pulled iproute2 tree from
git://github.com/shemminger/iproute2.git
But i don't see these updates there. Isn't this your latest iproute2 tree?
>
> I see no reason to add 'ip bridge' syntax wrappers.
If we can make all bridge related commands use 'ip bridge' prefix ,
i think we wouldn't need a new 'br' command.
Thanks
Sridhar
^ permalink raw reply
* Re: [RFC] iproute2: add br command
From: Stephen Hemminger @ 2011-10-04 23:00 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Michał Mirosław, Andi Kleen, Kevin Wilson, netdev
In-Reply-To: <1317768847.21658.16.camel@w-sridhar.beaverton.ibm.com>
On Tue, 04 Oct 2011 15:54:07 -0700
Sridhar Samudrala <sri@us.ibm.com> wrote:
> On Tue, 2011-10-04 at 15:42 -0700, Stephen Hemminger wrote:
> > On Wed, 5 Oct 2011 00:32:31 +0200
> > Michał Mirosław <mirqus@gmail.com> wrote:
> >
> > > 2011/10/5 Sridhar Samudrala <sri@us.ibm.com>:
> > > > On Tue, 2011-10-04 at 14:07 -0700, Stephen Hemminger wrote:
> > > >> On Tue, 04 Oct 2011 09:58:55 -0700
> > > >> Andi Kleen <andi@firstfloor.org> wrote:
> > > >> > Stephen Hemminger <shemminger@vyatta.com> writes:
> > > >> > > This adds a new 'br' command which is the bridging equivalent of
> > > >> > > the ip command. More of a demo of how to use netlink and bridging
> > > >> > > at this point.
> > > >> > Please name it "bridge", not "br"
> > > >> Ok, but it breaks the existing pattern.
> > > > Is this supposed to replace brctl utility?
> > > >
> > > > Can we add/delete a bridge and add/delete interfaces to a bridge using
> > > > this command?
> > > >
> > > > If so, why not make it
> > > > ip bridge add/del <brname>
> > > > ip bridge addif/delif <brname> <ifname>
> > >
> > > I'll add one more idea:
> > >
> > > ip link add/del <brname> type bridge
> > > ip bridge add/del <brname> <ifname>
> > > ip bridge fdb ...
> >
> > In 3.0 you can already do:
> > # ip link add dev br3 type bridge
> > # ip link set dev eth3 master br3
>
> I just pulled iproute2 tree from
> git://github.com/shemminger/iproute2.git
>
> But i don't see these updates there. Isn't this your latest iproute2 tree?
There is no special code for doing ip link stuff. it just works with
correct kernel.
> >
> > I see no reason to add 'ip bridge' syntax wrappers.
>
> If we can make all bridge related commands use 'ip bridge' prefix ,
> i think we wouldn't need a new 'br' command.
Maybe but there is no IP protocol function or requirement for bridging.
^ permalink raw reply
* Re: [PATCH v5 0/8] per-cgroup tcp buffer pressure settings
From: KAMEZAWA Hiroyuki @ 2011-10-05 0:29 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill, avagin, devel
In-Reply-To: <1317730680-24352-1-git-send-email-glommer@parallels.com>
On Tue, 4 Oct 2011 16:17:52 +0400
Glauber Costa <glommer@parallels.com> wrote:
> [[ v3: merge Kirill's suggestions, + a destroy-related bugfix ]]
> [[ v4: Fix a bug with non-mounted cgroups + disallow task movement ]]
> [[ v5: Compile bug with modular ipv6 + tcp files in bytes ]]
>
> Kame, Kirill,
>
> I am submitting this again merging most of your comments. I've decided to
> leave some of them out:
> * I am not using res_counters for allocated_memory. Besides being more
> expensive than what we need, to make it work in a nice way, we'd have
> to change the !cgroup code, including other protocols than tcp. Also,
>
> * I am not using failcnt and max_usage_in_bytes for it. I believe the value
> of those lies more in the allocation than in the pressure control. Besides,
> fail conditions lie mostly outside of the memory cgroup's control. (Actually,
> a soft_limit makes a lot of sense, and I do plan to introduce it in a follow
> up series)
>
> If you agree with the above, and there are any other pressing issues, let me
> know and I will address them ASAP. Otherwise, let's discuss it. I'm always open.
>
I'm not familar with reuqirements of users. So, I appreciate your choices.
What I adivse you here is taking a deep breath. Making new version every day
is not good for reviewing process ;)
(It's now -rc8 and merge will not be so quick, anyway.)
At this stage, my concern is view of interfaces and documenation, and future plans.
Let me give a try explanation by myself. (Correct me ;)
I added some questions but I'm sorry you've already answered.
New interfaces are 5 files. All files exists only for non-root memory cgroup.
1. memory.independent_kmem_limit
2. memory.kmem.usage_in_bytes
3. memory.kmem.limit_in_bytes
4. memory.kmem.tcp.limit_in_bytes
5. memory.kmem.tcp.usage_in_bytes
* memory.independent_kmem_limit
If 1, kmem_limit_in_bytes/kmem_usage_in_bytes works.
If 0, kmem_limit_in_bytes/kmem_usage_in_bytes doesn't work and all kmem
usages are controlled under memory.limit_in_bytes.
Question:
- What happens when parent/chidlren cgroup has different indepedent_kmem_limit ?
- What happens at creating a new cgroup with use_hierarchy==1.
* memory.kmem_limit_in_bytes/memory.kmem.tcp.limit_in_bytes
Both files works independently for _Now_. And memory.kmem_usage_in_bytes and
memory.kmem_tcp.usage_in_bytes has no relationships.
In future plan, kmem.usage_in_bytes should includes tcp.kmem_usage_in_bytes.
And kmem.limit_in_bytes should be the limiation of sum of all kmem.xxxx.limit_in_bytes.
Question:
- Why this integration is difficult ?
Can't tcp-limit-code borrows some amount of charges in batch from kmem_limit
and use it ?
- Don't you need a stat file to indicate "tcp memory pressure works!" ?
It can be obtained already ?
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] tg3: Dont dump registers if interface not ready.
From: Matt Carlson @ 2011-10-05 2:14 UTC (permalink / raw)
To: Xiao Jiang
Cc: Joe Jin, Matthew Carlson, Michael Chan, Guru Anbalagane,
Gurudas Pai, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Greg Marsden
In-Reply-To: <4E841519.6040201@gmail.com>
On Wed, Sep 28, 2011 at 11:50:01PM -0700, Xiao Jiang wrote:
> Joe Jin wrote:
> > When bootup the server with BCM5704 Gigabit Ethernet get below warning:
> >
> > tg3 0000:03:01.0: eth0: DMA Status error. Resetting chip.
> > <Registers state of device>
> > tg3 0000:03:01.0: eth0: 0: Host status block [00000007:00000002:(0000:0000:0000):(0000:0000)]
> > tg3 0000:03:01.0: eth0: 0: NAPI info [00000001:00000002:(0000:0000:01ff):0000:(00c8:0000:0000:0000)]
> > tg3 0000:03:01.0: eth0: Link is up at 1000 Mbps, full duplex
> > tg3 0000:03:01.0: eth0: Flow control is on for TX and on for RX
> > tg3 0000:03:01.0: tg3_stop_block timed out, ofs=4800 enable_bit=2
> > tg3 0000:03:01.0: eth0: Link is down
> > tg3 0000:03:01.0: eth0: Link is up at 1000 Mbps, full duplex
> > tg3 0000:03:01.0: eth0: Flow control is on for TX and on for RX
> >
> > If device not ready, then would not dump registers info.
> >
> > Signed-off-by: Joe Jin <joe.jin@oracle.com>
> > Signed-off-by: Guru Anbalagane <guru.anbalagane@oracle.com>
> > Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
> > Cc: Matt Carlson <mcarlson@broadcom.com>
> > Cc: Michael Chan <mchan@broadcom.com>
> > ---
> > drivers/net/tg3.c | 11 +++++++++--
> >
> Maybe this one should based on net-next tree too, the tg3.c
> is lived below ./drivers/net/ethernet/broadcom/ in that tree.
>
> Thanks,
> Xiao Jiang
> > 1 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> > index 4a1374d..d79d344 100644
> > --- a/drivers/net/tg3.c
> > +++ b/drivers/net/tg3.c
> > @@ -5475,10 +5475,15 @@ static void tg3_process_error(struct tg3 *tp)
> > {
> > u32 val;
> > bool real_error = false;
> > + bool dump = true;
> >
> > if (tg3_flag(tp, ERROR_PROCESSED))
> > return;
> >
> > + /* If interface not ready then dont dump error */
> > + if (!netif_carrier_ok(tp->dev))
> > + dump = false;
Would you still experience the problem if you did the following instead
of the above link check?
if (tg3_flag(tp, INIT_COMPLETE))
dump = false;
> > /* Check Flow Attention register */
> > val = tr32(HOSTCC_FLOW_ATTN);
> > if (val & ~HOSTCC_FLOW_ATTN_MBUF_LWM) {
> > @@ -5492,14 +5497,16 @@ static void tg3_process_error(struct tg3 *tp)
> > }
> >
> > if (tr32(RDMAC_STATUS) || tr32(WDMAC_STATUS)) {
> > - netdev_err(tp->dev, "DMA Status error. Resetting chip.\n");
> > + if (dump)
> > + netdev_err(tp->dev, "DMA Status error. Resetting chip.\n");
> > real_error = true;
> > }
> >
> > if (!real_error)
> > return;
> >
> > - tg3_dump_state(tp);
> > + if (dump)
> > + tg3_dump_state(tp);
> >
> > tg3_flag_set(tp, ERROR_PROCESSED);
> > schedule_work(&tp->reset_task);
> >
>
>
^ permalink raw reply
* [net-next 1/1] bna: Multiple Definition and Interface Setup Fix
From: Rasesh Mody @ 2011-10-05 2:31 UTC (permalink / raw)
To: davem, netdev
Cc: linux-next, linux-kernel, linux-scsi, rdunlap, sfr, huangj,
adapter_linux_open_src_team, Rasesh Mody
drivers/net/built-in.o: In function `bfa_ioc_ct2_poweron':
(.text+0xcdc90): multiple definition of `bfa_ioc_ct2_poweron'
drivers/scsi/built-in.o:(.text+0x17f9a0): first defined here
This patch renames bfa_ioc_ct2_poweron() to bfa_nw_ioc_ct2_poweron() to avoid
multiple definition with Brocade scsi driver. It also modifies asic specific
interface setup to allocate MSIX resources at power on in case of 1860 HW with
no asic block and warns if the asic gen is neither BFI_ASIC_GEN_CT nor
BFI_ASIC_GEN_CT2.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bfa_ioc.c | 5 ++++-
drivers/net/ethernet/brocade/bna/bfa_ioc.h | 2 +-
drivers/net/ethernet/brocade/bna/bfa_ioc_ct.c | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index e02d607..b0307a0 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -2006,8 +2006,11 @@ bfa_nw_ioc_pci_init(struct bfa_ioc *ioc, struct bfa_pcidev *pcidev,
*/
if (ioc->asic_gen == BFI_ASIC_GEN_CT)
bfa_nw_ioc_set_ct_hwif(ioc);
- else
+ else {
+ WARN_ON(ioc->asic_gen != BFI_ASIC_GEN_CT2);
bfa_nw_ioc_set_ct2_hwif(ioc);
+ bfa_nw_ioc_ct2_poweron(ioc);
+ }
bfa_ioc_map_port(ioc);
bfa_ioc_reg_init(ioc);
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.h b/drivers/net/ethernet/brocade/bna/bfa_ioc.h
index d5a21f4..ca158d1 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.h
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.h
@@ -281,7 +281,7 @@ void bfa_nw_ioc_mbox_regisr(struct bfa_ioc *ioc, enum bfi_mclass mc,
void bfa_nw_ioc_set_ct_hwif(struct bfa_ioc *ioc);
void bfa_nw_ioc_set_ct2_hwif(struct bfa_ioc *ioc);
-void bfa_ioc_ct2_poweron(struct bfa_ioc *ioc);
+void bfa_nw_ioc_ct2_poweron(struct bfa_ioc *ioc);
void bfa_nw_ioc_attach(struct bfa_ioc *ioc, void *bfa,
struct bfa_ioc_cbfn *cbfn);
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc_ct.c b/drivers/net/ethernet/brocade/bna/bfa_ioc_ct.c
index c2d3b1a..348479b 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc_ct.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc_ct.c
@@ -454,7 +454,7 @@ bfa_ioc_ct2_lpu_read_stat(struct bfa_ioc *ioc)
#define __MSIX_VT_NUMVT_(_v) ((_v) << __MSIX_VT_NUMVT__SH)
#define __MSIX_VT_OFST_ 0x000007ff
void
-bfa_ioc_ct2_poweron(struct bfa_ioc *ioc)
+bfa_nw_ioc_ct2_poweron(struct bfa_ioc *ioc)
{
void __iomem *rb = ioc->pcidev.pci_bar_kva;
u32 r32;
--
1.7.1
^ permalink raw reply related
* Re: [net-next 1/1] bna: Multiple Definition and Interface Setup Fix
From: David Miller @ 2011-10-05 3:27 UTC (permalink / raw)
To: rmody
Cc: netdev, linux-next, linux-kernel, linux-scsi, rdunlap, sfr,
huangj, adapter_linux_open_src_team
In-Reply-To: <1317781880-26515-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Tue, 4 Oct 2011 19:31:20 -0700
> drivers/net/built-in.o: In function `bfa_ioc_ct2_poweron':
> (.text+0xcdc90): multiple definition of `bfa_ioc_ct2_poweron'
> drivers/scsi/built-in.o:(.text+0x17f9a0): first defined here
>
> This patch renames bfa_ioc_ct2_poweron() to bfa_nw_ioc_ct2_poweron() to avoid
> multiple definition with Brocade scsi driver. It also modifies asic specific
> interface setup to allocate MSIX resources at power on in case of 1860 HW with
> no asic block and warns if the asic gen is neither BFI_ASIC_GEN_CT nor
> BFI_ASIC_GEN_CT2.
>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox