* Re: [PATCH 1/2] rps: core implementation
From: Jarek Poplawski @ 2009-11-20 19:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911200908l5acbf3d0v5fc9a2e1adb7c3a5@mail.gmail.com>
On Fri, Nov 20, 2009 at 09:08:10AM -0800, Tom Herbert wrote:
> > The description reads: "This solution queues packets early on in the
> > receive path on the backlog queues of other CPUs.", so I'm not sure
> > it's intended.
>
> That is precisely the intent. Getting packets quickly distributed to
> the target cpus maximizes parallelism and reduces latency.
Then precisely the intent is "the backlog queues of target CPUs".
"The backlog queues of other CPUs" may suggest that e.g. one cpu is
only doing distribution etc.
>
> Did you test it like this (and it was visibly worse)?:
> >
> > if (cpu < 0 || cpu == smp_processor_id())
> >
> >> + return __netif_receive_skb(skb);
> >> + else
> >> + return enqueue_to_backlog(skb, cpu);
> >> +}
> >> +
> This increases overall latency due to head of line blocking which will
> outweigh the benefits of optimizing for this one case.
The way I asked should suggest I "suspected" it's on purpose, and was
curious about "digits", but thanks for confirming this.
Jarek P.
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Eric W. Biederman @ 2009-11-20 18:21 UTC (permalink / raw)
To: Dhananjay Phadke
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <4B06DAF9.6080108@qlogic.com>
Dhananjay Phadke <dhananjay.phadke@qlogic.com> writes:
> Eric W. Biederman wrote:
>> MSI-X uses the same messages on the wire is the same as MSI it is
>> only the programming interface that is different. So if MSI works and
>> MSI-X does not it is not a platform problem.
>>
>
> Sure, but firmware and driver see it differently. IMO, this points to some
> firmware issue (which is why I asked him to get right version from right
> source). All that driver did was tried to enable msi-x, from my testing, I can
> tell that both msi and msix work on all revisions of the nic asic, but firmware
> revision can make a difference. For chiprev 0x25, 3.4.339 is the right firmware
> version.
Sorry I meant that only as a clarification, not to derail the conversation.
This does sound like a firmware mismatch issue to me as well.
Eric
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Dhananjay Phadke @ 2009-11-20 18:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <m1d43drt0g.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> MSI-X uses the same messages on the wire is the same as MSI it is
> only the programming interface that is different. So if MSI works and
> MSI-X does not it is not a platform problem.
>
Sure, but firmware and driver see it differently. IMO, this points to
some firmware issue (which is why I asked him to get right version from
right source). All that driver did was tried to enable msi-x, from my
testing, I can tell that both msi and msix work on all revisions of the
nic asic, but firmware revision can make a difference. For chiprev 0x25,
3.4.339 is the right firmware version.
Thanks,
Dhananjay
^ permalink raw reply
* Re: [PATCH NEXT] netxen: remove PCI IDs of CNA device
From: David Miller @ 2009-11-20 18:00 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, dhananjay.phadke
In-Reply-To: <1258679292-26098-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 19 Nov 2009 17:08:12 -0800
> Remove PCI vendor and device IDs for QLE8240 and QLE8242
> CNA devices. CNA devices will have separate driver.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] igb: Add full support for 82580 devices
From: David Miller @ 2009-11-20 18:00 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20091119224220.29487.14972.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 19 Nov 2009 14:42:21 -0800
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch makes use of the 82580 PHY and MAC support added and adds a set
> of supported device IDs for said hardware.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] igb: add support for the 82580 phy
From: David Miller @ 2009-11-20 18:00 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20091119224108.29487.75458.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 19 Nov 2009 14:41:42 -0800
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch adds support for the phy included in the 82580 silicon family.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: Compile Error for TI Davinci
From: David Miller @ 2009-11-20 17:50 UTC (permalink / raw)
To: srk; +Cc: netdev, davinci-linux-open-source, chaithrika
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC35608702FA751A01@dbde02.ent.ti.com>
From: "Govindarajan, Sriramakrishnan" <srk@ti.com>
Date: Fri, 20 Nov 2009 17:36:38 +0530
> Patch for "TI DaVinci EMAC: Clear statistics register properly"(commit- 0fe7463a35aadfaf22d1ca58325ab3851b8d757c on net-next) has dependency on
> Patch "TI DaVinci EMAC: Minor macro related updates "(commit - 69ef9694099802f7feeb23182dfb869e7c5f76f0 on net-next).
>
> The first patch has been pushed upstream while the later still remains on
> Net-next. Due to the dependency between these two, we are seeing compilation
> Failure when we build for Davinci.
>
> Can you please push "TI DaVinci EMAC: Minor macro related updates" - 69ef9694099802f7feeb23182dfb869e7c5f76f0 up-stream .
This should not be happening, because yesterday I merged Linus's
tree into net-2.6 and afterwards I merged net-2.6 into net-next-2.6
Please verify that the problem still occurs.
^ permalink raw reply
* Re: [PATCH 3/7] via-velocity: Enable support for adaptive interrupt supression
From: David Miller @ 2009-11-20 17:47 UTC (permalink / raw)
To: shemminger; +Cc: simon.kagstrom, netdev, davej, romieu
In-Reply-To: <20091120090505.0fa700e6@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 20 Nov 2009 09:05:05 -0800
> This should be done via ethtool irq coalescing settings not more module paramets.
Agreed.
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Eric W. Biederman @ 2009-11-20 17:43 UTC (permalink / raw)
To: Dhananjay Phadke
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <4B06D234.4060600@qlogic.com>
Dhananjay Phadke <dhananjay.phadke@qlogic.com> writes:
>> Weird. MSI's definitely weren't disabled. Looking a little farther at
>> your quoted setup MSI work on your board. This is definitely
>> something specific to the driver. Except for a few initialization
>> races that are an issue for bonding I am running 2.6.31 just fine.
>
>
> Jens,
>
> Even if /proc/interrupt says PCI-MSI in both cases, single interrupt case is msi
> vs. 4 vector case is msi-x. To confirm that msi-x doesn't work with your
> card/machine, you can still stay on 2.6.31 and set use_msi_x=0 in
> netxen_nic_main.c.
>
> I had tried to make a available a module param to disable msi/msi-x for
> platforms where msi-x doesn't work cleanly, but it was declined by David Miller,
> et al.
MSI-X uses the same messages on the wire is the same as MSI it is
only the programming interface that is different. So if MSI works and
MSI-X does not it is not a platform problem.
Eric
^ permalink raw reply
* Re: stmmac patches...
From: David Miller @ 2009-11-20 17:40 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <4B0642F2.7060308@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 20 Nov 2009 08:19:14 +0100
>> Please fix this up and resubmit both of your patches.
>
> I've just resent the second patch:
> [PATCH (RESENT)] stmmac: do not fail when the timer cannot be used.
> Let me know if I have to review something in my first patch as well.
I explicitly asked you to resubmit both patches, so that I would have
them in a group together to apply to my tree.
When changes are requested in some patches within a group, I mark
the entire group in patchwork with state 'changed requested' and
that's why I ask for the whole series to be resubmitted.
This means you should have resent the first patch even though I did
not ask you to make any changes to it.
^ permalink raw reply
* Re: [PATCH 1/7] via-velocity: Correct setting of skipped checksums
From: David Miller @ 2009-11-20 17:36 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, shemminger, romieu
In-Reply-To: <20091120161205.6ddeb3ff@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Fri, 20 Nov 2009 16:12:05 +0100
> (Taken from the VIA driver). Check that this is actually an UDP or TCP
> packet before claiming that the checksum is unnecessary.
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
Why would the chip specifically say UDP or TCP checksum is OK
on a packet that is not of said protocol type?
Just wondering...
^ permalink raw reply
* Re: [PATCH 4/7] via-velocity: Implement NAPI support
From: David Miller @ 2009-11-20 17:35 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, shemminger, romieu
In-Reply-To: <20091120161223.10d01fd9@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Fri, 20 Nov 2009 16:12:23 +0100
> This patch adds NAPI support for VIA velocity. The new velocity_poll
> function also pairs tx/rx handling twice which improves perforamance on
> some workloads (e.g., netperf UDP_STREAM) significantly (that part is
> from the VIA driver).
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
With NAPI support present, your patch #3 should almost be not
necessary at all.
And if it is, make sure that you only use very low HW interrupt
mitigation settings.
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Dhananjay Phadke @ 2009-11-20 17:30 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha,
Ameen Rahman
In-Reply-To: <m1tywprvl4.fsf@fess.ebiederm.org>
> Weird. MSI's definitely weren't disabled. Looking a little farther at
> your quoted setup MSI work on your board. This is definitely
> something specific to the driver. Except for a few initialization
> races that are an issue for bonding I am running 2.6.31 just fine.
Jens,
Even if /proc/interrupt says PCI-MSI in both cases, single interrupt
case is msi vs. 4 vector case is msi-x. To confirm that msi-x doesn't
work with your card/machine, you can still stay on 2.6.31 and set
use_msi_x=0 in netxen_nic_main.c.
I had tried to make a available a module param to disable msi/msi-x for
platforms where msi-x doesn't work cleanly, but it was declined by David
Miller, et al.
Anyway, please note a few things -
Jens' has older generation (NX2031) of nic asic, so 4.0.xxx FW doesn't
apply:
NetXen XGb XFP Board S/N IF72MK0200 Chip rev 0x25
Eric has newer generation (NX3031) of nic asic:
NetXen Dual XGb SFP+ LP Board S/N SF86BK0008 Chip rev 0x41
Anyhow, what I learned here is Jens obtained firmware from IBM Japan.
Could you please describe the source of your device, you should involve
respective OEM (HP/IBM) for getting right revision of the firmware.
If it was purchased via direct channel, call QLogic support about
3.4.339 firmware. I can't imagine IBM Japan hosting firmware not
released for IBM branded NIC boards.
Thanks,
Dhananjay
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 7/7 RFC] TCPCT part 1g: Responder Cookie => Initiator
From: David Miller @ 2009-11-20 17:31 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06B080.3000404@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 10:06:40 -0500
> /* RFC1323: H1. Apply PAWS check first. */
> - if (tcp_fast_parse_options(skb, th, tp) && tp->rx_opt.saw_tstamp &&
> - tcp_paws_discard(sk, skb)) {
> + if (tcp_fast_parse_options(skb, th, tp, &hash_location)
> + && tp->rx_opt.saw_tstamp
> + && tcp_paws_discard(sk, skb)) {
Please fix this conditional's coding style. The '&&' belongs at
the end of the previous line not at the beginning of the next
one. Also the indentation is not correct.
> +
> + if (cvp != NULL
> + && cvp->cookie_pair_size > 0
> + && tp->rx_opt.cookie_plus > 0) {
Likewise.
> + if (tmp_opt.cookie_plus > 0
> + && tmp_opt.saw_tstamp
> + && !tp->rx_opt.cookie_out_never
> + && (sysctl_tcp_cookie_size > 0
> + || (tp->cookie_values != NULL
> + && tp->cookie_values->cookie_desired > 0))) {
Likewise.
> + /* Similar rationale to tcp_syn_options() applies here, too.
> + * If the <SYN> options fit, the same options should fit now!
> + */
> + if (*md5 == NULL
> + && doing_ts
> + && cookie_plus > TCPOLEN_COOKIE_BASE) {
Likewise.
> + if (cvp != NULL
> + && cvp->s_data_constant
> + && cvp->s_data_desired > 0) {
Likewise.
> + if (tmp_opt.cookie_plus > 0
> + && tmp_opt.saw_tstamp
> + && !tp->rx_opt.cookie_out_never
> + && (sysctl_tcp_cookie_size > 0
> + || (tp->cookie_values != NULL
> + && tp->cookie_values->cookie_desired > 0))) {
Likewise.
Thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 6/7 RFC] TCPCT part 1f: Initiator Cookie => Responder
From: David Miller @ 2009-11-20 17:29 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06ADF1.2010107@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 09:55:45 -0500
> + u8 cookie_size = (!tp->rx_opt.cookie_out_never && cvp != NULL)
> + ? tcp_cookie_size_check(cvp->cookie_desired)
> + : 0;
Please put the "?" and ":" and the end of the previous line not
at the beginning of the next one.
>
> + if (*md5 == NULL
> + && (OPTION_TS & opts->options)
> + && cookie_size > 0) {
Please fix up the coding style of this conditional. The '&&'
belongs at the end of the previous line and the indentation is
not correct here.
Thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 5/7 RFC] TCPCT part 1e: implement socket option TCP_COOKIE_TRANSACTIONS
From: David Miller @ 2009-11-20 17:26 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06AC2C.3070102@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 09:48:12 -0500
> + if (ctd.tcpct_used > sizeof(ctd.tcpct_value)
> + || ctd.tcpct_s_data_desired > TCP_MSS_DESIRED)
> + return -EINVAL;
Please fix this conditional coding style.
> + } else if ((0x1 & ctd.tcpct_cookie_desired)
> + || ctd.tcpct_cookie_desired > TCP_COOKIE_MAX
> + || ctd.tcpct_cookie_desired < TCP_COOKIE_MIN) {
> + return -EINVAL;
Same here.
> + if (ctd.tcpct_used > 0
> + || (tp->cookie_values == NULL
> + && (sysctl_tcp_cookie_size > 0
> + || ctd.tcpct_cookie_desired > 0
> + || ctd.tcpct_s_data_desired > 0))) {
Please fix the conditional coding style, and the alignment of
the lines, it's not right here.
> + ctd.tcpct_flags = (tp->rx_opt.cookie_in_always
> + ? TCP_COOKIE_IN_ALWAYS : 0)
> + | (tp->rx_opt.cookie_out_never
> + ? TCP_COOKIE_OUT_NEVER : 0);
"?" should be at end of previous line not at beginning of
next one, please fix this up.
Thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: David Miller @ 2009-11-20 17:25 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06A9D4.8070007@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 09:38:12 -0500
> static inline void tcp_clear_options(struct tcp_options_received *rx_opt)
> {
> - rx_opt->tstamp_ok = rx_opt->sack_ok = rx_opt->wscale_ok = rx_opt->snd_wscale = 0;
> + rx_opt->tstamp_ok = rx_opt->sack_ok = 0;
> + rx_opt->wscale_ok = rx_opt->snd_wscale = 0;
> + rx_opt->cookie_plus = 0;
> }
>
Why not get the coding style correct wrt. long lines in patch #3 where
you initially added this function, rather than fixing it here as you
add the new ->cookie_plus assignment?
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 3/7 RFC] TCPCT part 1c: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS
From: David Miller @ 2009-11-20 17:24 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06A8CF.3000303@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 09:33:51 -0500
> @@ -59,6 +59,14 @@ int sysctl_tcp_base_mss __read_mostly = 512;
> /* By default, RFC2861 behavior. */
> int sysctl_tcp_slow_start_after_idle __read_mostly = 1;
>
> +#ifdef CONFIG_SYSCTL
> +/* By default, let the user enable it. */
> +int sysctl_tcp_cookie_size __read_mostly = 0;
> +#else
> +int sysctl_tcp_cookie_size __read_mostly = TCP_COOKIE_MAX;
> +#endif
> +
I would prefer if the default did not depend upon whether
SYSCTL is enabled or not. That's extremely non-intuitive.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 2/7 RFC] TCPCT part 1b: generate Responder Cookie secret
From: David Miller @ 2009-11-20 17:22 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06A659.3020109@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 09:23:21 -0500
> +static DEFINE_SPINLOCK(tcp_secret_locker);
So connection creation scalability will be limited now because
we'll always have to go through this centralized spinlock even
for independent listening sockets, right?
Just wondering...
^ permalink raw reply
* Re: [net-next-2.6 PATCH v7 1/7 RFC] TCPCT part 1a: add request_values parameter for sending SYNACK
From: David Miller @ 2009-11-20 17:20 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4B06A3BD.8090804@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Fri, 20 Nov 2009 09:12:13 -0500
> - if (tcp_v6_send_synack(sk, req))
> - goto drop;
> + if (tcp_v6_send_synack(sk, req, NULL)
> + || want_cookie)
> + goto drop_and_free;
Please fix the coding style here, the "||" belongs at the end
of the previous line, not at the start of the next one.
Also, since it will all fit one one line anyways, please make
it that way:
if (tcp_v6_send_synack(sk, req, NULL) || want_cookie)
Some of us still use 80x25 terminals to read code :-)
I think you've been asked to fix this specific kinds of cases up
before.
Thanks a lot.
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Tom Herbert @ 2009-11-20 17:08 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, netdev
In-Reply-To: <20091119095730.GA7661@ff.dom.local>
> The description reads: "This solution queues packets early on in the
> receive path on the backlog queues of other CPUs.", so I'm not sure
> it's intended.
That is precisely the intent. Getting packets quickly distributed to
the target cpus maximizes parallelism and reduces latency.
Did you test it like this (and it was visibly worse)?:
>
> if (cpu < 0 || cpu == smp_processor_id())
>
>> + return __netif_receive_skb(skb);
>> + else
>> + return enqueue_to_backlog(skb, cpu);
>> +}
>> +
This increases overall latency due to head of line blocking which will
outweigh the benefits of optimizing for this one case.
Tom
^ permalink raw reply
* Re: [PATCH 3/7] via-velocity: Enable support for adaptive interrupt supression
From: Stephen Hemminger @ 2009-11-20 17:05 UTC (permalink / raw)
To: Simon Kagstrom; +Cc: netdev, davem, davej, romieu
In-Reply-To: <20091120161217.45e611a6@marrow.netinsight.se>
On Fri, 20 Nov 2009 16:12:17 +0100
Simon Kagstrom <simon.kagstrom@netinsight.net> wrote:
> (From the upstream VIA driver). This reduces the amount of interrupts
> under load and improves performance by quite a bit by reducing the
> amount of work for the CPU.
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> ---
> drivers/net/via-velocity.c | 70 +++++++++++++++++++++++++++++++++++++++++++-
> drivers/net/via-velocity.h | 7 ++++-
> 2 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
> index 944a678..932339b 100644
> --- a/drivers/net/via-velocity.c
> +++ b/drivers/net/via-velocity.c
> @@ -364,6 +364,26 @@ static int rx_copybreak = 200;
> module_param(rx_copybreak, int, 0644);
> MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for copy-only-tiny-frames");
>
> +#define TXQUEUE_TIMER_DEF 0x59
> +#define TXQUEUE_TIMER_MIN 0x00
> +#define TXQUEUE_TIMER_MAX 0xFF
> +VELOCITY_PARAM(txqueue_timer, "Tx Queue Empty defer timer");
> +
> +#define RXQUEUE_TIMER_DEF 0x14
> +#define RXQUEUE_TIMER_MIN 0x00
> +#define RXQUEUE_TIMER_MAX 0xFF
> +VELOCITY_PARAM(rxqueue_timer, "Rx Queue Empty defer timer");
> +
> +#define TX_INTSUP_DEF 0x1F
> +#define TX_INTSUP_MIN 0x01
> +#define TX_INTSUP_MAX 0x3F
> +VELOCITY_PARAM(tx_intsup, "Tx Interrupt Suppression Threshold");
> +
> +#define RX_INTSUP_DEF 0x1F
> +#define RX_INTSUP_MIN 0x01
> +#define RX_INTSUP_MAX 0x3F
> +VELOCITY_PARAM(rx_intsup, "Rx Interrupt Suppression Threshold");
> +
> #ifdef CONFIG_PM
> static DEFINE_SPINLOCK(velocity_dev_list_lock);
> static LIST_HEAD(velocity_dev_list);
> @@ -517,6 +537,10 @@ static void __devinit velocity_get_options(struct velocity_opt *opts, int index,
> velocity_set_int_opt((int *) &opts->spd_dpx, speed_duplex[index], MED_LNK_MIN, MED_LNK_MAX, MED_LNK_DEF, "Media link mode", devname);
> velocity_set_int_opt((int *) &opts->wol_opts, wol_opts[index], WOL_OPT_MIN, WOL_OPT_MAX, WOL_OPT_DEF, "Wake On Lan options", devname);
> velocity_set_int_opt((int *) &opts->int_works, int_works[index], INT_WORKS_MIN, INT_WORKS_MAX, INT_WORKS_DEF, "Interrupt service works", devname);
> + velocity_set_int_opt((int *) &opts->txqueue_timer, txqueue_timer[index], TXQUEUE_TIMER_MIN, TXQUEUE_TIMER_MAX, TXQUEUE_TIMER_DEF, "TX queue empty defer timer", devname);
> + velocity_set_int_opt((int *) &opts->rxqueue_timer, rxqueue_timer[index], RXQUEUE_TIMER_MIN, RXQUEUE_TIMER_MAX, RXQUEUE_TIMER_DEF, "RX queue empty defer timer", devname);
> + velocity_set_int_opt((int *) &opts->tx_intsup, tx_intsup[index], TX_INTSUP_MIN, TX_INTSUP_MAX, TX_INTSUP_DEF, "TX interrupt suppression threshold", devname);
> + velocity_set_int_opt((int *) &opts->rx_intsup, rx_intsup[index], RX_INTSUP_MIN, RX_INTSUP_MAX, RX_INTSUP_DEF, "RX interrupt suppression threshold", devname);
> opts->numrx = (opts->numrx & ~3);
> }
This should be done via ethtool irq coalescing settings not more module paramets.
--
^ permalink raw reply
* Re: [PATCH 0/7] via-velocity performance fixes
From: Stephen Hemminger @ 2009-11-20 17:03 UTC (permalink / raw)
To: Simon Kagstrom; +Cc: netdev, davem, davej, romieu
In-Reply-To: <20091120160633.77b7aee0@marrow.netinsight.se>
On Fri, 20 Nov 2009 16:06:33 +0100
Simon Kagstrom <simon.kagstrom@netinsight.net> wrote:
> 1. Correct setting of skipped checksums (unsure about this). The
> mainline driver sets CHECKSUM_UNNECESSARY if this is an IP packet
> except if the TCP checksum is NOT ok.
>
> The VIA driver sets CHECKSUM_UNNECESSARY if this is an UDP/TCP
> packet except if the TCP checksum is not OK. The patch selects the
> VIA behavior.
This doesn't seem correct.
The mainline driver is already doing the correct thing.
The VIA driver would send packet
with known bad checksum up the stack with CHECKSUM_UNNECESSARY.
What is supposed to happen is:
Checksum good: set CHECKSUM_UNNECESSARY
bad: leave CHECKSUM_NONE
This is all documented in skbuff.h
--
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Eric W. Biederman @ 2009-11-20 16:48 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: Dhananjay Phadke, netdev@vger.kernel.org, Amit Salecha
In-Reply-To: <20091120075258.GM14661@jayr.de>
Jens Rosenboom <me@jayr.de> writes:
> On Thu, Nov 19, 2009 at 05:19:05PM -0800, Eric W. Biederman wrote:
>> Jens Rosenboom <me@jayr.de> writes:
>>
>> > On Thu, Nov 19, 2009 at 10:07:21AM -0800, Dhananjay Phadke wrote:
>> >> > My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1.
>> >> > With the
>> >> > newer kernel I can see packets been received on the switch it is
>> >> > connected to, but
>> >> > the kernel doesn't report any sent packets in the interface counters and
>> >> > nothing
>> >> > is being received either.
>> >> >
>> >> > I've tried to bisect this, but only seems the end up with kernels that do
>> >> > not boot
>> >> > at all because some SCSI stuff goes bad.
>> >>
>> >> Any particular reason for using -rc1 kernel and not 2.6.31 stable kernel?
>> >
>> > Sorry, I forgot to mention that all later kernels that I tested
>> > including 2.6.31 and the current net-2.6 also fail, so the badness
>> > comes in somewhere in between 2.6.30 and 2.6.31-rc1.
>> >
>> > I also noticed that the newer kernel allocate four interrupts for the
>> > card instead of only one, but none of them seem to get triggered, the
>> > /proc/interrupts counters all stay at zero.
>>
>> Hmm. Have you tried disabling msi's? aka putting nomsi on the kernel
>> command line.
>
> I hadn't before but tried it now, but no difference. The kernel still seems to
> allocate four interrupts:
Weird. MSI's definitely weren't disabled. Looking a little farther at
your quoted setup MSI work on your board. This is definitely
something specific to the driver. Except for a few initialization
races that are an issue for bonding I am running 2.6.31 just fine.
> kernel: [ 2.980300] bus: 'pci': add driver netxen_nic
> kernel: [ 2.980329] bus: 'pci': driver_probe_device: matched device 0000:22:00.0 with driver netxen_nic
> kernel: [ 2.980333] bus: 'pci': really_probe: probing driver netxen_nic with device 0000:22:00.0
> kernel: [ 2.980446] netxen_nic 0000:22:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> kernel: [ 2.980459] netxen_nic 0000:22:00.0: setting latency timer to 64
> kernel: [ 2.981505] netxen_nic 0000:22:00.0: 128MB memory map
> kernel: [ 2.981611] netxen_nic 0000:22:00.0: firmware: using built-in firmware nxromimg.bin
> kernel: [ 4.144018] netxen_nic 0000:22:00.0: loading firmware from nxromimg.bin
> kernel: [ 10.108208] NetXen XGb XFP Board S/N IF72MK0200 Chip rev 0x25
> kernel: [ 10.108211] netxen_nic 0000:22:00.0: firmware version 3.4.336
> kernel: [ 10.108262] alloc irq_desc for 37 on node 0
> kernel: [ 10.108265] alloc kstat_irqs on node 0
> kernel: [ 10.108273] netxen_nic 0000:22:00.0: irq 37 for MSI/MSI-X
> kernel: [ 10.108275] alloc irq_desc for 38 on node 0
> kernel: [ 10.108277] alloc kstat_irqs on node 0
> kernel: [ 10.108281] netxen_nic 0000:22:00.0: irq 38 for MSI/MSI-X
> kernel: [ 10.108284] alloc irq_desc for 39 on node 0
> kernel: [ 10.108286] alloc kstat_irqs on node 0
> kernel: [ 10.108289] netxen_nic 0000:22:00.0: irq 39 for MSI/MSI-X
> kernel: [ 10.108291] alloc irq_desc for 40 on node 0
> kernel: [ 10.108293] alloc kstat_irqs on node 0
> kernel: [ 10.108296] netxen_nic 0000:22:00.0: irq 40 for MSI/MSI-X
> kernel: [ 10.108311] netxen_nic 0000:22:00.0: using msi-x interrupts
> kernel: [ 10.108371] device: 'eth2': device_add
> kernel: [ 10.108442] PM: Adding info for No Bus:eth2
> kernel: [ 10.109197] netxen_nic 0000:22:00.0: eth2: XGbE port initialized
> kernel: [ 10.109219] driver: '0000:22:00.0': driver_bound: bound to device 'netxen_nic'
> kernel: [ 10.109226] bus: 'pci': really_probe: bound device 0000:22:00.0 to driver netxen_nic
>
> # grep eth2 /proc/interrupts
> 37: 0 0 0 0 PCI-MSI-edge eth2[0]
> 38: 0 0 0 0 PCI-MSI-edge eth2[1]
> 39: 0 0 0 0 PCI-MSI-edge eth2[2]
> 40: 0 0 0 0 PCI-MSI-edge eth2[3]
> # ethtool eth2
> Settings for eth2:
> Supported ports: [ FIBRE ]
> Supported link modes:
> Supports auto-negotiation: No
> Advertised link modes: 10000baseT/Full
> Advertised auto-negotiation: No
> Speed: 10000Mb/s
> Duplex: Full
> Port: FIBRE
> PHYAD: 0
> Transceiver: external
> Auto-negotiation: off
> Supports Wake-on: d
> Wake-on: d
> Link detected: yes
> # ethtool -i eth2
> driver: netxen_nic
> version: 4.0.30
> firmware-version: 3.4.336
> bus-info: 0000:22:00.0
> # uname -rvmpi
> 2.6.31.6 #5 SMP Wed Nov 18 09:15:48 CET 2009 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux
On my working setup I have:
driver: netxen_nic
version: 4.0.30
firmware-version: 4.0.305
bus-info: 0000:06:00.0
4.0.305 looks like the latest publicly available version on qlogic's
website. If that will work on your card I recommend you pull it down
and update your firmware.
My card is: NetXen Dual XGb SFP+ LP Board S/N SF86BK0008 Chip rev 0x41
Which is a bit different at the physical hardware level.
Eric
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] allow access to sysfs_groups member
From: Eric W. Biederman @ 2009-11-20 16:32 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: David Miller, netdev
In-Reply-To: <20091120102113.GC282@e-circ.dyndns.org>
Kurt Van Dijck <kurt.van.dijck@eia.be> writes:
> On Thu, Nov 19, 2009 at 05:11:45PM -0800, Eric W. Biederman wrote:
>> Kurt Van Dijck <kurt.van.dijck@eia.be> writes:
>>
>> > On Wed, Nov 18, 2009 at 01:08:59PM -0800, David Miller wrote:
>> >>
>> >> Unfortunately, the code in this function is much different
>> >> in net-next-2.6 which is where I want to add this, and your
>> >> patch doesn't apply.
>> >>
>> >> Please rebase your patch on that tree, thank you.
>> > As I mentioned, I'm not experienced with using git yet.
>> > Is there a fine manual I can inspect? I get lost in the man-pages.
>>
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
>>
>> Should get you started.
> $ git pull git://git.kernel.... master
> did the job today. It took me a while
An incremental pull typically much faster than the initial one.
>> In this case please look at how I modified the bonding driver to do
>> what you are trying to do. That is the conflict in net-next and
>> I think it was actually less code.
> It _is_ less code (does a little less too :-) ).
> It solves the problem anyway. I'll stop with my patch.
You were just worried about CAN devices and not all network devices
correct?
Eric
^ 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