* Good day,
From: rev.psalm @ 2010-03-30 3:01 UTC (permalink / raw)
To: 1266109622.11290.10.camel
Good day,
I am Osmond Amu, a Banker. Please do not be embarrass am seeking your help
in order to receive the sum of 30.7million as result of surfeit profit made
decade ago.
If you will be so kind enough to grant me the permission, I will be glad to
give the details.
I am ready to offer you 40% of the total amount for your input.
If you are interested respond to rev.psalm@gmail.com Send your name in full,
home address and telephone for cordial communication.
Better still call my cell phone for easy communication: +2347066703751.
Regards
Osmond Amu.
^ permalink raw reply
* Re: Minimizing TCP latency
From: Ben Hutchings @ 2010-03-30 3:20 UTC (permalink / raw)
To: Ben Hoyt; +Cc: netdev
In-Reply-To: <7c93bf1e1003291936v4b0f610eiae07c236dfc72047@mail.gmail.com>
On Tue, 2010-03-30 at 15:36 +1300, Ben Hoyt wrote:
> > Choose low-latency NICs. Read the tuning guide, but run your own
> > benchmarks.
>
> Is this the tuning guide you're referring to?
> http://fasterdata.es.net/TCP-tuning/linux.html
No, and that doesn't say anything about latency.
There are quite a few generic tuning knobs (buffer and ring sizes,
interrupt moderation and affinity). However, many vendors of
high-performance NICs, including Solarflare, provide a performance
tuning guide as part of their documentation, which can include
hardware-specific advice.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [iproute2] a 'ip rule ...' bug?
From: Stephen Hemminger @ 2010-03-30 2:42 UTC (permalink / raw)
To: thomas yang; +Cc: netdev
In-Reply-To: <f4f837ab1003260515y54f0db76vc19c966f39e1d3a1@mail.gmail.com>
On Fri, 26 Mar 2010 20:15:30 +0800
thomas yang <lampsu@gmail.com> wrote:
> in /etc/iproute2/rt_dsfield
> ...
> # Newer RFC2597 values
> 0x28 AF11
> 0x30 AF12
> 0x38 AF13
> ...
> ---in ip man page ---
> ip rule add - insert a new rule
>
> tos TOS
> dsfield TOS
> select the TOS value to match.
> ---
Read the syntax on the man page:
ip rule [ list | add | del | flush ] SELECTOR ACTION
SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark
FWMARK[/MASK] ] [ dev STRING ] [ pref NUMBER ]
There is no mention of dsfield argument.
>
> [root@localhost ~]# ip rule add dsfield 0x28 table 200
> Error: argument "dsfield" is wrong: Failed to parse rule type
>
> why???
> how to match 'dsfield' ?
>
> [root@localhost ~]# ip rule add tos 0x28 table 200
> RTNETLINK answers: Invalid argument
>
> (My OS is Fedora 11 : kernel-2.6.30.10-105.2.23.fc11.i586 ,
> iproute-2.6.29-2.fc11.i586 ;
> on my another linux box ( Fedora 7) 'ip rule' also has the same
> problem to match tos and dsfield. )
TOS field is masked by down to only 2 bits.
See include/net/route.h in kernel source.
I think the reason was that with original TOS (pre dsfield) route design,
the implementors wanted to save space.
^ permalink raw reply
* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2010-03-30 2:37 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Shanyu Zhao, Zhu Yi, Reinette Chatre,
John W. Linville, Johannes Berg
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-agn.c between commit
d4dca4e53fde2953d74198a2c445db1d36ed9fd2 ("iwlwifi: clear unattended
interrupts in tasklet") from the wireless-current tree and commit
a4c8b2a692601de0a7bcb032b69f806050944dff ("iwlwifi: move ICT data to agn
part of union") from the net tree.
I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/iwl-agn.c
index e4c2e1e,0a376f7..0000000
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@@ -1258,17 -1236,9 +1236,17 @@@ static void iwl_irq_tasklet(struct iwl_
/* Ack/clear/reset pending uCode interrupts.
* Note: Some bits in CSR_INT are "OR" of bits in CSR_FH_INT_STATUS,
*/
- iwl_write32(priv, CSR_INT, priv->_agn.inta);
+ /* There is a hardware bug in the interrupt mask function that some
+ * interrupts (i.e. CSR_INT_BIT_SCD) can still be generated even if
+ * they are disabled in the CSR_INT_MASK register. Furthermore the
+ * ICT interrupt handling mechanism has another bug that might cause
+ * these unmasked interrupts fail to be detected. We workaround the
+ * hardware bugs here by ACKing all the possible interrupts so that
+ * interrupt coalescing can still be achieved.
+ */
- iwl_write32(priv, CSR_INT, priv->inta | ~priv->inta_mask);
++ iwl_write32(priv, CSR_INT, priv->_agn.inta | ~priv->inta_mask);
- inta = priv->inta;
+ inta = priv->_agn.inta;
#ifdef CONFIG_IWLWIFI_DEBUG
if (iwl_get_debug_level(priv) & IWL_DL_ISR) {
^ permalink raw reply
* Re: Minimizing TCP latency
From: Ben Hoyt @ 2010-03-30 2:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1269876229.2092.3.camel@achroite.uk.solarflarecom.com>
> Choose low-latency NICs. Read the tuning guide, but run your own
> benchmarks.
Is this the tuning guide you're referring to?
http://fasterdata.es.net/TCP-tuning/linux.html
>> FYI, we're using RHE release 4 and kernel version 2.6.9 on x86_64 machines.
> You're not going to get much help here in working on that kernel.
Thanks for that. I didn't realise 2.6.9 was so old -- I'll upgrade.
-Ben
^ permalink raw reply
* Re: Minimizing TCP latency
From: Ben Hoyt @ 2010-03-30 2:35 UTC (permalink / raw)
To: netdev
In-Reply-To: <1269840891.2256.28.camel@edumazet-laptop>
> One machine sends messages, and messages are not aknowledged by other
> part ? Is it one way communication ?
No, it's two-way communication. It's really the round-trip
time/latency that's important.
> What are the targets ? (time constraints)
We're currently seeing a round-trip time of about 40us between two
Linux servers on our network (so presumably about 20us one way).
Anything quicker than that would be nice, but we're hoping to get down
to about half that.
> Mono threaded application handling one tcp flow ?
> Are you handling a very light load on few flows, or many flows ?
> Are machines all in the same LAN ?
It's a single-threaded application handling one TCP session with light
load, maybe one or two 512-byte packets per minute. The machines are
on the same localized network. There's a (fairly high-speed) router in
between, but I think most of the delays are being introduced at the
NIC and Linux levels.
Thanks,
Ben.
^ permalink raw reply
* Contact This Email For Claims atmcard2010@osoud.org
From: Brooke Burnett - Pasco @ 2010-03-30 2:05 UTC (permalink / raw)
Your Id has just been awarded $920,000.00Get back to us with your
Names:Address:Country:Occupation:Age:Tel:Sex: Yours Mr.Carlson
^ permalink raw reply
* [PATCH] gianfar: Fix a memory leak in gianfar close code
From: Andy Fleming @ 2010-03-30 1:42 UTC (permalink / raw)
To: davem; +Cc: netdev, eric.dumazet, Sandeep.Kumar
gianfar needed to ensure existence of the *skbuff arrays before
freeing the skbs in them, rather than ensuring their nonexistence.
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
drivers/net/gianfar.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index b671555..ad59608 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1638,13 +1638,13 @@ static void free_skb_resources(struct gfar_private *priv)
/* Go through all the buffer descriptors and free their data buffers */
for (i = 0; i < priv->num_tx_queues; i++) {
tx_queue = priv->tx_queue[i];
- if(!tx_queue->tx_skbuff)
+ if(tx_queue->tx_skbuff)
free_skb_tx_queue(tx_queue);
}
for (i = 0; i < priv->num_rx_queues; i++) {
rx_queue = priv->rx_queue[i];
- if(!rx_queue->rx_skbuff)
+ if(rx_queue->rx_skbuff)
free_skb_rx_queue(rx_queue);
}
--
1.6.5.2.g6ff9a
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v7 04/12] net-caif: add CAIF Link layer device header files
From: Marcel Holtmann @ 2010-03-30 1:29 UTC (permalink / raw)
To: David Miller; +Cc: sjur.brandeland, netdev, daniel.martensson, sjurbr
In-Reply-To: <20100329.171108.98400982.davem@davemloft.net>
Hi Dave,
> > +#endif /* CAIF_DEVICE_H_ */
> > +
>
> There are extra empty newlines at the end of several files
> just like this here, GIT warns about this when I try to
> apply your patches, therefore please fix this.
>
> It happens in several files in several of your patch postings,
> so please audit them all for this problem.
some editors tend to do this for no reason. I don't know which ones, but
I have seen it lately as well :(
Regards
Marcel
^ permalink raw reply
* Re: [PATCH next-next-2.6] virtio_net: missing sg_init_table
From: Shirley Ma @ 2010-03-30 1:19 UTC (permalink / raw)
To: Thomas Müller; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4BB10010.5060505@mathtm.de>
On Mon, 2010-03-29 at 21:31 +0200, Thomas Müller wrote:
> I've just tested the patch and it works fine, so I guess you can add a
> Tested-by: Thomas Müller <thomas@mathtm.de>
> line, if you like.
Thanks. Updated the patch with Tested-by.
Shirley
^ permalink raw reply
* [PATCH next-next-2.6 v2] virtio_net: missing sg_init_table
From: Shirley Ma @ 2010-03-30 1:19 UTC (permalink / raw)
To: David Miller; +Cc: Thomas Müller, netdev, linux-kernel
In-Reply-To: <4BB10010.5060505@mathtm.de>
Add missing sg_init_table for sg_set_buf in virtio_net which
induced in defer skb patch.
Reported-by: Thomas Müller <thomas@mathtm.de>
Tested-by: Thomas Müller <thomas@mathtm.de>
Signed-off-by: Shirley Ma <xma@us.ibm.com>
---
drivers/net/virtio_net.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 25dc77c..3f5be35 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -326,6 +326,7 @@ static int add_recvbuf_small(struct virtnet_info *vi, gfp_t gfp)
struct scatterlist sg[2];
int err;
+ sg_init_table(sg, 2);
skb = netdev_alloc_skb_ip_align(vi->dev, MAX_PACKET_LEN);
if (unlikely(!skb))
return -ENOMEM;
@@ -351,6 +352,7 @@ static int add_recvbuf_big(struct virtnet_info *vi, gfp_t gfp)
char *p;
int i, err, offset;
+ sg_init_table(sg, MAX_SKB_FRAGS + 2);
/* page in sg[MAX_SKB_FRAGS + 1] is list tail */
for (i = MAX_SKB_FRAGS + 1; i > 1; --i) {
first = get_a_page(vi, gfp);
^ permalink raw reply related
* Re: [PATCH 09/17] pcmcia: update gfp/slab.h includes
From: Tejun Heo @ 2010-03-30 1:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Dominik Brodowski, linux-next, linux-kernel, netdev
In-Reply-To: <20100330103129.b76a70e3.sfr@canb.auug.org.au>
Hello,
On 03/30/2010 08:31 AM, Stephen Rothwell wrote:
> Hi Dominik,
> On Mon, 29 Mar 2010 21:32:03 +0200 Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>>
>> On Tue, Mar 30, 2010 at 02:52:37AM +0900, Tejun Heo wrote:
>>> Implicit slab.h inclusion via percpu.h is about to go away. Make sure
>>> gfp.h or slab.h is included as necessary.
>>>
>>> Signed-off-by: Tejun Heo <tj@kernel.org>
>>> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Cc: Dominik Brodowski <linux@dominikbrodowski.net>
>> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
>
> The plan here is for you to put this in your tree now. It is safe to do
> so and Tejun can't carry it because this does not apply to mainline.
Yeap, something I completely forgot about when I asked Stephen to pull
from the slabh tree. It would be great if you can apply this one and
Stephen's patches on drivers/input/misc/ad714x.c and pcf8574_keypad.c
into input tree.
Thank you.
--
tejun
^ permalink raw reply
* [PATCH 1/2] netdev: ethtool RXHASH flag
From: Stephen Hemminger @ 2010-03-30 0:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100328154448.701c89ee@nehalam>
This adds ethtool and device feature flag to allow control
of receive hashing offload.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Supersedes earlier patch, decided to call it RXHASH not RSS since
we don't care about other vendors acronyms
--- a/include/linux/ethtool.h 2010-03-28 14:09:58.611267016 -0700
+++ b/include/linux/ethtool.h 2010-03-28 14:19:45.032516128 -0700
@@ -310,6 +310,7 @@ struct ethtool_perm_addr {
enum ethtool_flags {
ETH_FLAG_LRO = (1 << 15), /* LRO is enabled */
ETH_FLAG_NTUPLE = (1 << 27), /* N-tuple filters enabled */
+ ETH_FLAG_RXHASH = (1 << 28),
};
/* The following structures are for supporting RX network flow
--- a/include/linux/netdevice.h 2010-03-28 14:12:13.092517615 -0700
+++ b/include/linux/netdevice.h 2010-03-28 14:13:47.232915349 -0700
@@ -785,6 +785,7 @@ struct net_device {
#define NETIF_F_SCTP_CSUM (1 << 25) /* SCTP checksum offload */
#define NETIF_F_FCOE_MTU (1 << 26) /* Supports max FCoE MTU, 2158 bytes*/
#define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */
+#define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */
/* Segmentation offload features */
#define NETIF_F_GSO_SHIFT 16
--- a/net/core/ethtool.c 2010-03-28 14:12:25.012207457 -0700
+++ b/net/core/ethtool.c 2010-03-28 14:19:41.548521569 -0700
@@ -121,7 +121,7 @@ int ethtool_op_set_ufo(struct net_device
* NETIF_F_xxx values in include/linux/netdevice.h
*/
static const u32 flags_dup_features =
- (ETH_FLAG_LRO | ETH_FLAG_NTUPLE);
+ (ETH_FLAG_LRO | ETH_FLAG_NTUPLE | ETH_FLAG_RXHASH);
u32 ethtool_op_get_flags(struct net_device *dev)
{
@@ -152,6 +152,11 @@ int ethtool_op_set_flags(struct net_devi
features &= ~NETIF_F_NTUPLE;
}
+ if (data & ETH_FLAG_RXHASH)
+ features |= NETIF_F_RXHASH;
+ else
+ features &= ~NETIF_F_RXHASH;
+
dev->features = features;
return 0;
}
^ permalink raw reply
* [PATCH 2/2] ethtool: RXHASH flag support
From: Stephen Hemminger @ 2010-03-30 0:53 UTC (permalink / raw)
To: Jeff Garzik, David Miller; +Cc: netdev
In-Reply-To: <20100329174727.4654e19c@nehalam>
Add support for RXHASH flag in ethtool offload.
Update to current net-next sanitized version of ethtool.h
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
ethtool-copy.h | 32 +++++++++++++++++++++++++-------
ethtool.8 | 4 ++++
ethtool.c | 42 +++++++++++++++++++++++++++++++++++++-----
3 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 8681f5e..0cf8f33 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -36,7 +36,7 @@ struct ethtool_cmd {
__u32 reserved[2];
};
-static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
+static __inline__ void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
__u32 speed)
{
@@ -44,7 +44,7 @@ static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
ep->speed_hi = (__u16)(speed >> 16);
}
-static inline __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
+static __inline__ __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
{
return (ep->speed_hi << 16) | ep->speed;
}
@@ -61,6 +61,13 @@ struct ethtool_drvinfo {
/* For PCI devices, use pci_name(pci_dev). */
char reserved1[32];
char reserved2[12];
+ /*
+ * Some struct members below are filled in
+ * using ops->get_sset_count(). Obtaining
+ * this info from ethtool_drvinfo is now
+ * deprecated; Use ETHTOOL_GSSET_INFO
+ * instead.
+ */
__u32 n_priv_flags; /* number of flags valid in ETHTOOL_GPFLAGS */
__u32 n_stats; /* number of u64's from ETHTOOL_GSTATS */
__u32 testinfo_len;
@@ -253,6 +260,17 @@ struct ethtool_gstrings {
__u8 data[0];
};
+struct ethtool_sset_info {
+ __u32 cmd; /* ETHTOOL_GSSET_INFO */
+ __u32 reserved;
+ __u64 sset_mask; /* input: each bit selects an sset to query */
+ /* output: each bit a returned sset */
+ __u32 data[0]; /* ETH_SS_xxx count, in order, based on bits
+ in sset_mask. One bit implies one
+ __u32, two bits implies two
+ __u32's, etc. */
+};
+
enum ethtool_test_flags {
ETH_TEST_FL_OFFLINE = (1 << 0), /* online / offline */
ETH_TEST_FL_FAILED = (1 << 1), /* test passed / failed */
@@ -292,6 +310,7 @@ struct ethtool_perm_addr {
enum ethtool_flags {
ETH_FLAG_LRO = (1 << 15), /* LRO is enabled */
ETH_FLAG_NTUPLE = (1 << 27), /* N-tuple filters enabled */
+ ETH_FLAG_RXHASH = (1 << 28),
};
/* The following structures are for supporting RX network flow
@@ -389,8 +408,6 @@ struct ethtool_rx_ntuple_flow_spec {
#define ETHTOOL_RXNTUPLE_ACTION_DROP -1
};
-#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
-#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
struct ethtool_rx_ntuple {
__u32 cmd;
struct ethtool_rx_ntuple_flow_spec fs;
@@ -408,6 +425,7 @@ struct ethtool_flash {
char data[ETHTOOL_FLASH_MAX_FILENAME];
};
+
/* CMDs currently supported */
#define ETHTOOL_GSET 0x00000001 /* Get settings. */
#define ETHTOOL_SSET 0x00000002 /* Set settings. */
@@ -463,9 +481,9 @@ struct ethtool_flash {
#define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
#define ETHTOOL_RESET 0x00000034 /* Reset hardware */
-
-#define ETHTOOL_SRXNTUPLE 0x00000035 /* Add an n-tuple filter to device */
-#define ETHTOOL_GRXNTUPLE 0x00000036 /* Get n-tuple filters from device */
+#define ETHTOOL_SRXNTUPLE 0x00000035 /* Add an n-tuple filter to device */
+#define ETHTOOL_GRXNTUPLE 0x00000036 /* Get n-tuple filters from device */
+#define ETHTOOL_GSSET_INFO 0x00000037 /* Get string set info */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.8 b/ethtool.8
index eb6430b..a7b43d5 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -170,6 +170,7 @@ ethtool \- Display or change ethernet card settings
.B2 gso on off
.B2 gro on off
.B2 lro on off
+.B2 rxhash on off
.B ethtool \-p|\-\-identify
.I ethX
@@ -362,6 +363,9 @@ Specifies whether generic receive offload should be enabled
.A2 lro on off
Specifies whether large receive offload should be enabled
.TP
+.A2 rxhash on off
+Specifies whether receive hashing offload should be enabled
+.TP
.B \-p \-\-identify
Initiates adapter-specific action intended to enable an operator to
easily identify the adapter by sight. Typically this involves
diff --git a/ethtool.c b/ethtool.c
index fc9e419..26ab94b 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -173,6 +173,7 @@ static struct option {
" [ gro on|off ]\n"
" [ lro on|off ]\n"
" [ ntuple on|off ]\n"
+ " [ rxhash on|off ]\n"
},
{ "-i", "--driver", MODE_GDRV, "Show driver information" },
{ "-d", "--register-dump", MODE_GREGS, "Do a register dump",
@@ -257,6 +258,7 @@ static int off_gso_wanted = -1;
static int off_lro_wanted = -1;
static int off_gro_wanted = -1;
static int off_ntuple_wanted = -1;
+static int off_rxhash_wanted = -1;
static struct ethtool_pauseparam epause;
static int gpause_changed = 0;
@@ -382,6 +384,7 @@ static struct cmdline_info cmdline_offload[] = {
{ "lro", CMDL_BOOL, &off_lro_wanted, NULL },
{ "gro", CMDL_BOOL, &off_gro_wanted, NULL },
{ "ntuple", CMDL_BOOL, &off_ntuple_wanted, NULL },
+ { "rxhash", CMDL_BOOL, &off_rxhash_wanted, NULL },
};
static struct cmdline_info cmdline_pause[] = {
@@ -1526,7 +1529,7 @@ static int dump_coalesce(void)
}
static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
- int gro, int lro, int ntuple)
+ int gro, int lro, int ntuple, int rxhash)
{
fprintf(stdout,
"rx-checksumming: %s\n"
@@ -1537,7 +1540,8 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
"generic-segmentation-offload: %s\n"
"generic-receive-offload: %s\n"
"large-receive-offload: %s\n"
- "ntuple-filters: %s\n",
+ "ntuple-filters: %s\n"
+ "receive-hashing: %s\n",
rx ? "on" : "off",
tx ? "on" : "off",
sg ? "on" : "off",
@@ -1546,7 +1550,8 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
gso ? "on" : "off",
gro ? "on" : "off",
lro ? "on" : "off",
- ntuple ? "on" : "off");
+ ntuple ? "on" : "off",
+ rxhash ? "on" : "off");
return 0;
}
@@ -1863,7 +1868,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
{
struct ethtool_value eval;
int err, allfail = 1, rx = 0, tx = 0, sg = 0;
- int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, ntuple = 0;
+ int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, ntuple = 0, rxhash = 0;
fprintf(stdout, "Offload parameters for %s:\n", devname);
@@ -1935,6 +1940,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
} else {
lro = (eval.data & ETH_FLAG_LRO) != 0;
ntuple = (eval.data & ETH_FLAG_NTUPLE) != 0;
+ rxhash = (eval.data & ETH_FLAG_RXHASH) != 0;
allfail = 0;
}
@@ -1953,7 +1959,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
return 83;
}
- return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple);
+ return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple, rxhash);
}
static int do_soffload(int fd, struct ifreq *ifr)
@@ -2087,6 +2093,29 @@ static int do_soffload(int fd, struct ifreq *ifr)
return 93;
}
}
+ if (off_rxhash_wanted >= 0) {
+ changed = 1;
+ eval.cmd = ETHTOOL_GFLAGS;
+ eval.data = 0;
+ ifr->ifr_data = (caddr_t)&eval;
+ err = ioctl(fd, SIOCETHTOOL, ifr);
+ if (err) {
+ perror("Cannot get device flag settings");
+ return 91;
+ }
+
+ eval.cmd = ETHTOOL_SFLAGS;
+ if (off_rxhash_wanted)
+ eval.data |= ETH_FLAG_RXHASH;
+ else
+ eval.data &= ~ETH_FLAG_RXHASH;
+
+ err = ioctl(fd, SIOCETHTOOL, ifr);
+ if (err) {
+ perror("Cannot set receive hash settings");
+ return 93;
+ }
+ }
if (!changed) {
fprintf(stdout, "no offload settings changed\n");
@@ -2655,6 +2684,9 @@ static int do_srxntuple(int fd, struct ifreq *ifr)
return 0;
}
+#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
+#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
+
static int do_grxntuple(int fd, struct ifreq *ifr)
{
struct ethtool_gstrings *strings;
--
1.6.3.3
^ permalink raw reply related
* RE: [net-next-2.6 PATCH 3/8] vxge: Align the memory only if it is misaligned.
From: Ramkrishna Vepa @ 2010-03-30 0:04 UTC (permalink / raw)
To: David Miller, Sreenivasa Honnur; +Cc: netdev, support
In-Reply-To: <20100329.165945.157920838.davem@davemloft.net>
> From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
> Date: Mon, 29 Mar 2010 04:09:47 -0400 (EDT)
>
> > - Align the memory only if it is misaligned.
> >
> > Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> > Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
>
> Applied, but this vxge_os_dma_malloc code is completely
> unnecessary.
>
> If you want to allocate 4K chunks and make sure they are at least 128
> byte aligned, you can allocated pages (which are always PAGE_SIZE
> aligned) and chop them up into the appropriate block size as needed.
>
> This is exactly how drivers/net/niu.c handles this situation.
>
> See drivers/net/niu.c:niu_rbr_add_page()
Thanks. We'll make this change.
Ram
^ permalink raw reply
* Re: [PATCH net-next-2.6 v7 05/12] net-caif: add CAIF core protocol stack
From: David Miller @ 2010-03-30 0:11 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, marcel, daniel.martensson, sjurbr
In-Reply-To: <1269900693-9118-6-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Tue, 30 Mar 2010 00:11:26 +0200
> +struct cflayer *cfctrl_create()
> +{
This needs to be (void) not plain ().
This happens for all of your *_create() functions, please
fix this up.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v7 04/12] net-caif: add CAIF Link layer device header files
From: David Miller @ 2010-03-30 0:11 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, marcel, daniel.martensson, sjurbr
In-Reply-To: <1269900693-9118-5-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Tue, 30 Mar 2010 00:11:25 +0200
> +#endif /* CAIF_DEVICE_H_ */
> +
There are extra empty newlines at the end of several files
just like this here, GIT warns about this when I try to
apply your patches, therefore please fix this.
It happens in several files in several of your patch postings,
so please audit them all for this problem.
^ permalink raw reply
* RE: UDP path MTU discovery
From: Templin, Fred L @ 2010-03-29 23:38 UTC (permalink / raw)
To: Eric Dumazet, Rick Jones
Cc: Edgar E. Iglesias, Andi Kleen, Glen Turner,
netdev@vger.kernel.org
In-Reply-To: <1269898152.1958.86.camel@edumazet-laptop>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Eric Dumazet
> Sent: Monday, March 29, 2010 2:29 PM
> To: Rick Jones
> Cc: Edgar E. Iglesias; Andi Kleen; Glen Turner; netdev@vger.kernel.org
> Subject: Re: UDP path MTU discovery
>
> Le lundi 29 mars 2010 à 14:01 -0700, Rick Jones a écrit :
>
> > I would get the alphabet soup completely garbled, but the DNS folks are talking
> > about EDNS (?) message sizes upwards of 4096 bytes - encryption/authentication
> > and other angels being asked to dance on the head of the DNS pin are asking for
> > more and more space in the messages.
> >
> > So, someone will have to blink somewhere - either DNS will have to go TCP and
> > *possibly* take RTT hits there depending on various patch streams, or the IEEE
> > will have to sanction jumbo frames and people deploy them widely, or it will
> > have to become feasible to actually do the occasional IPv6 datagram
> > fragmentation and get a timely retransmission out of a UDP application on a PMTU
> > hit.
> >
>
> 1) 4096 bytes UDP messages... well...
> 2) Using regular TCP for DNS servers... well...
>
> I believe some guys were pushing TCPCT (Cookie Transactions) for this
> case ( http://tools.ietf.org/html/draft-simpson-tcpct-00.html )
>
> (That is, using an enhanced TCP for long DNS queries... but not only for
> DNS...)
IPv4 gets by this by setting DF=0 in the IP header, and
lets the network fragment the packet if necessary. IPv6 can
similarly get by this by having the sending host fragment
the large UDP packet into IPv6 fragments no longer than
1280 bytes each.
But wait! IPv4 hosts are only required to reassemble 576 bytes
at a minimum, and IPv6 hosts are only required to reassemble
1500 bytes at a minimum. Indeed, RFC2460 says:
"An upper-layer protocol or application that depends on IPv6
fragmentation to send packets larger than the MTU of a path should
not send packets larger than 1500 octets unless it has assurance that
the destination is capable of reassembling packets of that larger
size."
but it is not clear how the sender can get such "assurance".
In the end, perhaps IPv6 should just do what IPv4 does;
turn off PMTUD and hope for the best?
Fred
fred.l.templin@boeing.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [net-next-2.6 PATCH 8/8] vxge: Updating Maintainer list of S2IO 10GbE drivers (xframe / vxge).
From: David Miller @ 2010-03-30 0:00 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290413160.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:13:50 -0400 (EDT)
> - updating Maintainer list of S2IO 10GbE drivers (xframe / vxge).
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 7/8] vxge: Version update.
From: David Miller @ 2010-03-30 0:00 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290412360.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:13:13 -0400 (EDT)
> - Version update
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 6/8] vxge: Set function-0 as the privilaged function for normal function.
From: David Miller @ 2010-03-30 0:00 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290411440.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:12:33 -0400 (EDT)
> - For Normal function (MR-IOV disabled, SR-IOV disabled) Function-0 is the
> privilaged function.
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 5/8] vxge: Fixed MSIX interrupt configuration.
From: David Miller @ 2010-03-29 23:59 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290410360.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:11:41 -0400 (EDT)
> - Fixed MSIX interrupt configuration to support non contiguous vpaths in
> functions. Four msi-x vectors are reserved per vpath internal to the chip.
> In all, there are 68 msi-x vectors for the 17 vpaths in the chip. In the
> multi function configurations, non-contiguous vpaths are configured to
> represent a function. For instance vpaths 0 and 8 can be configured to
> represent function zero.
>
> - If pci_enable_msix fails for the requested vectors, try with a lesser number
> vectors by reducing the vpath count.
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 4/8] vxge: Fixed "ethtool -d" prints.
From: David Miller @ 2010-03-29 23:59 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290409530.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:10:33 -0400 (EDT)
> - Fixed "ethtool -d" prints
> - reg_space pointer was getting over written, updating it correctly.
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/8] vxge: Align the memory only if it is misaligned.
From: David Miller @ 2010-03-29 23:59 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290409080.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:09:47 -0400 (EDT)
> - Align the memory only if it is misaligned.
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied, but this vxge_os_dma_malloc code is completely
unnecessary.
If you want to allocate 4K chunks and make sure they are at least 128
byte aligned, you can allocated pages (which are always PAGE_SIZE
aligned) and chop them up into the appropriate block size as needed.
This is exactly how drivers/net/niu.c handles this situation.
See drivers/net/niu.c:niu_rbr_add_page()
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/8] vxge: Fix starvation of receive ring controller when blasted by short packets.
From: David Miller @ 2010-03-29 23:57 UTC (permalink / raw)
To: Sreenivasa.Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.11003290407500.4435-100000@guinness>
From: Sreenivasa Honnur <Sreenivasa.Honnur@neterion.com>
Date: Mon, 29 Mar 2010 04:08:30 -0400 (EDT)
> - Fix starvation of receive ring controller when blasted by short packets. This was because the driver was posting 64 rxds initially while the ring controller
> was expecting to read 256 replenished rxds. While the driver was coming up,
> the internal rxd memory filled up the 64 buffers provided and the ring
> controller was left waiting for the remaining 192 rxds to complete the write
> back of completed rxds to the host and generation of an interrupt.
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Applied.
^ 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