* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: Ron Mercer @ 2010-10-26 20:54 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, netdev@vger.kernel.org, Jitendra Kalsaria,
Ying Ping Lok
In-Reply-To: <AANLkTinr5fHjgPNieYjJuegU2EKWiQG00rAeatZV_=3w@mail.gmail.com>
On Mon, Oct 25, 2010 at 05:56:57PM -0700, Jesse Gross wrote:
>
> Using vlan groups within a driver is now deprecated. I realize that
> this is just a bug fix but it would nice if we can avoid introducing
> more code around vlan groups. Of course, fully switching the driver
> over to use the new vlan model would be even nicer.
I would like this bug fix to be applied though we will schedule switching
to the new vlan model ASAP.
^ permalink raw reply
* Re: [RFC PATCH 5/9] ipvs network name space aware
From: Simon Horman @ 2010-10-26 21:03 UTC (permalink / raw)
To: Hans Schillstrom
Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, ja@ssi.bg, wensong@linux-vs.org,
daniel.lezcano@free.fr
In-Reply-To: <201010261507.39734.hans.schillstrom@ericsson.com>
On Tue, Oct 26, 2010 at 03:07:38PM +0200, Hans Schillstrom wrote:
> On Friday 22 October 2010 21:05:48 Simon Horman wrote:
> > On Fri, Oct 08, 2010 at 01:17:02PM +0200, Hans Schillstrom wrote:
> > > This patch just contains ip_vs_ctl
> > >
> > > Signed-off-by:Hans Schillstrom <hans.schillstrom@ericsson.com>
> > >
> > > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > > index ca8ec8c..7e99cbc 100644
> > > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> >
> > [ snip ]
> > Hi Hans,
> >
> > is there a reason that the order some of the entries in
> > vs_vars has been switched around?
> >
> Yes there is, when vars will be copied to it's own NS it's a lot easier
> when they are in sequence and without a potential insert in the middle
> the #if 0 ...
>
> have a look at __ip_vs_control_init(struct net *net)
Ok, I suspected something like that.
In that case I think there may be a problem with
the way that I handled sysctl_ip_vs_conntrack.
^ permalink raw reply
* Re: GSO and IPv4 forwarding
From: Stephen Hemminger @ 2010-10-26 20:52 UTC (permalink / raw)
To: Kevin Wilson; +Cc: Eric Dumazet, netdev
In-Reply-To: <AANLkTik+s4CHgPuY6uhe-0aD=WJs=UHhoEdok4AyTdYJ@mail.gmail.com>
On Tue, 26 Oct 2010 22:26:07 +0200
Kevin Wilson <wkevils@gmail.com> wrote:
> Hi,
> Thanks a lot for your quick answer, I appreciate it (and did not
> expect it to be so quick!)
>
> Can someone please explain in 2-3 short sentences Why GRO can be
> forwarded and LRO cannot be forwarded ?
> rgs,
> Kevin
LRO merges packets together creating one large skb. This is a layering
violation for forwarding or bridging (it violates end to end principle).
GRO maintains the headers of each packet and passes them as
a cluster.
^ permalink raw reply
* Re: netns patches WAS( Re: [PATCH 8/8] net: Implement socketat.
From: jamal @ 2010-10-26 20:52 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Daniel Lezcano, Pavel Emelyanov, linux-kernel, Linux Containers,
netdev, netfilter-devel, linux-fsdevel, Linus Torvalds,
Michael Kerrisk, Ulrich Drepper, Al Viro, David Miller,
Serge E. Hallyn, Pavel Emelyanov, Ben Greear, Matt Helsley,
Jonathan Corbet, Sukadev Bhattiprolu, Jan Engelhardt,
Patrick McHardy
In-Reply-To: <1287145855.3642.30.camel@bigi>
Eric,
Ping?
If you are too busy to push these in maybe have
someone clueful like Daniel help out submitting? I think it
should probably be reasonable to leave out the sockeat
patch initially if it is deemed controversial..
cheers,
jamal
On Fri, 2010-10-15 at 08:30 -0400, jamal wrote:
> Eric et al,
>
> Did these patches make it in? I was looking at
> two Davem net trees and i dont see them.
>
> cheers,
> jamal
>
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: Ben Greear @ 2010-10-26 20:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1288125432.2652.39.camel@edumazet-laptop>
On 10/26/2010 01:37 PM, Eric Dumazet wrote:
> Le mardi 26 octobre 2010 à 13:29 -0700, Ben Greear a écrit :
>
>> I'm trying to craft my own netlink message...basically:
>>
>> memset(&snl, 0, sizeof(snl));
>> snl.nl_family = AF_NETLINK;
>> snl.nl_pid = 0;
>> snl.nl_groups = 0;
>>
>> memset(&buffer, 0, sizeof(buffer));
>> nlh->nlmsg_type = msg_type;
>> nlh->nlmsg_flags = NLM_F_MATCH|NLM_F_REQUEST;
>
> dont use F_MATCH : check net/core/rtnetlink.c
>
> vi +1660 net/core/rtnetlink.c
>
> You _dont_ want to call 'dumpit' : so dont use a bit present in
> NLM_F_DUMP at all:
That was exactly my problem. It works as expected with that NLM_F_MATCH
removed.
Thanks!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: GSO and IPv4 forwarding
From: Eric Dumazet @ 2010-10-26 20:43 UTC (permalink / raw)
To: Kevin Wilson; +Cc: netdev
In-Reply-To: <AANLkTik+s4CHgPuY6uhe-0aD=WJs=UHhoEdok4AyTdYJ@mail.gmail.com>
Le mardi 26 octobre 2010 à 22:26 +0200, Kevin Wilson a écrit :
> Hi,
> Thanks a lot for your quick answer, I appreciate it (and did not
> expect it to be so quick!)
>
> Can someone please explain in 2-3 short sentences Why GRO can be
> forwarded and LRO cannot be forwarded ?
Well, GRO is a pure software thing, completely handled in linux stack,
not driver specific. Its design included forwarding ability, LRO did
not.
http://lwn.net/Articles/311357/
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: Eric Dumazet @ 2010-10-26 20:37 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, netdev
In-Reply-To: <4CC73A1E.5050605@candelatech.com>
Le mardi 26 octobre 2010 à 13:29 -0700, Ben Greear a écrit :
> I'm trying to craft my own netlink message...basically:
>
> memset(&snl, 0, sizeof(snl));
> snl.nl_family = AF_NETLINK;
> snl.nl_pid = 0;
> snl.nl_groups = 0;
>
> memset(&buffer, 0, sizeof(buffer));
> nlh->nlmsg_type = msg_type;
> nlh->nlmsg_flags = NLM_F_MATCH|NLM_F_REQUEST;
dont use F_MATCH : check net/core/rtnetlink.c
vi +1660 net/core/rtnetlink.c
You _dont_ want to call 'dumpit' : so dont use a bit present in
NLM_F_DUMP at all:
if (kind == 2 && nlh->nlmsg_flags&NLM_F_DUMP) {
struct sock *rtnl;
rtnl_dumpit_func dumpit;
dumpit = rtnl_get_dumpit(family, type);
if (dumpit == NULL)
return -EOPNOTSUPP;
__rtnl_unlock();
rtnl = net->rtnl;
err = netlink_dump_start(rtnl, skb, nlh, dumpit, NULL);
rtnl_lock();
return err;
}
You want instead to call the 'doit' handler (one device only)
doit = rtnl_get_doit(family, type);
if (doit == NULL)
return -EOPNOTSUPP;
return doit(skb, nlh, (void *)&rta_buf[0]);
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: Ben Greear @ 2010-10-26 20:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1288122986.2652.20.camel@edumazet-laptop>
On 10/26/2010 12:56 PM, Eric Dumazet wrote:
> Le mardi 26 octobre 2010 à 12:38 -0700, David Miller a écrit :
>> From: Ben Greear<greearb@candelatech.com>
>> Date: Tue, 26 Oct 2010 12:31:12 -0700
>>
>>> Am I missing something, or do I just need to write up a patch
>>> to have netlink pay attention to the ifindex?
>>
>> Setting the ->ifi_index or IFLA_IFNAME attribute values appropriately
>> in the getlink request doesn't work?
>>
>> That should give you back, amonst other things, the rtnl_link_stats
>> for the device in the netlink response.
>> --
>
> Yep, it should be easy to change iproute2 to not ask a full dump
> in ip/ipaddress.c :
>
> if (rtnl_wilddump_request(&rth, preferred_family, RTM_GETLINK)< 0) ...
>
> and instead use rtnl_send() or something like that, if user provided one
> specific interface name (or index)
>
> ip link show dev eth0
I'm trying to craft my own netlink message...basically:
memset(&snl, 0, sizeof(snl));
snl.nl_family = AF_NETLINK;
snl.nl_pid = 0;
snl.nl_groups = 0;
memset(&buffer, 0, sizeof(buffer));
nlh->nlmsg_type = msg_type;
nlh->nlmsg_flags = NLM_F_MATCH|NLM_F_REQUEST;
static unsigned int nl_seqno = 1;
nlh->nlmsg_seq = nl_seqno++;
nlh->nlmsg_pid = nl_pid;
nlh->nlmsg_len = NLMSG_LENGTH(sizeof(*ifinfomsg));
ifinfomsg = (struct ifinfomsg*)(NLMSG_DATA(nlh));
ifinfomsg->ifi_family = AF_UNSPEC;
ifinfomsg->ifi_type = IFLA_UNSPEC;
ifinfomsg->ifi_index = if_index;
ifinfomsg->ifi_flags = 0;
ifinfomsg->ifi_change = 0xffffffff;
It's possible that I'm somehow messing this up. But, looking at the
static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
method, I cannot see how it would bail out properly after a single dev
has been processed, either.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Unwanted aliasing of UDP checksum failed error counter
From: Eric Dumazet @ 2010-10-26 20:27 UTC (permalink / raw)
To: Jeremy Jackson; +Cc: netdev
In-Reply-To: <a2ae895d871551a9b3ded9ce3874fe28.squirrel@imap.coplanar.net>
Le mardi 26 octobre 2010 à 16:21 -0400, Jeremy Jackson a écrit :
> > Le mardi 26 octobre 2010 à 15:53 -0400, Jeremy Jackson a écrit :
> >> Trying to find source of packet loss on an 8node compute cluster, we
> >> find:
> >> (not in this example, but on the real cluster)
> >>
> >> in /proc/sys/net/snmp
> >> Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
> >> Udp: 976460 1750 0 986795 0 0
> >>
> >> InErrors *and* RcvbufErrors both go up with full socket buffer, this has
> >> made troubleshooting our application more difficult. We were chasing
> >> UDP
> >> checksum problems, until we checked linux source code, and found
> >> aliasing.
> >>
> >> Is this done for assembly code efficiency? Any reason ENOMEM (ie socket
> >> buffer full) can't avoid aliasing to UDP checksum failed errors?
> >>
> >> in linux-source-2.6.32/net/ipv4/udp.c:__udp_queue_rcv_skb()
> >> ....
> >> /* Note that an ENOMEM error is charged twice */
> >> if (rc == -ENOMEM) {
> >> UDP_INC_STATS_BH(sock_net(sk),
> >> UDP_MIB_RCVBUFERRORS,
> >> is_udplite);
> >> atomic_inc(&sk->sk_drops);
> >> }
> >> goto drop;
> >> ...
> >> drop:
> >> UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
> >>
> >
> > In MIBS, there is no counter for UDP checksum errors
> >
> > So we use the standard UDP_MIB_INERRORS
>
> Yes, this part I understand, but what I don't understand is why ENOMEM
> errors *and* checksum errors both use the same counter, while ENOMEM has
> it's own already.
Because ENOMEM errors were handled in commit 81aa646c,
but _all_ errors must also be accounted in INERRORS, to be RFC
compliant.
[IPV4]: add the UdpSndbufErrors and UdpRcvbufErrors MIBs
If we add a new MIB counter for checksum errors, a bad checksum packet
will increment both this new counter and INERRORS.
^ permalink raw reply
* Re: GSO and IPv4 forwarding
From: Kevin Wilson @ 2010-10-26 20:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1288124114.2652.25.camel@edumazet-laptop>
Hi,
Thanks a lot for your quick answer, I appreciate it (and did not
expect it to be so quick!)
Can someone please explain in 2-3 short sentences Why GRO can be
forwarded and LRO cannot be forwarded ?
rgs,
Kevin
On Tue, Oct 26, 2010 at 10:15 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 26 octobre 2010 à 22:02 +0200, Kevin Wilson a écrit :
>> Hi,
>> When we set a netdevice to support forwarding, we disable LRO.
>> This is done because we don't want to forward an SKB which has been
>> processed by LRO.
>>
>> This is done in inet_forward_change() in net/ipv4/devinet.c:
>> We call dev_disable_lro(dev) in this method, when setting forwarding
>> for the device.
>> As a result, in ip_forward(), the packet will be dropped. (because
>> skb_warn_if_lro(), called by this method, returns TRUE)
>>
>> My question is:
>> dev_disable_lro(dev) disable the LRO feature (NETIF_F_LRO) of the
>> device. But suppose I have a device where GRO is enabled (and LRO is
>> not). And let's say I set forwarding on this device.
>>
>> it seems to me that is such case, calling dev_disable_lro(dev) in
>> net_forward_change() to disable the LRO feature of the device (which
>> is already disabled) is not enough, and in such case , GRO packets,
>> which want to be forwarded, will **not** be dropped in ip_forward().
>> (since kb_warn_if_lro() will return false in this case)
>>
>> Is it so ? I am ready to send a patch fixing it, but I am a newbie in
>> kernel, so I want to ask first.
>
> GRO packets can be forwarded just fine.
>
>
>
>
^ permalink raw reply
* Re: Unwanted aliasing of UDP checksum failed error counter
From: Jeremy Jackson @ 2010-10-26 20:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jeremy Jackson, netdev
In-Reply-To: <1288124033.2652.24.camel@edumazet-laptop>
> Le mardi 26 octobre 2010 à 15:53 -0400, Jeremy Jackson a écrit :
>> Trying to find source of packet loss on an 8node compute cluster, we
>> find:
>> (not in this example, but on the real cluster)
>>
>> in /proc/sys/net/snmp
>> Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
>> Udp: 976460 1750 0 986795 0 0
>>
>> InErrors *and* RcvbufErrors both go up with full socket buffer, this has
>> made troubleshooting our application more difficult. We were chasing
>> UDP
>> checksum problems, until we checked linux source code, and found
>> aliasing.
>>
>> Is this done for assembly code efficiency? Any reason ENOMEM (ie socket
>> buffer full) can't avoid aliasing to UDP checksum failed errors?
>>
>> in linux-source-2.6.32/net/ipv4/udp.c:__udp_queue_rcv_skb()
>> ....
>> /* Note that an ENOMEM error is charged twice */
>> if (rc == -ENOMEM) {
>> UDP_INC_STATS_BH(sock_net(sk),
>> UDP_MIB_RCVBUFERRORS,
>> is_udplite);
>> atomic_inc(&sk->sk_drops);
>> }
>> goto drop;
>> ...
>> drop:
>> UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
>>
>
> In MIBS, there is no counter for UDP checksum errors
>
> So we use the standard UDP_MIB_INERRORS
Yes, this part I understand, but what I don't understand is why ENOMEM
errors *and* checksum errors both use the same counter, while ENOMEM has
it's own already.
> udpInErrors OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of received UDP datagrams that could not be
> delivered for reasons other than the lack of an
> application at the destination port.
>
>
> We could add a LINUX specific MIB entry, eventually...
>
>
>
>
^ permalink raw reply
* Re: GSO and IPv4 forwarding
From: David Miller @ 2010-10-26 20:19 UTC (permalink / raw)
To: wkevils; +Cc: netdev
In-Reply-To: <AANLkTikxNYGFAmyZDit9fTp=-M8wfYp3Ew8rejsjHWHb@mail.gmail.com>
From: Kevin Wilson <wkevils@gmail.com>
Date: Tue, 26 Oct 2010 22:02:26 +0200
> My question is:
> dev_disable_lro(dev) disable the LRO feature (NETIF_F_LRO) of the
> device. But suppose I have a device where GRO is enabled (and LRO is
> not). And let's say I set forwarding on this device.
GRO is completely different from LRO, and can remain enabled
when forwarding is turned on.
^ permalink raw reply
* Re: GSO and IPv4 forwarding
From: Eric Dumazet @ 2010-10-26 20:15 UTC (permalink / raw)
To: Kevin Wilson; +Cc: netdev
In-Reply-To: <AANLkTikxNYGFAmyZDit9fTp=-M8wfYp3Ew8rejsjHWHb@mail.gmail.com>
Le mardi 26 octobre 2010 à 22:02 +0200, Kevin Wilson a écrit :
> Hi,
> When we set a netdevice to support forwarding, we disable LRO.
> This is done because we don't want to forward an SKB which has been
> processed by LRO.
>
> This is done in inet_forward_change() in net/ipv4/devinet.c:
> We call dev_disable_lro(dev) in this method, when setting forwarding
> for the device.
> As a result, in ip_forward(), the packet will be dropped. (because
> skb_warn_if_lro(), called by this method, returns TRUE)
>
> My question is:
> dev_disable_lro(dev) disable the LRO feature (NETIF_F_LRO) of the
> device. But suppose I have a device where GRO is enabled (and LRO is
> not). And let's say I set forwarding on this device.
>
> it seems to me that is such case, calling dev_disable_lro(dev) in
> net_forward_change() to disable the LRO feature of the device (which
> is already disabled) is not enough, and in such case , GRO packets,
> which want to be forwarded, will **not** be dropped in ip_forward().
> (since kb_warn_if_lro() will return false in this case)
>
> Is it so ? I am ready to send a patch fixing it, but I am a newbie in
> kernel, so I want to ask first.
GRO packets can be forwarded just fine.
^ permalink raw reply
* Re: Unwanted aliasing of UDP checksum failed error counter
From: Eric Dumazet @ 2010-10-26 20:13 UTC (permalink / raw)
To: Jeremy Jackson; +Cc: netdev
In-Reply-To: <8545971aec0612a0bca2801107d9493b.squirrel@imap.coplanar.net>
Le mardi 26 octobre 2010 à 15:53 -0400, Jeremy Jackson a écrit :
> Trying to find source of packet loss on an 8node compute cluster, we find:
> (not in this example, but on the real cluster)
>
> in /proc/sys/net/snmp
> Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
> Udp: 976460 1750 0 986795 0 0
>
> InErrors *and* RcvbufErrors both go up with full socket buffer, this has
> made troubleshooting our application more difficult. We were chasing UDP
> checksum problems, until we checked linux source code, and found aliasing.
>
> Is this done for assembly code efficiency? Any reason ENOMEM (ie socket
> buffer full) can't avoid aliasing to UDP checksum failed errors?
>
> in linux-source-2.6.32/net/ipv4/udp.c:__udp_queue_rcv_skb()
> ....
> /* Note that an ENOMEM error is charged twice */
> if (rc == -ENOMEM) {
> UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_RCVBUFERRORS,
> is_udplite);
> atomic_inc(&sk->sk_drops);
> }
> goto drop;
> ...
> drop:
> UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
>
In MIBS, there is no counter for UDP checksum errors
So we use the standard UDP_MIB_INERRORS
udpInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP datagrams that could not be
delivered for reasons other than the lack of an
application at the destination port.
We could add a LINUX specific MIB entry, eventually...
^ permalink raw reply
* GSO and IPv4 forwarding
From: Kevin Wilson @ 2010-10-26 20:02 UTC (permalink / raw)
To: netdev
Hi,
When we set a netdevice to support forwarding, we disable LRO.
This is done because we don't want to forward an SKB which has been
processed by LRO.
This is done in inet_forward_change() in net/ipv4/devinet.c:
We call dev_disable_lro(dev) in this method, when setting forwarding
for the device.
As a result, in ip_forward(), the packet will be dropped. (because
skb_warn_if_lro(), called by this method, returns TRUE)
My question is:
dev_disable_lro(dev) disable the LRO feature (NETIF_F_LRO) of the
device. But suppose I have a device where GRO is enabled (and LRO is
not). And let's say I set forwarding on this device.
it seems to me that is such case, calling dev_disable_lro(dev) in
net_forward_change() to disable the LRO feature of the device (which
is already disabled) is not enough, and in such case , GRO packets,
which want to be forwarded, will **not** be dropped in ip_forward().
(since kb_warn_if_lro() will return false in this case)
Is it so ? I am ready to send a patch fixing it, but I am a newbie in
kernel, so I want to ask first.
rgs,
Kevin
^ permalink raw reply
* Unwanted aliasing of UDP checksum failed error counter
From: Jeremy Jackson @ 2010-10-26 19:53 UTC (permalink / raw)
To: netdev
Trying to find source of packet loss on an 8node compute cluster, we find:
(not in this example, but on the real cluster)
in /proc/sys/net/snmp
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
Udp: 976460 1750 0 986795 0 0
InErrors *and* RcvbufErrors both go up with full socket buffer, this has
made troubleshooting our application more difficult. We were chasing UDP
checksum problems, until we checked linux source code, and found aliasing.
Is this done for assembly code efficiency? Any reason ENOMEM (ie socket
buffer full) can't avoid aliasing to UDP checksum failed errors?
in linux-source-2.6.32/net/ipv4/udp.c:__udp_queue_rcv_skb()
....
/* Note that an ENOMEM error is charged twice */
if (rc == -ENOMEM) {
UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_RCVBUFERRORS,
is_udplite);
atomic_inc(&sk->sk_drops);
}
goto drop;
...
drop:
UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
^ permalink raw reply
* [PATCH 10/22] [RFC] trivial: fix typos concerning "function"
From: Uwe Kleine-König @ 2010-10-26 19:57 UTC (permalink / raw)
To: trivial; +Cc: linux-kernel, netdev
In-Reply-To: <1288123039-22368-1-git-send-email-u.kleine-koenig@pengutronix.de>
I'm a bit unsure about this patch. I'm unable to parse both statements.
Cc: netdev@vger.kernel.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/isdn/hisax/isar.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hisax/isar.c b/drivers/isdn/hisax/isar.c
index 40b914b..2e72227 100644
--- a/drivers/isdn/hisax/isar.c
+++ b/drivers/isdn/hisax/isar.c
@@ -1427,8 +1427,8 @@ modeisar(struct BCState *bcs, int mode, int bc)
&bcs->hw.isar.reg->Flags))
bcs->hw.isar.dpath = 1;
else {
- printk(KERN_WARNING"isar modeisar analog funktions only with DP1\n");
- debugl1(cs, "isar modeisar analog funktions only with DP1");
+ printk(KERN_WARNING"isar modeisar analog functions only with DP1\n");
+ debugl1(cs, "isar modeisar analog functions only with DP1");
return(1);
}
break;
--
1.7.2.3
^ permalink raw reply related
* Re: netlink stats: Ability to get stats for a single device?
From: Eric Dumazet @ 2010-10-26 19:56 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev
In-Reply-To: <20101026.123811.13746869.davem@davemloft.net>
Le mardi 26 octobre 2010 à 12:38 -0700, David Miller a écrit :
> From: Ben Greear <greearb@candelatech.com>
> Date: Tue, 26 Oct 2010 12:31:12 -0700
>
> > Am I missing something, or do I just need to write up a patch
> > to have netlink pay attention to the ifindex?
>
> Setting the ->ifi_index or IFLA_IFNAME attribute values appropriately
> in the getlink request doesn't work?
>
> That should give you back, amonst other things, the rtnl_link_stats
> for the device in the netlink response.
> --
Yep, it should be easy to change iproute2 to not ask a full dump
in ip/ipaddress.c :
if (rtnl_wilddump_request(&rth, preferred_family, RTM_GETLINK) < 0) ...
and instead use rtnl_send() or something like that, if user provided one
specific interface name (or index)
ip link show dev eth0
^ permalink raw reply
* Re: [PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.
From: David Miller @ 2010-10-26 19:38 UTC (permalink / raw)
To: gwurster
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, shemminger,
eric.dumazet, herbert, ebiederm, netdev, linux-kernel
In-Reply-To: <201010161442.18748.gwurster@scs.carleton.ca>
From: Glenn Wurster <gwurster@scs.carleton.ca>
Date: Sat, 16 Oct 2010 14:42:17 -0400
> No, the first patch was to create a temporary address if none exists. Like
> Brian Haley pointed out, that patch accommodates the case where we set
> use_tempaddr to a non-zero value after the interface had been brought up.
>
> This patch accommodates the case where the router is only broadcasting
> advertisements every x seconds, and yet the user has set the valid_lft to be
> something less than x.
Ok, thanks for your patience.
I've applied both of your patches, thanks.
^ permalink raw reply
* Re: [PATCH] net: reset gso header when the copied skb is linearized
From: Herbert Xu @ 2010-10-26 19:38 UTC (permalink / raw)
To: David Miller; +Cc: fleitner, netdev
In-Reply-To: <20101026.122801.52191238.davem@davemloft.net>
On Tue, Oct 26, 2010 at 12:28:01PM -0700, David Miller wrote:
>
> Thus, if we linearize a larger than MSS sized frame, it should still
> have the same GSO attributes.
I agree with you on all counts :)
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: David Miller @ 2010-10-26 19:38 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4CC72C80.9010802@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 26 Oct 2010 12:31:12 -0700
> Am I missing something, or do I just need to write up a patch
> to have netlink pay attention to the ifindex?
Setting the ->ifi_index or IFLA_IFNAME attribute values appropriately
in the getlink request doesn't work?
That should give you back, amonst other things, the rtnl_link_stats
for the device in the netlink response.
^ permalink raw reply
* Re: netlink stats: Ability to get stats for a single device?
From: Eric Dumazet @ 2010-10-26 19:35 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4CC72C80.9010802@candelatech.com>
Le mardi 26 octobre 2010 à 12:31 -0700, Ben Greear a écrit :
> From what I can tell, it's impossible to request stats for a single
> network device via netlink. When you have thousands of interfaces,
> this means a lot of wasted effort to get stats for a particular
> device.
>
> Am I missing something, or do I just need to write up a patch
> to have netlink pay attention to the ifindex?
>
Its already done
rtnl_register(PF_UNSPEC, RTM_GETLINK, rtnl_getlink, rtnl_dump_ifinfo);
^ permalink raw reply
* netlink stats: Ability to get stats for a single device?
From: Ben Greear @ 2010-10-26 19:31 UTC (permalink / raw)
To: NetDev
From what I can tell, it's impossible to request stats for a single
network device via netlink. When you have thousands of interfaces,
this means a lot of wasted effort to get stats for a particular
device.
Am I missing something, or do I just need to write up a patch
to have netlink pay attention to the ifindex?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] ipv4: Flush per-ns routing cache more sanely.
From: Eric Dumazet @ 2010-10-26 19:30 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, netdev, daniel.lezcano
In-Reply-To: <20101026.122022.241452738.davem@davemloft.net>
Le mardi 26 octobre 2010 à 12:20 -0700, David Miller a écrit :
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Tue, 26 Oct 2010 12:05:39 -0700
>
> >> @@ -999,7 +999,7 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
> >> rt_cache_flush(dev_net(dev), 0);
> >> break;
> >> case NETDEV_UNREGISTER_BATCH:
> >> - rt_cache_flush_batch();
> >> + rt_cache_flush_batch(dev_net(dev));
> >
> > It still has this incorrect conversion in it.
>
> Sorry I missed that, what's the exact problem with it?
Because the way _BATCH operation is performed, we call it once...
rollback_registered_many() calls it for the first dev queued in the
list.
So it should be net independant.
^ permalink raw reply
* Re: [PATCH] net: reset gso header when the copied skb is linearized
From: David Miller @ 2010-10-26 19:28 UTC (permalink / raw)
To: fleitner; +Cc: netdev, herbert
In-Reply-To: <20101026192511.GA3494@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Tue, 26 Oct 2010 17:25:11 -0200
> If I understand that correctly, the gso_segs is the number
> of GSO segments which are divided in non-linear way. When the
> copy is made using that function, the skb turns into a big
> one segment inlined. So, the idea of segments is lost and
> I'm not seeing how it is going to be divided again.
> Later the NIC drives does, for example:
GSO has nothing to do with linearity, although it just so happens
to be that GSO packets tend to be non-linear due to the way
TCP builds such frames.
The GSO segment count is the number of MSS sized frames are
contained inside of a larger than MSS sized SKB.
That is it. So the definition and meaning is independent of
linearity.
Thus, if we linearize a larger than MSS sized frame, it should still
have the same GSO attributes.
^ 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