* Re: [PATCH v9] tilegx network driver: initial support
From: Chris Metcalf @ 2012-06-06 18:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: bhutchings, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <1339004459.26966.31.camel@edumazet-glaptop>
On 6/6/2012 1:40 PM, Eric Dumazet wrote:
> On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
>
>> +/* Allocate and push a buffer. */
>> +static bool tile_net_provide_buffer(bool small)
>> +{
>> + int stack = small ? small_buffer_stack : large_buffer_stack;
>> + const unsigned long buffer_alignment = 128;
>> + struct sk_buff *skb;
>> + int len;
>> +
>> + len = sizeof(struct sk_buff **) + buffer_alignment;
>> + len += (small ? 128 : 1664);
> 1664 is a magic number, it should be a nice define
>
> #define ..... ( ETH_DATA_LEN + .... )
Fair enough. However, the magic-ness comes from the hardware header code
in arch/tile/gxio/mpipe.h, which provides a limited set of allowed buffer
sizes, including 1664. But I can add these #defines at the top of this driver:
/* Buffer sizes and mpipe enum codes for buffer stacks.
* See arch/tile/include/gxio/mpipe.h for the set of possible values.
*/
#define BUFFER_SIZE_SMALL_ENUM GXIO_MPIPE_BUFFER_SIZE_128
#define BUFFER_SIZE_SMALL 128
#define BUFFER_SIZE_LARGE_ENUM GXIO_MPIPE_BUFFER_SIZE_1664
#define BUFFER_SIZE_LARGE 1664
>> + skb = dev_alloc_skb(len);
>> + if (skb == NULL)
>> + return false;
>> +
>> + /* Make room for a back-pointer to 'skb' and guarantee alignment. */
>> + skb_reserve(skb, sizeof(struct sk_buff **));
>> + skb_reserve(skb, -(long)skb->data & (buffer_alignment - 1));
>> +
>> + /* Save a back-pointer to 'skb'. */
>> + *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
>> +
>> + /* Make sure "skb" and the back-pointer have been flushed. */
>> + wmb();
> Interesting, have you considered using build_skb() instead of this
> convoluted thing ?
>
> This could save some cache misses...
I hadn't looked at build_skb() before; we built up this driver mostly on a
base of 2.6.38, where it doesn't exist. That said, it doesn't seem like it
matters; dev_alloc_skb() will just end up calling down to build_skb()
anyway, as far as I can tell.
The code where we do the two skb_reserves and then stuff in a backpointer
and do a barrier are because we track the skbuffs in hardware, and hardware
ignores the low 7 bits aof the address (thus the "buffer_alignment" part)
and we need to be able to pull the actual skb address out of the data when
the hardware returns a pointer to the data to us.
By the way, your question about tx_queue_len is a good one; I'm roping in
our other network developer folks to figure it out. Originally it was a
performance optimization, I believe; I'm not sure it's still required.
I'll follow up on that one when we've tracked it down.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH net-next 2/3] qlcnic: fix unsupported CDRP command error message.
From: Anirban Chakraborty @ 2012-06-06 18:35 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, netdev, Dept-NX Linux NIC Driver, Jitendra Kalsaria
In-Reply-To: <1339006447.13710.6.camel@joe2Laptop>
On 6/6/12 11:14 AM, "Joe Perches" <joe@perches.com> wrote:
>On Wed, 2012-06-06 at 13:35 -0400, Anirban Chakraborty wrote:
>> From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>>
>> Add debug messages for FW CDRP command failure.
>
>trivia:
>
>Please be consistent with the use of (preferably _no_) periods
>at the end of logging messages.
>
>$ git grep -E "[^\.]\\\\n\"" drivers/net/ethernet/qlogic/qlcnic/ | wc -l
>187
>$ git grep -E "\.\\\\n\"" drivers/net/ethernet/qlogic/qlcnic/ | wc -l
>22
>
>[]
>> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
>>b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
>[]
>> @@ -53,12 +53,39 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter,
>>struct qlcnic_cmd_args *cmd)
>> rsp = qlcnic_poll_rsp(adapter);
>>
>> if (rsp == QLCNIC_CDRP_RSP_TIMEOUT) {
>> - dev_err(&pdev->dev, "card response timeout.\n");
>> + dev_err(&pdev->dev, "CDRP response timeout.\n");
>
>ie: no period necessary.
Thanks for pointing it out. We will not add that period in commit messages
from next time on.
>
>CDRP is kind of an odd acronym.
>Is it for CarD ResPonse?
It stands for FW CommanD ResPonse.
>
>If it is, then I think a lot of the below messages are
>not particularly sensible and the CDRP should be dropped.
Having CDRRP in the message string helps us identify the source of error.
This works well for us in debugging issues.
-Anirban
^ permalink raw reply
* Change in alloc_skb() behavior in 3.2+ kernels?
From: Grant Edwards @ 2012-06-06 18:32 UTC (permalink / raw)
To: netdev
I'm tracking down a problem that appears to be caused by a change in
the behavior of alloc_skb() introduced in kernel version 3.2. In
kernel versions prior to 3.2, calling alloc_skb(1350), returned an
sk_buff with a tailroom of around 1400 bytes (safely below the default
Ethernet frame size limit of 1500).
In 3.2 and later, calling alloc_skb(1350) returns an sk_buff with a
tailroom of about 1850.
Why has the "extra" space increased from 60 bytes to 500 bytes?
[It's always possible that I've unintentionally changed something in
the kernel configs that causes this, but I've tried to build the
kernels as identically as possible.]
The kernel module that's started failing fills the allocated sk_buff
until tailroom() indicates it is full and then sends it. The problem
is that sending a packet with a length of 1850 won't work (it's a
MAC-layer Ethernet packet).
I've found man pages for alloc_skb() from a few years ago that state
explicitly that alloc_skb(_size_) will allocate a new sk_buff with no
headroom and a tail room of _size_ bytes. This doesn't seem to be the
case for recent kernels. Is there any documentation stating what the
current behavior is supposed to be?
Are callers to alloc_skb() supposed to check the tailroom and
reserve() an appropriate number of bytes such that the tailroom is
correct?
Is the tailroom of the allocated sk_buff guaranteed to be at least as
large as the requested size, or does application code also have to
check for tailroom less than the requested size?
The ultimate question I'm trying to answer is what is the "right" way
to allocate an sk_buff that has a size appropriate for an Ethernet
frame assuming an MTU of 1500?
--
Grant Edwards grant.b.edwards Yow! Let's send the
at Russians defective
gmail.com lifestyle accessories!
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: David Miller @ 2012-06-06 18:23 UTC (permalink / raw)
To: therbert
Cc: shimoda.hiroaki, jesse.brandeburg, eric.dumazet, denys, netdev,
e1000-devel, jeffrey.t.kirsher
In-Reply-To: <CA+mtBx-o4WB5gmHRMTQ6+haNrbeJyaaX9zXPhhYZydZbSPO98w@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 6 Jun 2012 11:21:40 -0700
> I'm not exactly sure what the exact effect of WTHRESH is here. Does
> the device coalesce 5 completions regardless of size? Would the
> problem be avoided if bql limit_min were MTU, or could same issue be
> hit with larger that 64 byte packets?
The problem is that no TX completions are signalled happen until at
least WTHRESH are pending.
BQL is the least of the problems generated by this kind of behavior.
All drivers must TX complete in a small, finite, amount of time so
it is absolutely illegal to have the behavior that WRTHRESH > 1
gives.
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Tom Herbert @ 2012-06-06 18:21 UTC (permalink / raw)
To: Hiroaki SHIMODA
Cc: Denys Fedoryshchenko, e1000-devel, netdev, Jesse Brandeburg,
davem
In-Reply-To: <20120607021937.a5638bfd.shimoda.hiroaki@gmail.com>
I'm not exactly sure what the exact effect of WTHRESH is here. Does
the device coalesce 5 completions regardless of size? Would the
problem be avoided if bql limit_min were MTU, or could same issue be
hit with larger that 64 byte packets?
Tom
On Wed, Jun 6, 2012 at 10:19 AM, Hiroaki SHIMODA
<shimoda.hiroaki@gmail.com> wrote:
> On Wed, 6 Jun 2012 09:26:35 -0700
> Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
>
>> On Wed, 6 Jun 2012 Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> wrote:
>> > Sorry for long delay. I'll post.
>> > (I have no idea how to fix this problem as keeping TXDCTL.WTHRESH to 5)
>>
>> I don't like changing WTHRESH wholesale because making the global change
>> to WTHRESH on e1000e just to fix this one bug (likely specific to a
>> particular chip/hardware) will adversely effect performance on many
>> models supported by e1000e not demonstrating any problem. We could
>> possibly check something in for just ESB2LAN (S5000 chipset).
>>
>> Other people (tom herbert) with this same chipset have been unable to
>> reproduce this issue right?
>
> I understand your performance concern.
>
> The affected chip would be e1000_82571, e1000_82572, e1000_82574
> and e1000_80003es2lan which have FLAG2_DMA_BURST bit in
> adapter->flags2.
> Anyway, I have no objection intel guys NACK to my patch and
> provide right fix. But in that case please consider 82574L chip too
> which I observed similar behaviour.
>
> Thanks.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH v9] tilegx network driver: initial support
From: Ben Hutchings @ 2012-06-06 18:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Chris Metcalf, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <1339006223.26966.36.camel@edumazet-glaptop>
On Wed, 2012-06-06 at 20:10 +0200, Eric Dumazet wrote:
> On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
> > This change adds support for the tilegx network driver based on the
> > GXIO IORPC support in the tilegx software stack, using the on-chip
> > mPIPE packet processing engine.
> >
>
> > +
> > +/* Do "TSO" handling for egress.
> > + *
> > + * Normally drivers set NETIF_F_TSO only to support hardware TSO;
> > + * otherwise the stack uses scatter-gather to implement GSO in software.
> > + * On our testing, enabling GSO support (via NETIF_F_SG) drops network
> > + * performance down to around 7.5 Gbps on the 10G interfaces, although
> > + * also dropping cpu utilization way down, to under 8%. But
> > + * implementing "TSO" in the driver brings performance back up to line
> > + * rate, while dropping cpu usage even further, to less than 4%. In
> > + * practice, profiling of GSO shows that skb_segment() is what causes
> > + * the performance overheads; we benefit in the driver from using
> > + * preallocated memory to duplicate the TCP/IP headers.
> > + */
>
> All this stuff cost about 300 lines of code in this driver, without IPv6
> support.
>
> I am pretty sure this performance problem should be solved in net/{core|
> ipv4|ipv6} instead
>
> What TCP performance do you get with TSO/GSO and SG off ?
It's a real problem and we have soft-TSO in the sfc driver for the same
reason. GSO means more allocation, more DMA mapping, more calls into
the driver and more register writes.
If drivers could use GSO explicitly from their ndo_start_xmit function,
more like they do with GRO, much of this would presumably be avoidable.
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 v9] tilegx network driver: initial support
From: David Miller @ 2012-06-06 18:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: cmetcalf, bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <1339006223.26966.36.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Jun 2012 20:10:23 +0200
> I am pretty sure this performance problem should be solved in net/{core|
> ipv4|ipv6} instead
>
> What TCP performance do you get with TSO/GSO and SG off ?
We have other drivers already doing this.
I tried a few years ago to make this generic, because NIU could
benefit from it as well, but I couldn't figure out a clean enough
way to abstract this.
Therefore it is absolutely reasonable to continue to let drivers
do this locally until we actually have a reasonable solution.
The gains are definitely significant for chips that lack real TSO
hardware, I absolutely do not require "proof" of this, it is clearly
evident to anyone who considers the issue.
^ permalink raw reply
* Re: pull-request: can-next 2012-06-04
From: David Miller @ 2012-06-06 18:15 UTC (permalink / raw)
To: socketcan; +Cc: mkl, netdev, linux-can
In-Reply-To: <4FCF9B3B.1070105@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 06 Jun 2012 20:02:35 +0200
> i think there was a confusion about
>
> linux-can and linux-can-next
>
> pull requests that overlapped in the mail traffic that day.
>
> The pull request of linux-can-next is still pending.
>
> git://gitorious.org/linux-can/linux-can-next.git master
Strange, I thought I had pulled it, I've done so now, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/3] qlcnic: fix unsupported CDRP command error message.
From: Joe Perches @ 2012-06-06 18:14 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: davem, netdev, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1339004108-7356-3-git-send-email-anirban.chakraborty@qlogic.com>
On Wed, 2012-06-06 at 13:35 -0400, Anirban Chakraborty wrote:
> From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>
> Add debug messages for FW CDRP command failure.
trivia:
Please be consistent with the use of (preferably _no_) periods
at the end of logging messages.
$ git grep -E "[^\.]\\\\n\"" drivers/net/ethernet/qlogic/qlcnic/ | wc -l
187
$ git grep -E "\.\\\\n\"" drivers/net/ethernet/qlogic/qlcnic/ | wc -l
22
[]
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
[]
> @@ -53,12 +53,39 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter, struct qlcnic_cmd_args *cmd)
> rsp = qlcnic_poll_rsp(adapter);
>
> if (rsp == QLCNIC_CDRP_RSP_TIMEOUT) {
> - dev_err(&pdev->dev, "card response timeout.\n");
> + dev_err(&pdev->dev, "CDRP response timeout.\n");
ie: no period necessary.
CDRP is kind of an odd acronym.
Is it for CarD ResPonse?
If it is, then I think a lot of the below messages are
not particularly sensible and the CDRP should be dropped.
> cmd->rsp.cmd = QLCNIC_RCODE_TIMEOUT;
> } else if (rsp == QLCNIC_CDRP_RSP_FAIL) {
> cmd->rsp.cmd = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
> - dev_err(&pdev->dev, "failed card response code:0x%x\n",
> + switch (cmd->rsp.cmd) {
> + case QLCNIC_RCODE_INVALID_ARGS:
> + dev_err(&pdev->dev, "CDRP invalid args: 0x%x.\n",
> cmd->rsp.cmd);
> + break;
> + case QLCNIC_RCODE_NOT_SUPPORTED:
> + case QLCNIC_RCODE_NOT_IMPL:
> + dev_err(&pdev->dev,
> + "CDRP command not supported: 0x%x.\n",
> + cmd->rsp.cmd);
> + break;
> + case QLCNIC_RCODE_NOT_PERMITTED:
> + dev_err(&pdev->dev,
> + "CDRP requested action not permitted: 0x%x.\n",
> + cmd->rsp.cmd);
> + break;
> + case QLCNIC_RCODE_INVALID:
> + dev_err(&pdev->dev,
> + "CDRP invalid or unknown cmd received: 0x%x.\n",
> + cmd->rsp.cmd);
> + break;
> + case QLCNIC_RCODE_TIMEOUT:
> + dev_err(&pdev->dev, "CDRP command timeout: 0x%x.\n",
> + cmd->rsp.cmd);
> + break;
> + default:
> + dev_err(&pdev->dev, "CDRP command failed: 0x%x.\n",
> + cmd->rsp.cmd);
> + }
> } else if (rsp == QLCNIC_CDRP_RSP_OK) {
> cmd->rsp.cmd = QLCNIC_RCODE_SUCCESS;
> if (cmd->rsp.arg2)
> @@ -957,9 +984,6 @@ int qlcnic_get_mac_stats(struct qlcnic_adapter *adapter,
> mac_stats->mac_rx_jabber = le64_to_cpu(stats->mac_rx_jabber);
> mac_stats->mac_rx_dropped = le64_to_cpu(stats->mac_rx_dropped);
> mac_stats->mac_rx_crc_error = le64_to_cpu(stats->mac_rx_crc_error);
> - } else {
> - dev_info(&adapter->pdev->dev,
> - "%s: Get mac stats failed =%d.\n", __func__, err);
> }
>
> dma_free_coherent(&adapter->pdev->dev, stats_size, stats_addr,
^ permalink raw reply
* Re: [PATCH v9] tilegx network driver: initial support
From: Eric Dumazet @ 2012-06-06 18:10 UTC (permalink / raw)
To: Chris Metcalf; +Cc: bhutchings, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <201206042023.q54KNEZp003834@farm-0002.internal.tilera.com>
On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
> This change adds support for the tilegx network driver based on the
> GXIO IORPC support in the tilegx software stack, using the on-chip
> mPIPE packet processing engine.
>
> +
> +/* Do "TSO" handling for egress.
> + *
> + * Normally drivers set NETIF_F_TSO only to support hardware TSO;
> + * otherwise the stack uses scatter-gather to implement GSO in software.
> + * On our testing, enabling GSO support (via NETIF_F_SG) drops network
> + * performance down to around 7.5 Gbps on the 10G interfaces, although
> + * also dropping cpu utilization way down, to under 8%. But
> + * implementing "TSO" in the driver brings performance back up to line
> + * rate, while dropping cpu usage even further, to less than 4%. In
> + * practice, profiling of GSO shows that skb_segment() is what causes
> + * the performance overheads; we benefit in the driver from using
> + * preallocated memory to duplicate the TCP/IP headers.
> + */
All this stuff cost about 300 lines of code in this driver, without IPv6
support.
I am pretty sure this performance problem should be solved in net/{core|
ipv4|ipv6} instead
What TCP performance do you get with TSO/GSO and SG off ?
^ permalink raw reply
* Re: pull-request: can-next 2012-06-04
From: Oliver Hartkopp @ 2012-06-06 18:02 UTC (permalink / raw)
To: davem; +Cc: Marc Kleine-Budde, Linux Netdev List, linux-can@vger.kernel.org
In-Reply-To: <4FCCD9A8.7030207@pengutronix.de>
Hello Dave,
i think there was a confusion about
linux-can and linux-can-next
pull requests that overlapped in the mail traffic that day.
The pull request of linux-can-next is still pending.
git://gitorious.org/linux-can/linux-can-next.git master
Regards,
Oliver
On 04.06.2012 17:52, Marc Kleine-Budde wrote:
> On 06/04/2012 12:52 AM, Marc Kleine-Budde wrote:
>> Hello David,
>>
>> here are the first patches for net-next, they add power management
>> support for the flexcan driver and clarify the documentation with
>> respect to error messages.
>>
>> regards, Marc
>>
>> ---
>>
>> The following changes since commit 31a67102f4762df5544bc2dfb34a931233d2a5b2:
>>
>> Fix blocking allocations called very early during bootup (2012-05-21 12:52:42 -0700)
>>
>> are available in the git repository at:
>> git@gitorious.org:linux-can/linux-can-next.git master
>
> That should be:
>
> git://gitorious.org/linux-can/linux-can-next.git master
>
> Sorry for the noise,
> Marc
>
^ permalink raw reply
* [PATCH net-next 1/3] qlcnic: Fix estimation of recv MSS in case of LRO
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Rajesh Borundia
In-Reply-To: <1339004108-7356-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
o Linux stack estimates MSS from skb->len or skb_shinfo(skb)->gso_size.
In case of LRO skb->len is aggregate of len of number of packets hence MSS
obtained using skb->len would be incorrect. Incorrect estimation of recv MSS
would lead to delayed acks in some traffic patterns (which sends two or three
packets and wait for ack and only then send remaining packets). This leads to
drop in performance. Hence we need to set gso_size to MSS obtained from firmware.
o This is fixed recently in firmware hence the MSS is obtained based on
capability. If fw is capable of sending the MSS then only driver sets the gso_size.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 7 +++++++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 3 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 3 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 9 +++++++++
5 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 8680a5d..520ff03 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -258,6 +258,8 @@ struct rcv_desc {
(((sts_data) >> 52) & 0x1)
#define qlcnic_get_lro_sts_seq_number(sts_data) \
((sts_data) & 0x0FFFFFFFF)
+#define qlcnic_get_lro_sts_mss(sts_data1) \
+ ((sts_data1 >> 32) & 0x0FFFF)
struct status_desc {
@@ -623,6 +625,7 @@ struct qlcnic_recv_context {
#define QLCNIC_CAP0_JUMBO_CONTIGUOUS (1 << 7)
#define QLCNIC_CAP0_LRO_CONTIGUOUS (1 << 8)
#define QLCNIC_CAP0_VALIDOFF (1 << 11)
+#define QLCNIC_CAP0_LRO_MSS (1 << 21)
/*
* Context state
@@ -829,6 +832,9 @@ struct qlcnic_mac_list_s {
#define QLCNIC_FW_CAPABILITY_FVLANTX BIT_9
#define QLCNIC_FW_CAPABILITY_HW_LRO BIT_10
#define QLCNIC_FW_CAPABILITY_MULTI_LOOPBACK BIT_27
+#define QLCNIC_FW_CAPABILITY_MORE_CAPS BIT_31
+
+#define QLCNIC_FW_CAPABILITY_2_LRO_MAX_TCP_SEG BIT_2
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
@@ -918,6 +924,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_NEED_FLR 0x1000
#define QLCNIC_FW_RESET_OWNER 0x2000
#define QLCNIC_FW_HANG 0x4000
+#define QLCNIC_FW_LRO_MSS_CAP 0x8000
#define QLCNIC_IS_MSI_FAMILY(adapter) \
((adapter)->flags & (QLCNIC_MSI_ENABLED | QLCNIC_MSIX_ENABLED))
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index 8db8524..cfa174d 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -237,6 +237,9 @@ qlcnic_fw_cmd_create_rx_ctx(struct qlcnic_adapter *adapter)
| QLCNIC_CAP0_VALIDOFF);
cap |= (QLCNIC_CAP0_JUMBO_CONTIGUOUS | QLCNIC_CAP0_LRO_CONTIGUOUS);
+ if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
+ cap |= QLCNIC_CAP0_LRO_MSS;
+
prq->valid_field_offset = offsetof(struct qlcnic_hostrq_rx_ctx,
msix_handler);
prq->txrx_sds_binding = nsds_rings - 1;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
index 6ced319..28a6b28 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
@@ -588,6 +588,7 @@ enum {
#define CRB_DRIVER_VERSION (QLCNIC_REG(0x2a0))
#define CRB_FW_CAPABILITIES_1 (QLCNIC_CAM_RAM(0x128))
+#define CRB_FW_CAPABILITIES_2 (QLCNIC_CAM_RAM(0x12c))
#define CRB_MAC_BLOCK_START (QLCNIC_CAM_RAM(0x1c0))
/*
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index 799fd40..8620b69 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1653,6 +1653,9 @@ qlcnic_process_lro(struct qlcnic_adapter *adapter,
length = skb->len;
+ if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
+ skb_shinfo(skb)->gso_size = qlcnic_get_lro_sts_mss(sts_data1);
+
if (vid != 0xffff)
__vlan_hwaccel_put_tag(skb, vid);
netif_receive_skb(skb);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 46e77a2..707b5ca 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -1136,6 +1136,8 @@ static int
__qlcnic_up(struct qlcnic_adapter *adapter, struct net_device *netdev)
{
int ring;
+ u32 capab2;
+
struct qlcnic_host_rds_ring *rds_ring;
if (adapter->is_up != QLCNIC_ADAPTER_UP_MAGIC)
@@ -1146,6 +1148,12 @@ __qlcnic_up(struct qlcnic_adapter *adapter, struct net_device *netdev)
if (qlcnic_set_eswitch_port_config(adapter))
return -EIO;
+ if (adapter->capabilities & QLCNIC_FW_CAPABILITY_MORE_CAPS) {
+ capab2 = QLCRD32(adapter, CRB_FW_CAPABILITIES_2);
+ if (capab2 & QLCNIC_FW_CAPABILITY_2_LRO_MAX_TCP_SEG)
+ adapter->flags |= QLCNIC_FW_LRO_MSS_CAP;
+ }
+
if (qlcnic_fw_create_ctx(adapter))
return -EIO;
@@ -1215,6 +1223,7 @@ __qlcnic_down(struct qlcnic_adapter *adapter, struct net_device *netdev)
qlcnic_napi_disable(adapter);
qlcnic_fw_destroy_ctx(adapter);
+ adapter->flags &= ~QLCNIC_FW_LRO_MSS_CAP;
qlcnic_reset_rx_buffers_list(adapter);
qlcnic_release_tx_buffers(adapter);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 3/3] qlcnic: Fix protcol type in case of inband vlan.
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Rajesh Borundia
In-Reply-To: <1339004108-7356-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
o Use correct l3 (ETH_IP or ETH_IPV6)protcol in case
of inband vlan. Because of incorrect protcol type driver
was setting incorrect opcode. This resulted in adapter calculating
checksum incorrectly.
o Updated driver version to 5.0.29
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 ++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index df4552f..eaa1db9 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -36,8 +36,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 0
-#define _QLCNIC_LINUX_SUBVERSION 28
-#define QLCNIC_LINUX_VERSIONID "5.0.28"
+#define _QLCNIC_LINUX_SUBVERSION 29
+#define QLCNIC_LINUX_VERSIONID "5.0.29"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_DRIVER_VERSION ((_QLCNIC_LINUX_MAJOR << 16) |\
(_QLCNIC_LINUX_MINOR << 8) | (_QLCNIC_LINUX_SUBVERSION))
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 707b5ca..33c3e46 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -2033,6 +2033,7 @@ qlcnic_tx_pkt(struct qlcnic_adapter *adapter,
vh = (struct vlan_ethhdr *)skb->data;
flags = FLAGS_VLAN_TAGGED;
vlan_tci = vh->h_vlan_TCI;
+ protocol = ntohs(vh->h_vlan_encapsulated_proto);
} else if (vlan_tx_tag_present(skb)) {
flags = FLAGS_VLAN_OOB;
vlan_tci = vlan_tx_tag_get(skb);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 2/3] qlcnic: fix unsupported CDRP command error message.
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1339004108-7356-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Add debug messages for FW CDRP command failure.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 34 +++++++++++++++++++---
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 520ff03..df4552f 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -612,7 +612,11 @@ struct qlcnic_recv_context {
#define QLCNIC_CDRP_CMD_GET_MAC_STATS 0x00000037
#define QLCNIC_RCODE_SUCCESS 0
+#define QLCNIC_RCODE_INVALID_ARGS 6
#define QLCNIC_RCODE_NOT_SUPPORTED 9
+#define QLCNIC_RCODE_NOT_PERMITTED 10
+#define QLCNIC_RCODE_NOT_IMPL 15
+#define QLCNIC_RCODE_INVALID 16
#define QLCNIC_RCODE_TIMEOUT 17
#define QLCNIC_DESTROY_CTX_RESET 0
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index cfa174d..b8ead69 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -53,12 +53,39 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter, struct qlcnic_cmd_args *cmd)
rsp = qlcnic_poll_rsp(adapter);
if (rsp == QLCNIC_CDRP_RSP_TIMEOUT) {
- dev_err(&pdev->dev, "card response timeout.\n");
+ dev_err(&pdev->dev, "CDRP response timeout.\n");
cmd->rsp.cmd = QLCNIC_RCODE_TIMEOUT;
} else if (rsp == QLCNIC_CDRP_RSP_FAIL) {
cmd->rsp.cmd = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- dev_err(&pdev->dev, "failed card response code:0x%x\n",
+ switch (cmd->rsp.cmd) {
+ case QLCNIC_RCODE_INVALID_ARGS:
+ dev_err(&pdev->dev, "CDRP invalid args: 0x%x.\n",
cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_SUPPORTED:
+ case QLCNIC_RCODE_NOT_IMPL:
+ dev_err(&pdev->dev,
+ "CDRP command not supported: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_PERMITTED:
+ dev_err(&pdev->dev,
+ "CDRP requested action not permitted: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_INVALID:
+ dev_err(&pdev->dev,
+ "CDRP invalid or unknown cmd received: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_TIMEOUT:
+ dev_err(&pdev->dev, "CDRP command timeout: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ default:
+ dev_err(&pdev->dev, "CDRP command failed: 0x%x.\n",
+ cmd->rsp.cmd);
+ }
} else if (rsp == QLCNIC_CDRP_RSP_OK) {
cmd->rsp.cmd = QLCNIC_RCODE_SUCCESS;
if (cmd->rsp.arg2)
@@ -957,9 +984,6 @@ int qlcnic_get_mac_stats(struct qlcnic_adapter *adapter,
mac_stats->mac_rx_jabber = le64_to_cpu(stats->mac_rx_jabber);
mac_stats->mac_rx_dropped = le64_to_cpu(stats->mac_rx_dropped);
mac_stats->mac_rx_crc_error = le64_to_cpu(stats->mac_rx_crc_error);
- } else {
- dev_info(&adapter->pdev->dev,
- "%s: Get mac stats failed =%d.\n", __func__, err);
}
dma_free_coherent(&adapter->pdev->dev, stats_size, stats_addr,
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 0/3] qlcnic: Bug fixes
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
Please apply.
Thanks,
Anirban
^ permalink raw reply
* Re: [PATCH] macvtap: use set_curren_state to ensure mb
From: David Miller @ 2012-06-06 17:48 UTC (permalink / raw)
To: honkiko; +Cc: eric.dumazet, netdev, arnd, zhiguo.hong, vikifang
In-Reply-To: <CAA7+ByUH8LsSrbetHngEZmaHkvK5aUO5v7-F=+wbveo6q68f-g@mail.gmail.com>
From: Hong zhi guo <honkiko@gmail.com>
Date: Tue, 5 Jun 2012 20:05:34 +0800
> On Tue, Jun 5, 2012 at 7:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Why not using the more standard :
>>
>> prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
>>
>> and
>>
>> finish_wait(sk_sleep(sk), &wait);
>>
>
> Thanks for your comments. The difference is that prepare_to_wait
> inside loop introduces extra "list_empty" judgement than original
> patch. But personally I prefer the newer version too:
>
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
Please don't submit patches like this:
1) When submitting new versions of a patch, make a fresh
new mailing list posting with just the patch and it's
commit message.
Do not post new versions by replying to other conversations.
2) Your email client has severely corrupted the patch, breaking
up long lines etc. Please read Documentation/email-clients.txt
to learn how to fix this.
^ permalink raw reply
* Re: [PATCH v2] inetpeer: fix a race in inetpeer_gc_worker()
From: David Miller @ 2012-06-06 17:45 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, netdev
In-Reply-To: <20120605130953.GG27795@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 5 Jun 2012 15:09:54 +0200
> On Tue, Jun 05, 2012 at 03:00:18PM +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with
>> the routing cache) added a race :
>>
>> Before freeing an inetpeer, we must respect a RCU grace period, and make
>> sure no user will attempt to increase refcnt.
>>
>> inetpeer_invalidate_tree() waits for a RCU grace period before inserting
>> inetpeer tree into gc_list and waking the worker. At that time, no
>> concurrent lookup can find a inetpeer in this tree.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Steffen Klassert <steffen.klassert@secunet.com>
>
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
I'll apply this and queue it up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for inetpeer
From: David Miller @ 2012-06-06 17:43 UTC (permalink / raw)
To: gaofeng
Cc: serge.hallyn, ebiederm, herbert, steffen.klassert, eric.dumazet,
netdev, containers
In-Reply-To: <1338882737-11914-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Tue, 5 Jun 2012 15:52:17 +0800
> now inetpeer doesn't support namespace,the information will
> be leaking across namespace.
>
> this patch move the global vars v4_peers and v6_peers to
> netns_ipv4 and netns_ipv6 as a field peers.
>
> add struct pernet_operations inetpeer_ops to initial pernet
> inetpeer data.
>
> and change family_to_base and inet_getpeer to support namespace.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
As stated yesterday we have to move the inetpeer tree roots into
the FIB rule entries to fix other bugs, and that as a result will
transparently fix this problem too.
So I'm dropping these two patches and will work on the mentioned
approach to this fix.
Thanks.
^ permalink raw reply
* RE: [net-next PATCH v2 1/3] Added kernel support in EEE Ethtool commands
From: Ben Hutchings @ 2012-06-06 17:41 UTC (permalink / raw)
To: Yuval Mintz
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eilon Greenstein,
peppe.cavallaro@st.com
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A50268AA@SJEXCHMB10.corp.ad.broadcom.com>
On Wed, 2012-06-06 at 16:40 +0000, Yuval Mintz wrote:
> > > + * @supported: Link speeds for which there is eee support.
> > > + * @advertised: Link speeds the interface advertises (AN) as eee capable.
> > > + * @lp_advertised: Link speeds the link partner advertised as eee capable.
> >
> > And these are bitmasks of SUPPORTED_* & ADVERTISED_* flags, right?
>
> Right.
>
> > Maybe 'link modes' not 'link speeds'?
>
> Not that it matters greatly, but there are SUPPORTED & ADVERTISED flags for
> things other than link speeds, such as connection type and flow control,
> so using exactly the same semantic in description might confuse someone.
What I'm getting at is that we don't have flags for speeds; we have
flags for modes (speed/duplex combination). I think EEE only works with
full-duplex modes but clients and drivers will still have to specify
that explicitly in flag names.
I can see that 'link modes' might be slightly ambiguous, so how about:
@supported: Mask of %SUPPORTED_* flags for the speed/duplex
combinations for which there is EEE support.
and similarly for the other fields.
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 v9] tilegx network driver: initial support
From: Eric Dumazet @ 2012-06-06 17:40 UTC (permalink / raw)
To: Chris Metcalf; +Cc: bhutchings, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <201206042023.q54KNEZp003834@farm-0002.internal.tilera.com>
On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
> +/* Allocate and push a buffer. */
> +static bool tile_net_provide_buffer(bool small)
> +{
> + int stack = small ? small_buffer_stack : large_buffer_stack;
> + const unsigned long buffer_alignment = 128;
> + struct sk_buff *skb;
> + int len;
> +
> + len = sizeof(struct sk_buff **) + buffer_alignment;
> + len += (small ? 128 : 1664);
1664 is a magic number, it should be a nice define
#define ..... ( ETH_DATA_LEN + .... )
> + skb = dev_alloc_skb(len);
> + if (skb == NULL)
> + return false;
> +
> + /* Make room for a back-pointer to 'skb' and guarantee alignment. */
> + skb_reserve(skb, sizeof(struct sk_buff **));
> + skb_reserve(skb, -(long)skb->data & (buffer_alignment - 1));
> +
> + /* Save a back-pointer to 'skb'. */
> + *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
> +
> + /* Make sure "skb" and the back-pointer have been flushed. */
> + wmb();
Interesting, have you considered using build_skb() instead of this
convoluted thing ?
This could save some cache misses...
^ permalink raw reply
* Re: [PATCH] net: sierra_net: device IDs for Aircard 320U++
From: David Miller @ 2012-06-06 17:40 UTC (permalink / raw)
To: gregkh
Cc: bjorn, netdev, linux-usb, dcbw, linux, autif.mlist, tomas.cassidy,
stable
In-Reply-To: <20120606121633.GB8535@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Wed, 6 Jun 2012 21:16:33 +0900
> Ok, thanks for clearing that up, I'll take the serial patch, and I'm
> sure that David will take this one.
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I'll apply this, thanks.
Greg, could you not put that TAB at the beginning of your
signoffs? It causes patchwork not to pick them up so I have
to add it manually.
Thanks.
^ permalink raw reply
* Re: [PATCH] Net: mv643xx_eth: Fix compile error for architectures without clk.
From: David Miller @ 2012-06-06 17:38 UTC (permalink / raw)
To: andrew; +Cc: jwboyer, buytenh, olof, netdev, ben
In-Reply-To: <1339000843-26078-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 6 Jun 2012 18:40:43 +0200
> Commit 452503ebc (ARM: Orion: Eth: Add clk/clkdev support.) broke
> the building of the driver on architectures which don't have clk
> support. In particular PPC32 Pegasos which uses this driver.
>
> Add #ifdef around the clk API usage.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fec: Add support for Coldfire M5441x enet-mac.
From: Jan Ceuleers @ 2012-06-06 17:34 UTC (permalink / raw)
To: Steven King; +Cc: netdev, uClinux development list, Greg Ungerer
In-Reply-To: <201206061006.21288.sfking@fdwdc.com>
On 06/06/2012 07:06 PM, Steven King wrote:
> Add support for the Freescale Coldfire M5441x; as these parts have an
> enet-mac, add a quirk to distinguish them from the other Coldfire parts so we
> can use the existing enet-mac support.
Stephen,
You are activating certain functionality based on whether M5441x is
defined. But where is this being defined? Should this not be added in a
Kconfig somewhere as a platform option?
Thanks, Jan
^ permalink raw reply
* Re: [PATCH v9] tilegx network driver: initial support
From: Eric Dumazet @ 2012-06-06 17:31 UTC (permalink / raw)
To: Chris Metcalf; +Cc: bhutchings, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <201206042023.q54KNEZp003834@farm-0002.internal.tilera.com>
On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
> This change adds support for the tilegx network driver based on the
> GXIO IORPC support in the tilegx software stack, using the on-chip
> mPIPE packet processing engine.
> +static void tile_net_setup(struct net_device *dev)
> +{
> + ether_setup(dev);
> + dev->netdev_ops = &tile_net_ops;
> + dev->watchdog_timeo = TILE_NET_TIMEOUT;
> + dev->features |= NETIF_F_LLTX;
> + dev->features |= NETIF_F_HW_CSUM;
> + dev->features |= NETIF_F_SG;
> + dev->features |= NETIF_F_TSO;
> + dev->tx_queue_len = 0;
> + dev->mtu = 1500;
> +}
Why is tx_queue_len set to 0 ?
^ permalink raw reply
* [PATCH] sparc bpf_jit: support BPF_S_ANC_ALU_XOR_X instruction
From: David Miller @ 2012-06-06 17:31 UTC (permalink / raw)
To: netdev; +Cc: sparclinux
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Committed to net-next
arch/sparc/net/bpf_jit_comp.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index 1a69244..e9073e9 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -96,6 +96,7 @@ static void bpf_flush_icache(void *start_, void *end_)
#define AND F3(2, 0x01)
#define ANDCC F3(2, 0x11)
#define OR F3(2, 0x02)
+#define XOR F3(2, 0x03)
#define SUB F3(2, 0x04)
#define SUBCC F3(2, 0x14)
#define MUL F3(2, 0x0a) /* umul */
@@ -462,6 +463,9 @@ void bpf_jit_compile(struct sk_filter *fp)
case BPF_S_ALU_OR_K: /* A |= K */
emit_alu_K(OR, K);
break;
+ case BPF_S_ANC_ALU_XOR_X: /* A ^= X; */
+ emit_alu_X(XOR);
+ break;
case BPF_S_ALU_LSH_X: /* A <<= X */
emit_alu_X(SLL);
break;
--
1.7.6.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox