* Re: [PATCH RFC 51/77] mthca: Update MSI/MSI-X interrupts enablement code
From: Jack Morgenstein @ 2013-10-03 16:11 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers,
"VMware, Inc." <pv-dr
In-Reply-To: <9d424912ef78993dc75e2af5006cd12913e9e7e7.1380703263.git.agordeev@redhat.com>
On Wed, 2 Oct 2013 12:49:07 +0200
Alexander Gordeev <agordeev@redhat.com> wrote:
> Subject: [PATCH RFC 51/77] mthca: Update MSI/MSI-X interrupts
> enablement code Date: Wed, 2 Oct 2013 12:49:07 +0200
> Sender: linux-rdma-owner@vger.kernel.org
> X-Mailer: git-send-email 1.7.7.6
>
> As result of recent re-design of the MSI/MSI-X interrupts enabling
> pattern this driver has to be updated to use the new technique to
> obtain a optimal number of MSI/MSI-X interrupts required.
>
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
ACK.
-Jack
^ permalink raw reply
* I NEED YOUR HELP.
From: FROM MRS GRACE MANDA @ 2013-10-03 16:36 UTC (permalink / raw)
In-Reply-To: <1380809157.62922.YahooMailNeo@web5706.biz.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
I PRAY THAT THIS MAIL GETS TO YOU IN BETTER HEALTH.
[-- Attachment #2: From Grace Manda.pdf --]
[-- Type: application/pdf, Size: 41077 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/2] sit: allow to use rtnl ops on fb tunnel
From: David Miller @ 2013-10-03 17:37 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, steffen.klassert, pshelar
In-Reply-To: <524D2580.9040702@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 03 Oct 2013 10:06:24 +0200
> In fact, I just notice that 3.9 branch is EoL (bug is only in 3.8 and
> 3.9).
> Should I still send a patch ? If yes, based on which tree/branch?
No stable backports are needed then.
^ permalink raw reply
* Re: [net-next 2/3] udp: Add udp early demux
From: Shawn Bohrer @ 2013-10-03 17:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, tomk, netdev
In-Reply-To: <1380749932.19002.127.camel@edumazet-glaptop.roam.corp.google.com>
On Wed, Oct 02, 2013 at 02:38:52PM -0700, Eric Dumazet wrote:
> I suggested that for unicast, you do a limited lookup to the first
> socket found in bucket.
>
> If its an exact match, you take the socket.
>
> If not, you give up, and do not scan the whole chain.
So something like the following?
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 02185a5..d202e5b 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1849,7 +1849,42 @@ begin:
}
rcu_read_unlock();
return result;
+}
+/* For unicast we should only early demux connected sockets or we can
+ * break forwarding setups. The chains here can be long so only check
+ * if the first socket is an exact match and if not move on.
+ */
+static struct sock *__udp4_lib_demux_lookup(struct net *net,
+ __be16 loc_port, __be32 loc_addr,
+ __be16 rmt_port, __be32 rmt_addr,
+ int dif)
+{
+ struct sock *sk, *result;
+ struct hlist_nulls_node *node;
+ unsigned short hnum = ntohs(loc_port);
+ unsigned int slot = udp_hashfn(net, hnum, udp_table.mask);
+ struct udp_hslot *hslot = &udp_table.hash[slot];
+ const int exact_match = 18;
+ int score;
+
+ rcu_read_lock();
+ result = NULL;
+ sk_nulls_for_each_rcu(sk, node, &hslot->head) {
+ score = compute_score(sk, net, rmt_addr, hnum, rmt_port,
+ loc_addr, loc_port, dif);
+ if (score == exact_match)
+ result = sk;
+ /* Only check first socket in chain */
+ break;
+ }
+
+ if (result) {
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
+ result = NULL;
+ }
+ rcu_read_unlock();
+ return result;
}
void udp_v4_early_demux(struct sk_buff *skb)
@@ -1870,8 +1905,8 @@ void udp_v4_early_demux(struct sk_buff *skb)
sk = __udp4_lib_mcast_demux_lookup(net, uh->dest, iph->daddr,
uh->source, iph->saddr, dif);
else if (skb->pkt_type == PACKET_HOST)
- sk = __udp4_lib_lookup(net, iph->saddr, uh->source,
- iph->daddr, uh->dest, dif, &udp_table);
+ sk = __udp4_lib_demux_lookup(net, uh->dest, iph->daddr,
+ uh->source, iph->saddr, dif);
else
return;
--
---------------------------------------------------------------
This email, along with any attachments, is confidential. If you
believe you received this message in error, please contact the
sender immediately and delete all copies of the message.
Thank you.
^ permalink raw reply related
* Fw: [Bug 62491] New: alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff
From: Stephen Hemminger @ 2013-10-03 17:40 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook, Johannes Berg; +Cc: netdev
Begin forwarded message:
Date: Thu, 3 Oct 2013 10:21:34 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 62491] New: alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff
https://bugzilla.kernel.org/show_bug.cgi?id=62491
Bug ID: 62491
Summary: alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff
Product: Networking
Version: 2.5
Kernel Version: 3.12-rc3
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: vaniaz@msn.com
Regression: No
Hardware: lenovo g780 using alx network driver; software - opensuse tambleweed
with kernel 3.12-rc3.
After entering sleep mode and waking up console at alt + f is flooding with
messages like:
[672.000000] alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH RFC 59/77] qla2xxx: Update MSI/MSI-X interrupts enablement code
From: Saurav Kashyap @ 2013-10-03 17:42 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux390@de.ibm.com,
linux-s390@vger.kernel.org, x86@kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <54f6b89372f51cd27a6adf6ecc91b8bf6bb5ba74.1380703263.git.agordeev@redhat.com>
Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
>As result of recent re-design of the MSI/MSI-X interrupts enabling
>pattern this driver has to be updated to use the new technique to
>obtain a optimal number of MSI/MSI-X interrupts required.
>
>Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
>---
> drivers/scsi/qla2xxx/qla_isr.c | 18 +++++++++++-------
> 1 files changed, 11 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/qla2xxx/qla_isr.c
>b/drivers/scsi/qla2xxx/qla_isr.c
>index df1b30b..6c11ab9 100644
>--- a/drivers/scsi/qla2xxx/qla_isr.c
>+++ b/drivers/scsi/qla2xxx/qla_isr.c
>@@ -2836,16 +2836,20 @@ qla24xx_enable_msix(struct qla_hw_data *ha,
>struct rsp_que *rsp)
> for (i = 0; i < ha->msix_count; i++)
> entries[i].entry = i;
>
>- ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
>- if (ret) {
>+ ret = pci_msix_table_size(ha->pdev);
>+ if (ret < 0) {
>+ goto msix_failed;
>+ } else {
> if (ret < MIN_MSIX_COUNT)
> goto msix_failed;
>
>- ql_log(ql_log_warn, vha, 0x00c6,
>- "MSI-X: Failed to enable support "
>- "-- %d/%d\n Retry with %d vectors.\n",
>- ha->msix_count, ret, ret);
>- ha->msix_count = ret;
>+ if (ret < ha->msix_count) {
>+ ql_log(ql_log_warn, vha, 0x00c6,
>+ "MSI-X: Failed to enable support "
>+ "-- %d/%d\n Retry with %d vectors.\n",
>+ ha->msix_count, ret, ret);
>+ ha->msix_count = ret;
>+ }
> ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
> if (ret) {
> msix_failed:
>--
>1.7.7.6
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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] dev: add support of flag IFF_NOPROC
From: Stephen Hemminger @ 2013-10-03 17:46 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1380806905-4461-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, 3 Oct 2013 15:28:25 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> This flag allows to create netdevices without creating directories in
> /proc, ie no /proc/sys/net/ipv[4|6]/[conf|neigh]/<dev> and no
> /proc/net/dev_snmp6/<dev>.
>
> When a system creates a lot of virtual netdevices, this allows to speed up the
> creation time. For systems which continuously create and destroy virtual
> netdevices, proc entries for these netdevices may not be used, hence adding this
> flag is interesting.
>
> Note that the flag should be specified at the creation time (before calling
> register_netdevice()) and cannot be removed during the life of the netdevice.
>
> Here are some numbers:
>
> dummy20000.batch contains 20 000 times 'link add type dummy' and
> dummy20000-noproc.batch 20 000 times 'link add noproc type dummy'.
>
> time ip -b dummy20000.batch
> real 0m56.367s
> user 0m0.200s
> sys 0m53.070s
>
> time ip -b dummy20000-noproc.batch
> real 0m42.417s
> user 0m0.310s
> sys 0m38.470s
>
> Suggested-by: Thierry Herbelot <thierry.herbelot@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Seems like a special case. The problem is that you just created devices
that are unmanageable and might well break other tools in the system.
What about speeding up proc or sysfs? Or providing a bulk create/destroy.
Also if you used a custom program it could have seperate netlink send
and receive threads to pipeline the creation.
^ permalink raw reply
* Re: [net-next 2/3] udp: Add udp early demux
From: Eric Dumazet @ 2013-10-03 18:06 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: David Miller, tomk, netdev
In-Reply-To: <20131003173946.GA5684@sbohrermbp13-local.rgmadvisors.com>
On Thu, 2013-10-03 at 12:39 -0500, Shawn Bohrer wrote:
> On Wed, Oct 02, 2013 at 02:38:52PM -0700, Eric Dumazet wrote:
> > I suggested that for unicast, you do a limited lookup to the first
> > socket found in bucket.
> >
> > If its an exact match, you take the socket.
> >
> > If not, you give up, and do not scan the whole chain.
>
> So something like the following?
>
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 02185a5..d202e5b 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1849,7 +1849,42 @@ begin:
> }
> rcu_read_unlock();
> return result;
> +}
>
> +/* For unicast we should only early demux connected sockets or we can
> + * break forwarding setups. The chains here can be long so only check
> + * if the first socket is an exact match and if not move on.
> + */
> +static struct sock *__udp4_lib_demux_lookup(struct net *net,
> + __be16 loc_port, __be32 loc_addr,
> + __be16 rmt_port, __be32 rmt_addr,
> + int dif)
> +{
> + struct sock *sk, *result;
> + struct hlist_nulls_node *node;
> + unsigned short hnum = ntohs(loc_port);
> + unsigned int slot = udp_hashfn(net, hnum, udp_table.mask);
> + struct udp_hslot *hslot = &udp_table.hash[slot];
> + const int exact_match = 18;
> + int score;
> +
> + rcu_read_lock();
> + result = NULL;
> + sk_nulls_for_each_rcu(sk, node, &hslot->head) {
> + score = compute_score(sk, net, rmt_addr, hnum, rmt_port,
> + loc_addr, loc_port, dif);
> + if (score == exact_match)
> + result = sk;
> + /* Only check first socket in chain */
> + break;
> + }
> +
> + if (result) {
> + if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
> + result = NULL;
> + }
> + rcu_read_unlock();
> + return result;
> }
>
Just do the tuple comparison instead of compute_score(),
since you know we want full L4 match.
The standard way is to use the INET_MATCH() macro
^ permalink raw reply
* Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Ben Greear @ 2013-10-03 18:27 UTC (permalink / raw)
To: netdev, linux-wireless@vger.kernel.org
I'm seeing something a bit strange and wondering if anyone had an opinion on why...
I am testing up to 200 wifi station systems, each with a TCP connection running
on them (download only, from VAP to stations).
Without encryption (ie, open network), I see total throughput go from
about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
However, if I enable encryption, the throughput is actually higher
(111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
bit of CPU load in this test. The numbers bounce around since this is
wifi after all, but in general encryption tends to win reliably in this
test.
When testing with a single station (and 5 tcp streams with jacked up snd/rcv buffers)
the open networks perform significantly better at total throughput: 263Mbps vs 246Mbps.
Maybe the extra delay for decryption increases odds that GRO will take
affect for the many, slower streams (and maybe that will decrease ACK traffic?)
Any other ideas?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [stable 3.0] add some CVE fixes
From: Greg KH @ 2013-10-03 18:44 UTC (permalink / raw)
To: Jiri Slaby; +Cc: stable, netdev
In-Reply-To: <524D36DC.5070506@suse.cz>
On Thu, Oct 03, 2013 at 11:20:28AM +0200, Jiri Slaby wrote:
> Hi,
>
> could you consider adding fixes for the following CVEs to 3.0 (and
> possibly later)?
> CVE-2013-4163: 75a493e60ac4bbe2e977e7129d6d8cbb0dd236be
> CVE-2013-2206: f2815633504b442ca0b0605c16bf3d88a3a0fcea
Network patches for stable releases need to be asked of the networking
maintainer, who then forwards them on to me.
> Plus the backports that are replied to this mail?
I don't see any backports, did you forget to send them?
thanks,
greg k-h
^ permalink raw reply
* Re: Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Rick Jones @ 2013-10-03 18:50 UTC (permalink / raw)
To: Ben Greear, netdev,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <524DB6F6.6020405-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On 10/03/2013 11:27 AM, Ben Greear wrote:
> I'm seeing something a bit strange and wondering if anyone had an
> opinion on why...
>
> I am testing up to 200 wifi station systems, each with a TCP connection
> running on them (download only, from VAP to stations).
>
> Without encryption (ie, open network), I see total throughput go from
> about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
> so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
>
> However, if I enable encryption, the throughput is actually higher
> (111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
> bit of CPU load in this test. The numbers bounce around since this is
> wifi after all, but in general encryption tends to win reliably in this
> test.
>
> When testing with a single station (and 5 tcp streams with jacked up
> snd/rcv buffers) the open networks perform significantly better at total throughput:
> 263Mbps vs 246Mbps.
>
> Maybe the extra delay for decryption increases odds that GRO will take
> affect for the many, slower streams (and maybe that will decrease ACK
> traffic?)
>
> Any other ideas?
Fewer times two or more stations step on one another? The recievers
will only try to transmit when they receive data. Modulo timing, if the
individual downloads are a bit slower, less chance of the receivers
looking to send ACKs back through at the same time? Got any low-level
stats for the health and well being of the wireless network?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] dev: add support of flag IFF_NOPROC
From: David Miller @ 2013-10-03 19:09 UTC (permalink / raw)
To: stephen; +Cc: nicolas.dichtel, netdev
In-Reply-To: <20131003104627.411f5cc4@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 3 Oct 2013 10:46:27 -0700
> What about speeding up proc or sysfs? Or providing a bulk create/destroy.
+1 +1 +1
This will benefit more people than the just the envisioned users for
this IFF_NOPROC thing.
I really don't want to take the IFF_NOPROC approach.
^ permalink raw reply
* Re: [stable 3.0] add some CVE fixes
From: Jiri Slaby @ 2013-10-03 19:11 UTC (permalink / raw)
To: Greg KH; +Cc: stable, netdev
In-Reply-To: <20131003184411.GG8901@kroah.com>
On 10/03/2013 08:44 PM, Greg KH wrote:
> On Thu, Oct 03, 2013 at 11:20:28AM +0200, Jiri Slaby wrote:
>> Plus the backports that are replied to this mail?
>
> I don't see any backports, did you forget to send them?
I don't think so, they were sent and this is a log of one of them:
OK. Log says:
Sendmail: /usr/sbin/sendmail -f jslaby@suse.cz -i stable@vger.kernel.org
jslaby@suse.cz
From: Jiri Slaby <jslaby@suse.cz>
To: <stable@vger.kernel.org>
Cc: jslaby@suse.cz
Subject: [PATCH 4/4] Tools: hv: verify origin of netlink connector message
Date: Thu, 3 Oct 2013 11:23:50 +0200
Message-Id: <1380792230-27255-4-git-send-email-jslaby@suse.cz>
X-Mailer: git-send-email 1.8.4
In-Reply-To: <1380792230-27255-1-git-send-email-jslaby@suse.cz>
References: <524D36DC.5070506@suse.cz>
<1380792230-27255-1-git-send-email-jslaby@suse.cz>
Result: OK
Could you check your spam folder? Or I can bounce them directly to you?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: Ideas on why using WPA2 encryption speeds up many TCP connections?
From: Ben Greear @ 2013-10-03 19:17 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, linux-wireless@vger.kernel.org
In-Reply-To: <524DBC93.1070400@hp.com>
On 10/03/2013 11:50 AM, Rick Jones wrote:
> On 10/03/2013 11:27 AM, Ben Greear wrote:
>> I'm seeing something a bit strange and wondering if anyone had an
>> opinion on why...
>>
>> I am testing up to 200 wifi station systems, each with a TCP connection
>> running on them (download only, from VAP to stations).
>>
>> Without encryption (ie, open network), I see total throughput go from
>> about 108Mbps down to 69Mbps as I add more stations (I add 25 at a time,
>> so the 108Mbps is with 25 active, and 69Mbps is with 200 active).
>>
>> However, if I enable encryption, the throughput is actually higher
>> (111Mbps to 71Mbps). I'm doing encryption in software, so it adds a fair
>> bit of CPU load in this test. The numbers bounce around since this is
>> wifi after all, but in general encryption tends to win reliably in this
>> test.
>>
>> When testing with a single station (and 5 tcp streams with jacked up
>> snd/rcv buffers) the open networks perform significantly better at total throughput:
>> 263Mbps vs 246Mbps.
>>
>> Maybe the extra delay for decryption increases odds that GRO will take
>> affect for the many, slower streams (and maybe that will decrease ACK
>> traffic?)
>>
>> Any other ideas?
>
> Fewer times two or more stations step on one another? The recievers will only try to transmit when they receive data. Modulo timing, if the individual
> downloads are a bit slower, less chance of the receivers looking to send ACKs back through at the same time? Got any low-level stats for the health and well
> being of the wireless network?
The tcp connection stats are taken after running for 60 seconds, and I take 3-sec running averages
as well as 60 second averages. So, I think that it would have to be total decrease in ACKs,
not just timing, to make a difference. The 3 and 60 second stats show consistently higher throughput
with encryption when using 25+ stations/connections.
Also, it works out that the sending sockets all sort of send randomly as they
are able, so I don't think there would be any particular ACK flood seen..
I have great quantities of low level stats, but I have not dug into them in detail
just yet. In general, my RF environment in this test is fairly controlled, as
I am cabling the systems using good semi-rigid SMA cables and an RF attenuator.
There will be some external interference of course, as they are not in an
isolation chamber.
As for the difference in 1 stations vs 25+, then it is very likely related to
low level things like MPDU working better with a single station, and probably
better ACK avoidance (I recall about 20kpps download, 4kpps upload in a previous
test with a single station, which indicates to me we must not be acking every
packet-on-the-air..somehow).
(For grins, I played with the delayed-ack-segs from an out-of-tree patch and
can get TCP throughput up to 300Mbps by setting delayed ack segs to 64 in
single station/5 stream, open network test).
Thanks,
Ben
>
> rick jones
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] atl1e: enable support for NETIF_F_RXALL and NETIF_F_RXCRC features
From: Andrea Merello @ 2013-10-03 19:18 UTC (permalink / raw)
To: jie.yang, xiong.huang; +Cc: davem, netdev, linux-kernel, Andrea Merello
This patch allows (optionally, via ethtool) the atl1e NIC to:
- Receive bad frames (runt, bad-fcs, etc..)
- Receive full frames without stripping the FCS.
This has been tested on my board by injecting runt and bad-fcs
frames with a FPGA-based device.
The particular scenario of receiving very short frames (<4 bytes)
without passing FCS to the upper layer has been also tested:
This could be potentially dangerous because the driver performs a
4 byte subtraction on the frame length, but I finally have NOT
added anything to avoid this because it seems the NIC always
discards frames so much short..
If someone still have some reason to worry about this, please
tell me.. I will add an explicit SW check..
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 46 ++++++++++++++++++++++---
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 1966444..7a73f3a 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -313,6 +313,34 @@ static void atl1e_set_multi(struct net_device *netdev)
}
}
+static void __atl1e_rx_mode(netdev_features_t features, u32 *mac_ctrl_data)
+{
+
+ if (features & NETIF_F_RXALL) {
+ /* enable RX of ALL frames */
+ *mac_ctrl_data |= MAC_CTRL_DBG;
+ } else {
+ /* disable RX of ALL frames */
+ *mac_ctrl_data &= ~MAC_CTRL_DBG;
+ }
+}
+
+static void atl1e_rx_mode(struct net_device *netdev,
+ netdev_features_t features)
+{
+ struct atl1e_adapter *adapter = netdev_priv(netdev);
+ u32 mac_ctrl_data = 0;
+
+ netdev_dbg(adapter->netdev, "%s\n", __func__);
+
+ atl1e_irq_disable(adapter);
+ mac_ctrl_data = AT_READ_REG(&adapter->hw, REG_MAC_CTRL);
+ __atl1e_rx_mode(features, &mac_ctrl_data);
+ AT_WRITE_REG(&adapter->hw, REG_MAC_CTRL, mac_ctrl_data);
+ atl1e_irq_enable(adapter);
+}
+
+
static void __atl1e_vlan_mode(netdev_features_t features, u32 *mac_ctrl_data)
{
if (features & NETIF_F_HW_VLAN_CTAG_RX) {
@@ -394,6 +422,10 @@ static int atl1e_set_features(struct net_device *netdev,
if (changed & NETIF_F_HW_VLAN_CTAG_RX)
atl1e_vlan_mode(netdev, features);
+ if (changed & NETIF_F_RXALL)
+ atl1e_rx_mode(netdev, features);
+
+
return 0;
}
@@ -1057,7 +1089,8 @@ static void atl1e_setup_mac_ctrl(struct atl1e_adapter *adapter)
value |= MAC_CTRL_PROMIS_EN;
if (netdev->flags & IFF_ALLMULTI)
value |= MAC_CTRL_MC_ALL_EN;
-
+ if (netdev->features & NETIF_F_RXALL)
+ value |= MAC_CTRL_DBG;
AT_WRITE_REG(hw, REG_MAC_CTRL, value);
}
@@ -1405,7 +1438,8 @@ static void atl1e_clean_rx_irq(struct atl1e_adapter *adapter, u8 que,
rx_page_desc[que].rx_nxseq++;
/* error packet */
- if (prrs->pkt_flag & RRS_IS_ERR_FRAME) {
+ if ((prrs->pkt_flag & RRS_IS_ERR_FRAME) &&
+ !(netdev->features & NETIF_F_RXALL)) {
if (prrs->err_flag & (RRS_ERR_BAD_CRC |
RRS_ERR_DRIBBLE | RRS_ERR_CODE |
RRS_ERR_TRUNC)) {
@@ -1418,7 +1452,10 @@ static void atl1e_clean_rx_irq(struct atl1e_adapter *adapter, u8 que,
}
packet_size = ((prrs->word1 >> RRS_PKT_SIZE_SHIFT) &
- RRS_PKT_SIZE_MASK) - 4; /* CRC */
+ RRS_PKT_SIZE_MASK);
+ if (likely(!(netdev->features & NETIF_F_RXFCS)))
+ packet_size -= 4; /* CRC */
+
skb = netdev_alloc_skb_ip_align(netdev, packet_size);
if (skb == NULL)
goto skip_pkt;
@@ -2245,7 +2282,8 @@ static int atl1e_init_netdev(struct net_device *netdev, struct pci_dev *pdev)
NETIF_F_HW_VLAN_CTAG_RX;
netdev->features = netdev->hw_features | NETIF_F_LLTX |
NETIF_F_HW_VLAN_CTAG_TX;
-
+ /* not enabled by default */
+ netdev->hw_features |= NETIF_F_RXALL | NETIF_F_RXFCS;
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
From: David Miller @ 2013-10-03 19:29 UTC (permalink / raw)
To: hns; +Cc: j.dumon, marek.belisko, linux-usb, netdev, linux-kernel
In-Reply-To: <B1808224-5850-41E3-9A8F-0F350F84FF89@goldelico.com>
From: "Dr. H. Nikolaus Schaller" <hns@goldelico.com>
Date: Wed, 2 Oct 2013 09:00:18 +0200
> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: Thu, 15 Nov 2012 14:40:57 +0100
> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
> GTM601 during RING indication
>
> It has been observed that the GTM601 with 1.7 firmware sometimes sends a value
> wIndex that has bit 0x04 set instead of being reset as the code expects. So we
> mask it for the error check.
>
> See http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>
> Signed-off-by: NeilBrown <neilb@suse.de>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.de>
I think we should look more deeply into what this bit might mean
and why the firmware might be setting it before we even consider
applying a patch like this one.
^ permalink raw reply
* Re: [PATCH net-next] tcp: shrink tcp6_timewait_sock by one cache line
From: David Miller @ 2013-10-03 19:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380711604.19002.78.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 02 Oct 2013 04:00:04 -0700
> + tmo = tw->tw_ttd - (u32)jiffies;
...
> + tw->tw_ttd = (u32)(jiffies + timeo);
...
> + tw->tw_ttd = (u32)(jiffies + (slot << INET_TWDR_RECYCLE_TICK));
...
> + s32 delta = tw->tw_ttd - (u32)jiffies;
...
> + s32 delta = tw->tw_ttd - (u32)jiffies;
Eric just use tcp_time_stamp in all of these locations, then you can
lose the casts and still achieve your stated objective.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] inet: consolidate INET_TW_MATCH
From: David Miller @ 2013-10-03 19:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380713390.19002.87.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 02 Oct 2013 04:29:50 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 2 :
>
> We can use a generic lookup, sockets being in whatever state, if
> we are sure all relevant fields are at the same place in all socket
> types (ESTABLISH, TIME_WAIT, SYN_RECV)
>
> This patch removes these macros :
>
> inet_addrpair, inet_addrpair, tw_addrpair, tw_portpair
>
> And adds :
>
> sk_portpair, sk_addrpair, sk_daddr, sk_rcv_saddr
>
> Then, INET_TW_MATCH() is really the same than INET_MATCH()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Nice simplification, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] bonding: modify the current and add new hash functions
From: David Miller @ 2013-10-03 19:37 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar, eric.dumazet, vfalico
In-Reply-To: <1380713966-3891-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Wed, 2 Oct 2013 13:39:23 +0200
> This is a complete remake of my old patch that modified the bonding hash
> functions to use skb_flow_dissect which was suggested by Eric Dumazet.
> This time around I've left the old modes although using a new hash function
> again suggested by Eric, which is the same for all modes. The only
> difference is the way the headers are obtained. The old modes obtain them
> as before in order to address concerns about speed, but the 2 new ones use
> skb_flow_dissect. The unification of the hash function allows to remove a
> pointer from struct bonding and also a few extra functions that dealt with
> it. Two new functions are added which take care of the hashing based on
> bond->params.xmit_policy only:
> bond_xmit_hash() - global function, used by XOR and 3ad modes
> bond_flow_dissect() - used by bond_xmit_hash() to obtain the necessary
> headers and combine them according to bond->params.xmit_policy.
> Also factor out the ports extraction from skb_flow_dissect and add a new
> function - skb_flow_get_ports() which can be re-used.
>
> v2: add the flow_dissector patch and use skb_flow_get_ports in patch 02
> v3: fix a bug in the flow_dissector patch that caused a different thoff
> by modifying the thoff argument in skb_flow_get_ports directly, most
> of the users already do it anyway.
> Also add the necessary export symbol for skb_flow_get_ports.
> v4: integrate the thoff bug fix in patch 01
> v5: disintegrate the thoff bug fix and re-base on top of Eric's fix
Series applied, thanks al ot.
^ permalink raw reply
* Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
From: Dr. H. Nikolaus Schaller @ 2013-10-03 19:40 UTC (permalink / raw)
To: David Miller
Cc: Jan Dumon, Belisko Marek, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131003.152907.2144013596237714581.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi,
Am 03.10.2013 um 21:29 schrieb David Miller:
> From: "Dr. H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> Date: Wed, 2 Oct 2013 09:00:18 +0200
>
>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
>> From: "H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
>> Date: Thu, 15 Nov 2012 14:40:57 +0100
>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
>> GTM601 during RING indication
>>
>> It has been observed that the GTM601 with 1.7 firmware sometimes sends a value
>> wIndex that has bit 0x04 set instead of being reset as the code expects. So we
>> mask it for the error check.
>>
>> See http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>>
>> Signed-off-by: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
>> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVIAdwXzzRB9H2Q@public.gmane.org>
>
> I think we should look more deeply into what this bit might mean
> and why the firmware might be setting it before we even consider
> applying a patch like this one.
Yes, that would be the right way.
The problem is that the firmware is a black box and the packet format has no
(public) documentation (unless someone inside OPTION has access to it).
I have made the bug observation from debug log that this bit is set in a response
each time the modem has a RING message. It might be specific to this modem
and firmware version, i.e. a firmware bug. But we have no means to verify or even
change it in the firmware.
I.e. the driver must handle it in a better way.
Because the notification is rejected by the driver, the driver will hang up and the
whole modem connection breaks down.
With this patch, the problem was never observed again in ~2 years.
I'd hope the maintainer of this driver can shed some light on it.
BR,
Nikolaus Schaller
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/19 v2] net: atl1c: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna
Cc: jcliburn, chris.snook, jkosina, rdunlap, standby24x7, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-1-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:48 +0200
> The variable ret is only assigned the values true and false.
> The function atl1c_read_eeprom already returns bool. Change
> ret type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 19/19 v2] net: ipv4: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna; +Cc: kuznet, jmorris, kaber, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-4-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:51 +0200
> The variable fully_acked is only assigned the values true and false.
> Change its type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 10/19 v2] net: myri10ge: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna; +Cc: hykim, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-3-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:50 +0200
> There is the rc variable on both myri10ge_ss_lock_napi and
> myri10ge_ss_lock_poll functions. In both cases rc is only assigned the
> values true and false. Both functions already return bool. Change rc
> type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 09/19 v2] net: bnx2x: Change variable type to bool
From: David Miller @ 2013-10-03 19:41 UTC (permalink / raw)
To: peter.senna; +Cc: eilong, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1380716391-20214-2-git-send-email-peter.senna@gmail.com>
From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Wed, 2 Oct 2013 14:19:49 +0200
> The variable rc is only assigned the values true and false.
> The function bnx2x_prev_is_path_marked already returns bool.
> Change rc type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] be2net: Warn users of possible broken functionality on BE2 cards with very old F/W versions with latest driver.
From: Ben Hutchings @ 2013-10-03 19:45 UTC (permalink / raw)
To: Somnath Kotur; +Cc: netdev, davem
In-Reply-To: <e84f68dc-6ab3-4e56-b2f5-70e51c46d1c3@CMEXHTCAS1.ad.emulex.com>
On Thu, 2013-10-03 at 12:33 +0530, Somnath Kotur wrote:
> On very old F/W versions < 4.0, the mailbox command to set interrupts on the
> card succeeds even though it is not supported and should have failed leading to
> interrupts not working.
> Hence warn users to upgrade to a suitable F/W version to avoid seeing broken
> functionality.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2c38cc4..f4bbc92 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -3247,6 +3247,11 @@ static int be_setup(struct be_adapter *adapter)
>
> be_cmd_get_fw_ver(adapter, adapter->fw_ver, adapter->fw_on_flash);
>
> + if (BE2_chip(adapter) && memcmp(adapter->fw_ver, "4.", 2) < 0) {
Are you sure the firmware major version will never go up to 2 digits?
This seems like a job for simple_strtol(), except that's now deprecated.
I don't know what one is supposed to do now when parsing a string that
has more than just a single integer in it.
> + dev_err(dev, "F/W version is very old. IRQs may not work\n");
> + dev_err(dev, "Pls upgrade to F/W version >= 4.0\n");
'Please' is spelt thus. And it seems odd to say 'very old' when you
also have a very specific idea of how old that is (< 4.0).
Ben.
> + }
> +
> if (adapter->vlans_added)
> be_vid_config(adapter);
>
--
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
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