* Re: [PATCH] net/wireless/libertas: do not call wiphy_unregister() w/o wiphy_register()
From: Holger Schurig @ 2010-03-30 6:49 UTC (permalink / raw)
To: Daniel Mack
Cc: linux-kernel, Dan Williams, John W. Linville, Bing Zhao,
libertas-dev, linux-wireless, netdev
In-Reply-To: <1269875658-3324-1-git-send-email-daniel@caiaq.de>
> The libertas driver calls wiphy_unregister() without a prior
> wiphy_register() when a devices fails initialization. Fix this by
> introducing a private flag.
Nice.
However, I wonder: do we really need a private variable? Does each driver
introduce a private variable for this?
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-30 6:19 UTC (permalink / raw)
To: Edgar E. Iglesias
Cc: Andi Kleen, Templin, Fred L, Eric Dumazet, Rick Jones,
Glen Turner, netdev@vger.kernel.org
In-Reply-To: <20100330061627.GA22436@laped.iglesias.mooo.com>
> If you don't want to hassle with all of that, the app can stick to
> 1280 (or I guess for the extreme/lazy cases turn on fragmentation)..
See the early mails in this thread. This is about apps who can't
limit themselves to 1280, but still don't want full blown PMTU.
[They probably should, but it can be a lot of work]
The MTU would allow to force fragmentation on the sending host
as a workaround similar to IPv4.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: UDP path MTU discovery II
From: Andi Kleen @ 2010-03-30 6:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, Templin, Fred L, Rick Jones, Edgar E. Iglesias,
Glen Turner, netdev@vger.kernel.org
In-Reply-To: <1269929168.1958.94.camel@edumazet-laptop>
Hmm, never mind your scheme of mapping it to the pmtudisc field would
probably work. Except it's u8 currently, would need to be u16 or u32
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: UDP path MTU discovery
From: Edgar E. Iglesias @ 2010-03-30 6:16 UTC (permalink / raw)
To: Andi Kleen
Cc: Templin, Fred L, Eric Dumazet, Rick Jones, Glen Turner,
netdev@vger.kernel.org
In-Reply-To: <20100330052044.GJ20695@one.firstfloor.org>
On Tue, Mar 30, 2010 at 07:20:44AM +0200, Andi Kleen wrote:
> On Mon, Mar 29, 2010 at 04:38:49PM -0700, Templin, Fred L wrote:
> > > 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.
>
> That's true -- in theory the UDP app unwilling/unable to do proper ptmudisc
> could set the path mtu to 1280 + header and still keep path mtu discovery off
> and then just fragment.
>
> Drawback would be of course suboptimal network use with too small MTUs
> in the common case.
>
> Right now there is no right socket option to set the path mtu. We
> have a IP_MTU option, but it only works for getting the MTU.
> That's because the PMTU is in the routing cache entry and shared
> by multiple sockets. Presumably one could add a special case
> with an MTU in the socket overriding the one in the destination entry.
Sorry I'm not following you here.. Why do you need to set the MTU?
IIUC:
UDP is supposed to preserve datagram boundaries, so the sender should
when seeing an EMSGSIZE, read the PMTU and avoid sending further UDP
packets larger than that. Userspace has control over the UDP datagram
size. If it can, the app will also at this point retransmit any recent
packets that went out larger than the fresh PMTU.
If you don't want to hassle with all of that, the app can stick to
1280 (or I guess for the extreme/lazy cases turn on fragmentation)..
Cheers
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-30 6:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, Templin, Fred L, Rick Jones, Edgar E. Iglesias,
Glen Turner, netdev@vger.kernel.org
In-Reply-To: <1269929168.1958.94.camel@edumazet-laptop>
> > Right now there is no right socket option to set the path mtu. We
> > have a IP_MTU option, but it only works for getting the MTU.
> > That's because the PMTU is in the routing cache entry and shared
> > by multiple sockets. Presumably one could add a special case
> > with an MTU in the socket overriding the one in the destination entry.
>
> We have IP_MTU_DISCOVER option with four existing values
I think you would just need a sk->pmtu and a option to set/unset it
Or perhaps just a flag that clamps to 1280?
Then the existing mtu discover options would be sufficient.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: UDP path MTU discovery
From: Eric Dumazet @ 2010-03-30 6:06 UTC (permalink / raw)
To: Andi Kleen
Cc: Templin, Fred L, Rick Jones, Edgar E. Iglesias, Glen Turner,
netdev@vger.kernel.org
In-Reply-To: <20100330052044.GJ20695@one.firstfloor.org>
Le mardi 30 mars 2010 à 07:20 +0200, Andi Kleen a écrit :
> On Mon, Mar 29, 2010 at 04:38:49PM -0700, Templin, Fred L wrote:
> > > 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.
>
> That's true -- in theory the UDP app unwilling/unable to do proper ptmudisc
> could set the path mtu to 1280 + header and still keep path mtu discovery off
> and then just fragment.
>
> Drawback would be of course suboptimal network use with too small MTUs
> in the common case.
>
> Right now there is no right socket option to set the path mtu. We
> have a IP_MTU option, but it only works for getting the MTU.
> That's because the PMTU is in the routing cache entry and shared
> by multiple sockets. Presumably one could add a special case
> with an MTU in the socket overriding the one in the destination entry.
We have IP_MTU_DISCOVER option with four existing values
/* IP_MTU_DISCOVER values */
#define IP_PMTUDISC_DONT 0 /* Never send DF frames */
#define IP_PMTUDISC_WANT 1 /* Use per route hints */
#define IP_PMTUDISC_DO 2 /* Always DF */
#define IP_PMTUDISC_PROBE 3 /* Ignore dst pmtu */
We might add a fifth value (or open full range) and change
static inline int ip_skb_dst_mtu(struct sk_buff *skb)
{
struct inet_sock *inet = skb->sk ? inet_sk(skb->sk) : NULL;
return (inet && inet->pmtudisc == IP_PMTUDISC_PROBE) ?
skb_dst(skb)->dev->mtu : dst_mtu(skb_dst(skb));
}
->
static inline int ip_skb_dst_mtu(struct sk_buff *skb)
{
if (skb->sk) {
struct inet_sock *inet = inet_sk(skb->sk);
if (inet->pmtudisc > IP_PMTUDISC_PROBE)
return inet->pmtudisc;
if (inet->pmtudisc == IP_PMTUDISC_PROBE)
return skb_dst(skb)->dev->mtu;
}
return dst_mtu(skb_dst(skb));
}
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-30 5:20 UTC (permalink / raw)
To: Templin, Fred L
Cc: Eric Dumazet, Rick Jones, Edgar E. Iglesias, Andi Kleen,
Glen Turner, netdev@vger.kernel.org
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A649E05EAAB5@XCH-NW-01V.nw.nos.boeing.com>
On Mon, Mar 29, 2010 at 04:38:49PM -0700, Templin, Fred L wrote:
> > 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.
That's true -- in theory the UDP app unwilling/unable to do proper ptmudisc
could set the path mtu to 1280 + header and still keep path mtu discovery off
and then just fragment.
Drawback would be of course suboptimal network use with too small MTUs
in the common case.
Right now there is no right socket option to set the path mtu. We
have a IP_MTU option, but it only works for getting the MTU.
That's because the PMTU is in the routing cache entry and shared
by multiple sockets. Presumably one could add a special case
with an MTU in the socket overriding the one in the destination entry.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] virtio_net: avoid BUG_ON() with large packets when CONFIG_DEBUG_SG=y
From: David Miller @ 2010-03-30 5:08 UTC (permalink / raw)
To: rusty; +Cc: netdev, mst
In-Reply-To: <201003301526.35720.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Tue, 30 Mar 2010 15:26:35 +1030
> AFAICT only weird kvm setups and lguest traverse this code path now.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Shirley Ma already posted a fix for this, and you missed the
add_recvbuf_small() case in your version.
I'll be applying Shirley's patch to net-next-2.6
^ permalink raw reply
* [PATCH] virtio_net: avoid BUG_ON() with large packets when CONFIG_DEBUG_SG=y
From: Rusty Russell @ 2010-03-30 4:56 UTC (permalink / raw)
To: netdev; +Cc: Michael S. Tsirkin
AFAICT only weird kvm setups and lguest traverse this code path now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/virtio_net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -351,6 +351,9 @@ static int add_recvbuf_big(struct virtne
char *p;
int i, err, offset;
+ /* This is a waste of cycles, but satisfies CONFIG_DEBUG_SG. */
+ sg_init_table(sg, ARRAY_SIZE(sg));
+
/* 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
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 4:55 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100329144339.GA26214@gondor.apana.org.au>
Herbert Xu wrote:
> On Mon, Mar 29, 2010 at 05:12:38PM +0300, Timo Teras wrote:
>> @@ -1132,7 +1119,7 @@ int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
>> __xfrm_policy_link(pol, XFRM_POLICY_MAX+dir);
>> }
>> if (old_pol)
>> - __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>> + old_pol = __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>> write_unlock_bh(&xfrm_policy_lock);
>>
>> if (old_pol) {
>
> So when can this actually fail?
Considering that the socket reference is received from the sk->sk_policy,
and the hash bucket we use is "XFRM_POLICY_MAX+dir", it's non-obvious if
it can fail or not.
It would look like the timer can kill a policy and unlink it, but it
would still be found from sk_policy.
It probably doesn't really make sense to insert per-socket policy that
expires. But in case someone does something like that, I'd think we
need the above just to be sure.
Considering this, xfrm_sk_policy_lookup() should probably check the
dead flag, and cleanup sk_policy if it was killed by a timer.
^ permalink raw reply
* Re: Minimizing TCP latency
From: Mikael Abrahamsson @ 2010-03-30 4:05 UTC (permalink / raw)
To: Ben Hoyt; +Cc: netdev
In-Reply-To: <7c93bf1e1003291935k6c9060bah11e1138568ba6998@mail.gmail.com>
On Tue, 30 Mar 2010, Ben Hoyt wrote:
> 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.
Serialisation delay on GigE for a 512 byte packet is 4us if my
calculations are correct, so if you have some equipment in between that
means two serialisations either way, meaning on GigE just the
serialisation delay is 16us RTT.
You'd probably be better off directly connection the two machines with
10GE NIC, or at least buy equipment that'll do cut-through switching if
you want to bring the delay down. I'm even surprised you got it down this
low...
^ permalink raw reply
* 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
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