* Re: net-2.6.24 plans
From: David Miller @ 2007-09-18 0:04 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, akpm, linville, jgarzik
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C030EF13C@orsmsx418.amr.corp.intel.com>
From: "Nelson, Shannon" <shannon.nelson@intel.com>
Date: Mon, 17 Sep 2007 16:57:03 -0700
> >From: netdev-owner@vger.kernel.org
> >[mailto:netdev-owner@vger.kernel.org] On Behalf Of David Miller
> >Sent: Monday, September 17, 2007 2:18 PM
> >To: netdev@vger.kernel.org
> >Cc: akpm@linux-foundation.org; linville@tuxdriver.com;
> >jgarzik@pobox.com
> >Subject: Re: net-2.6.24 plans
> [...]
> >
> >Andrew, I removed the troublesome IOAT patch. The only conflicts
> >and fixes you should need at this point are:
> >
> [...]
>
> Which IOAT patch are you referring to?
The 'uninitialized variable' one, you should have a copy.
If not, Andrew definitely does.
^ permalink raw reply
* Re: net-2.6.24 plans
From: Andrew Morton @ 2007-09-18 0:04 UTC (permalink / raw)
To: Nelson, Shannon; +Cc: David Miller, netdev, linville, jgarzik
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C030EF13C@orsmsx418.amr.corp.intel.com>
On Mon, 17 Sep 2007 16:57:03 -0700
"Nelson, Shannon" <shannon.nelson@intel.com> wrote:
> >From: netdev-owner@vger.kernel.org
> >[mailto:netdev-owner@vger.kernel.org] On Behalf Of David Miller
> >Sent: Monday, September 17, 2007 2:18 PM
> >To: netdev@vger.kernel.org
> >Cc: akpm@linux-foundation.org; linville@tuxdriver.com;
> >jgarzik@pobox.com
> >Subject: Re: net-2.6.24 plans
> [...]
> >
> >Andrew, I removed the troublesome IOAT patch. The only conflicts
> >and fixes you should need at this point are:
> >
> [...]
>
> Which IOAT patch are you referring to?
>
A dopey one-liner which removes unused variable `u16 chanctrl'. It caused
rather a mess due to all the dma changes we have queued. It's under control.
^ permalink raw reply
* Re: net-2.6.24 plans
From: David Miller @ 2007-09-18 0:15 UTC (permalink / raw)
To: akpm; +Cc: netdev, linville, jgarzik, andy, romieu
In-Reply-To: <20070917165318.36a1f1a7.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 17 Sep 2007 16:53:18 -0700
> The Tehuti driver you should probably pull from the above git tree.
>
> Andy sent me a fix-it-for-net-2.6.24 patch which I'll send. It applies
> on top of the git tree.
>
> ipg-add-ip1000a-driver-to-kernel-tree.patch got broken by git-2.6.24 and I
> just disabled it in Kconfig. I'll send it anyway but someone will need to
> repair it. For some reason this driver doesn't have a changelog.
I integrated and fixed up the IPG IP1000A driver, I'll work on
the Tehuti merge after dinner.
Thanks Andrew.
^ permalink raw reply
* Quick benchmark for Mellanox 2-port 10Gbe NIC.
From: Ben Greear @ 2007-09-18 0:21 UTC (permalink / raw)
To: NetDev
I just managed to get a 2-port Mellanox 10Gbe pci-e NIC working with
2.6.23-rc6 + my hacks. There are some errors about scheduling
while atomic and such in the management path (ie, querying stats, etc),
but the data path looks pretty good.
At 1500 MTU I was able to send + rx 2.5Gbps on both ports using my
pktgen.
TCP maxed out at about 1.4Gbps send + rx, generated with my proprietary
user-space tool with MTU 1500. With MTU 8000, I can send + rx about 1.8Gbps.
When I change MTU to 8000 on the NICs, pktgen can send + rx about 4.5Gbps
at 4000 byte pkt sizes.
When sending one one port and receiving on the other, I can send 9+Gbps of
traffic, using MTU of 8000 and pktgen pkt size of 4000. Using larger pktgen pkt sizes slows traffic down
to around 7Gbps, probably due to extra page allocations.
So, there are some warts to be worked out in the driver, but the
raw performance looks pretty promising!
Take it easy,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: net-2.6.24 plans
From: David Miller @ 2007-09-18 1:51 UTC (permalink / raw)
To: akpm; +Cc: netdev, linville, jgarzik, andy, romieu
In-Reply-To: <20070917165318.36a1f1a7.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 17 Sep 2007 16:53:18 -0700
> The Tehuti driver you should probably pull from the above git tree.
Ok I added in the Tehuti driver to net-2.6.24 and made sure the
napi_struct conversion was good too.
That only leaves the wireless bits :-)
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: David Miller @ 2007-09-18 1:53 UTC (permalink / raw)
To: pjwaskiewicz
Cc: dlezcano, shemminger, netdev, ebiederm, containers,
benjamin.thery
In-Reply-To: <224b7d320709171212o66734847kbd17efa817b482fc@mail.gmail.com>
From: "Peter Waskiewicz" <pjwaskiewicz@gmail.com>
Date: Mon, 17 Sep 2007 12:12:24 -0700
> This would be a good opportunity to remove the single-allocated queue struct
> in netdevice (at the bottom) that we had to put in to accomodate the static
> loopback. Now we can set it back to a zero element list, and have
> alloc_netdev_mq() just allocate the number of queues requested, not
> num_queues - 1.
>
> I'll put a patch together based on this patchset.
Thanks Peter.
I'll also let this sit so that Eric can provide any feedback
he wants and also figure out how he will use this for the
namespace stuff.
^ permalink raw reply
* Re: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: David Miller @ 2007-09-18 1:58 UTC (permalink / raw)
To: ebiederm; +Cc: xemul, netdev, devel
In-Reply-To: <m1ir69tp7l.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Mon, 17 Sep 2007 07:07:42 -0600
> Pavel if you are going down this route. Could you look at
> cleanup_net as well. The reverse walk there could probably
> benefit from being list_for_each_entry_reverse.
Pavel please resubmit this work after everything has been
resolved, thanks.
If you have already, please resend as I don't have a copy.
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: David Miller @ 2007-09-18 2:01 UTC (permalink / raw)
To: hadi; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <1189975284.4230.14.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 16 Sep 2007 16:41:24 -0400
> Ok, maybe i am thinking too hard with that patch, so help me out:->
> When i looked at that code path as it is today: i felt the softirq could
> be interupted on the same CPU it is running on while it already grabbed
> that tx lock (if the trylock succeeds) and that the hardirq code when
> attempting to grab the lock would result in a deadlock.
Hardirq should never try to grab the netif_tx_lock(), it is
only for base and softirq context.
Any hardirq context code taking that lock needs to be fixed.
We could assert this if we don't already.
It's the only way that it works that we can invoke ->hard_start_xmit()
with interrupts fully enabled.
I notice that your patch bypasses the LLTX logic (I think) and this
isn't kosher, it might introduce deadlocks or similar as when we
are doing LLTX the driver determines the locking and IRQ context
semantics.
^ permalink raw reply
* Re: Please pull 'upstream-jgarzik' branch of wireless-2.6
From: Zhu Yi @ 2007-09-18 1:54 UTC (permalink / raw)
To: John W. Linville; +Cc: jeff, netdev, linux-wireless
In-Reply-To: <20070915132134.GD6060@tuxdriver.com>
On Sat, 2007-09-15 at 09:21 -0400, John W. Linville wrote:
> Jeff,
>
> A few more for 2.6.24...
Hi John, how is the iwlwifi driver going? Would you like to push it to
Jeff for .24? Or you'd like me to create a patch against this branch?
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
From: David Miller @ 2007-09-18 2:05 UTC (permalink / raw)
To: joe; +Cc: johannes, netdev, akpm, jgarzik
In-Reply-To: <1189798908.19708.170.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Fri, 14 Sep 2007 12:41:48 -0700
> David? Did you ever get a chance to look at this?
> Do you want me to rebase it against your newer net-2.4.26?
>
> http://repo.or.cz/w/linux-2.6/trivial-mods.git
How can I pull from this tree?
davem@sunset:~/src/GIT/mac_fmt-2.6$ git pull http://repo.or.cz/w/linux-2.6/trivial-mods.git
error: pick-rref: HEAD not found
No such ref HEAD at http://repo.or.cz/w/linux-2.6/trivial-mods.git
davem@sunset:~/src/GIT/mac_fmt-2.6$
Anyways, it would indeed help if you could rebase the patch
against net-2.6.24 It would save me a ton of time.
Thanks!
^ permalink raw reply
* Re: net-2.6.24 plans
From: Andy Gospodarek @ 2007-09-18 2:13 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linville, jgarzik, romieu
In-Reply-To: <20070917.185157.26533038.davem@davemloft.net>
On 9/17/07, David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Mon, 17 Sep 2007 16:53:18 -0700
>
> > The Tehuti driver you should probably pull from the above git tree.
>
> Ok I added in the Tehuti driver to net-2.6.24 and made sure the
> napi_struct conversion was good too.
>
> That only leaves the wireless bits :-)
>
Thanks, Dave! I'm building it right now....
^ permalink raw reply
* Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
From: Joe Perches @ 2007-09-18 2:14 UTC (permalink / raw)
To: David Miller; +Cc: johannes, netdev, akpm, jgarzik
In-Reply-To: <20070917.190527.42775386.davem@davemloft.net>
On Mon, 2007-09-17 at 19:05 -0700, David Miller wrote:
> Anyways, it would indeed help if you could rebase the patch
> against net-2.6.24 It would save me a ton of time.
I'll rebase it tomorrow against whatever's in
your current net-2.6.24.
cheers, Joe
^ permalink raw reply
* [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: lepton @ 2007-09-18 2:16 UTC (permalink / raw)
To: netdev; +Cc: lkm
Hi,
In some situation, icmp_reply and ip_send_reply will send
out packet with the wrong source addr, the following patch
will fix this.
I don't understand why we must use rt->rt_src in the current
code, if this is a wrong fix, please correct me.
Signed-off-by: Lepton Wu <ytht.net@gmail.com>
diff -X linux-2.6.22.6/Documentation/dontdiff -pru linux-2.6.22.6/net/ipv4/icmp.c linux-2.6.22.6-lepton/net/ipv4/icmp.c
--- linux-2.6.22.6/net/ipv4/icmp.c 2007-09-14 17:41:18.000000000 +0800
+++ linux-2.6.22.6-lepton/net/ipv4/icmp.c 2007-09-18 09:57:30.000000000 +0800
@@ -382,6 +382,7 @@ static void icmp_reply(struct icmp_bxm *
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
__be32 daddr;
+ struct iphdr *ip = ip_hdr(skb);
if (ip_options_echo(&icmp_param->replyopts, skb))
return;
@@ -393,7 +394,7 @@ static void icmp_reply(struct icmp_bxm *
icmp_out_count(icmp_param->data.icmph.type);
inet->tos = ip_hdr(skb)->tos;
- daddr = ipc.addr = rt->rt_src;
+ daddr = ipc.addr = ip->saddr;
ipc.opt = NULL;
if (icmp_param->replyopts.optlen) {
ipc.opt = &icmp_param->replyopts;
diff -X linux-2.6.22.6/Documentation/dontdiff -pru linux-2.6.22.6/net/ipv4/ip_output.c linux-2.6.22.6-lepton/net/ipv4/ip_output.c
--- linux-2.6.22.6/net/ipv4/ip_output.c 2007-09-14 17:41:18.000000000 +0800
+++ linux-2.6.22.6-lepton/net/ipv4/ip_output.c 2007-09-18 09:57:13.000000000 +0800
@@ -1337,11 +1337,12 @@ void ip_send_reply(struct sock *sk, stru
struct ipcm_cookie ipc;
__be32 daddr;
struct rtable *rt = (struct rtable*)skb->dst;
+ struct iphdr *ip = ip_hdr(skb);
if (ip_options_echo(&replyopts.opt, skb))
return;
- daddr = ipc.addr = rt->rt_src;
+ daddr = ipc.addr = ip->saddr;
ipc.opt = NULL;
if (replyopts.opt.optlen) {
^ permalink raw reply
* Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: David Miller @ 2007-09-18 2:20 UTC (permalink / raw)
To: ytht.net; +Cc: netdev, linux-kernel
In-Reply-To: <20070918021617.GA15540@router.lepton.home>
From: lepton <ytht.net@gmail.com>
Date: Tue, 18 Sep 2007 10:16:17 +0800
> Hi,
> In some situation, icmp_reply and ip_send_reply will send
> out packet with the wrong source addr, the following patch
> will fix this.
>
> I don't understand why we must use rt->rt_src in the current
> code, if this is a wrong fix, please correct me.
>
> Signed-off-by: Lepton Wu <ytht.net@gmail.com>
That the address is wrong is your opinion only :-)
Source address selection is a rather complex topic, and
here we are definitely purposefully using the source
address selected by the routing lookup for the reply.
^ permalink raw reply
* Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-09-18 2:26 UTC (permalink / raw)
To: ytht.net; +Cc: netdev, linux-kernel, davem, yoshfuji
In-Reply-To: <20070917.192044.48396034.davem@davemloft.net>
In article <20070917.192044.48396034.davem@davemloft.net> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <davem@davemloft.net> says:
> From: lepton <ytht.net@gmail.com>
> Date: Tue, 18 Sep 2007 10:16:17 +0800
>
> > Hi,
> > In some situation, icmp_reply and ip_send_reply will send
> > out packet with the wrong source addr, the following patch
> > will fix this.
> >
> > I don't understand why we must use rt->rt_src in the current
> > code, if this is a wrong fix, please correct me.
> >
> > Signed-off-by: Lepton Wu <ytht.net@gmail.com>
>
> That the address is wrong is your opinion only :-)
>
> Source address selection is a rather complex topic, and
> here we are definitely purposefully using the source
> address selected by the routing lookup for the reply.
And, if you do think something is "wrong", you need to describe it
in detail, at least.
--yoshfuji
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: Eric W. Biederman @ 2007-09-18 2:44 UTC (permalink / raw)
To: David Miller
Cc: pjwaskiewicz, dlezcano, shemminger, netdev, containers,
benjamin.thery
In-Reply-To: <20070917.185349.98863851.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: "Peter Waskiewicz" <pjwaskiewicz@gmail.com>
> Date: Mon, 17 Sep 2007 12:12:24 -0700
>
>> This would be a good opportunity to remove the single-allocated queue struct
>> in netdevice (at the bottom) that we had to put in to accomodate the static
>> loopback. Now we can set it back to a zero element list, and have
>> alloc_netdev_mq() just allocate the number of queues requested, not
>> num_queues - 1.
>>
>> I'll put a patch together based on this patchset.
>
> Thanks Peter.
>
> I'll also let this sit so that Eric can provide any feedback
> he wants and also figure out how he will use this for the
> namespace stuff.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Not that it doesn't already have my signed off by.
I have an earlier version of this patch sitting in my tree,
along with some additional patches to make this per namespace.
I don't really care which version of this patch goes in and
I'm happy to give Daniel credit for doing the final work to get this
patch merged.
I think it is important for bisect reasons that we first dynamically
allocate the loopback device and then make it per network namespace.
So someone can determine which part of the work caused a problem if
there is one.
Eric
^ permalink raw reply
* Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-18 2:48 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, kaber, dada1, johnpol
In-Reply-To: <20070917.190133.79431533.davem@davemloft.net>
On Mon, 2007-17-09 at 19:01 -0700, David Miller wrote:
> Hardirq should never try to grab the netif_tx_lock(), it is
> only for base and softirq context.
>
> Any hardirq context code taking that lock needs to be fixed.
> We could assert this if we don't already.
I snooped around it looks pretty clean; An assertion wont hurt,
but people will find _very quickly_ it hurts when testing a driver if
they did it wrong;->
> It's the only way that it works that we can invoke ->hard_start_xmit()
> with interrupts fully enabled.
> I notice that your patch bypasses the LLTX logic (I think) and this
> isn't kosher, it might introduce deadlocks or similar as when we
> are doing LLTX the driver determines the locking and IRQ context
> semantics.
Nothing much has changed from what it was before.
The only difference is we let go of the queue lock before grabbing
the tx lock which never mattered for LLTX.
Once we grab the tx lock it is the same logic and so far is working well
on both tg3 and e1000 (which is LLTX).
I will continue to retest with net-2.6.24 once you complete rebasing
and look around to see if anyone maybe affected.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: lepton @ 2007-09-18 2:48 UTC (permalink / raw)
Cc: ytht.net, netdev, linux-kernel, davem
In-Reply-To: <20070918.112644.28694997.yoshfuji@linux-ipv6.org>
Hi,
sorry for lack of details.
let's think about ip_send_reply. it is only called
by tcp_v4_send_ack and tcp_v4_reset. I don't know why
we need a source address diffrent from ip_hdr(skb)->s_addr
icmp_reply is only called by icmp_echo and icmp_timestamp.
Is there a situation to need we use a source address diffrent
from ip_hdr(skb)->s_addr?
My situaiton is:
I DNAT some tcp packet to my box. some times the box will
reply reset or ack packet with tcp_v4_send_ack and tcp_v4_reset,
when this happens, it will use the rt->s_addr instead of
ip_hdr(skb)->s_addr, then the packet will send out without change
the source addr. Becaus netfilter don't know these packets belongs
to the DNATed connection.
Another people's situaiton is (quoted from email to me):
While conducting a research about networking, I discovered
improper handling of ICMP echo reply messages in Linux 2.4.26. I
looked into the code and noticed that the icmp_reply function sets the
destination address in the reply packet to rt->rt_src. This produces
strange results in some cases as can be easily shown with hping and
tcpdump. Here is an example (NOTE: eth0 address is set to
10.10.10.1/24):
# tcpdump -n -i any icmp &
[1] 16842
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96
bytes
# hping2 --icmp --spoof 10.10.10.3 10.10.10.1
HPING 10.10.10.1 (eth0 10.10.10.1): icmp mode set, 28 headers + 0
data bytes
02:16:53.206016 IP 10.10.10.3 > 10.10.10.1: icmp 8: echo request seq
0
02:16:53.206082 IP 10.10.10.1 > 10.10.10.1: icmp 8: echo reply seq 0
02:16:54.202123 IP 10.10.10.3 > 10.10.10.1: icmp 8: echo request seq
If ICMP echo requests with a spoofed source address are sent to the
address of our eth0 interface (which of course happens through the
loopback interface), the code of icmp_reply sets the destination
address in the reply to 10.10.10.1 instead of simply reversing the
source and destination addresses as required by the RFC.
On Tue, Sep 18, 2007 at 11:26:44AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote:
> In article <20070917.192044.48396034.davem@davemloft.net> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <davem@davemloft.net> says:
>
> > From: lepton <ytht.net@gmail.com>
> > Date: Tue, 18 Sep 2007 10:16:17 +0800
> >
> > > Hi,
> > > In some situation, icmp_reply and ip_send_reply will send
> > > out packet with the wrong source addr, the following patch
> > > will fix this.
> > >
> > > I don't understand why we must use rt->rt_src in the current
> > > code, if this is a wrong fix, please correct me.
> > >
> > > Signed-off-by: Lepton Wu <ytht.net@gmail.com>
> >
> > That the address is wrong is your opinion only :-)
> >
> > Source address selection is a rather complex topic, and
> > here we are definitely purposefully using the source
> > address selected by the routing lookup for the reply.
>
> And, if you do think something is "wrong", you need to describe it
> in detail, at least.
>
> --yoshfuji
^ permalink raw reply
* Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: lepton @ 2007-09-18 2:59 UTC (permalink / raw)
Cc: ytht.net, netdev, linux-kernel, davem
In-Reply-To: <20070918.112644.28694997.yoshfuji@linux-ipv6.org>
Hi,
sorry for my previous email.
What I mean is icmp_reply and ip_send_reply
in some situation will send out packets with wrong
DESTINATION address. the source address is always
correct.
^ permalink raw reply
* Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: david @ 2007-09-18 3:14 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: ytht.net, netdev, linux-kernel, davem
In-Reply-To: <20070918.112644.28694997.yoshfuji@linux-ipv6.org>
On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B wrote:
> In article <20070917.192044.48396034.davem@davemloft.net> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <davem@davemloft.net> says:
>
>> From: lepton <ytht.net@gmail.com>
>> Date: Tue, 18 Sep 2007 10:16:17 +0800
>>
>>> Hi,
>>> In some situation, icmp_reply and ip_send_reply will send
>>> out packet with the wrong source addr, the following patch
>>> will fix this.
>>>
>>> I don't understand why we must use rt->rt_src in the current
>>> code, if this is a wrong fix, please correct me.
>>>
>>> Signed-off-by: Lepton Wu <ytht.net@gmail.com>
>>
>> That the address is wrong is your opinion only :-)
>>
>> Source address selection is a rather complex topic, and
>> here we are definitely purposefully using the source
>> address selected by the routing lookup for the reply.
>
> And, if you do think something is "wrong", you need to describe it
> in detail, at least.
I missed the beginning of the discussion, so apologies if I'm way off
base.
it sounds like the question is, when a packet hits the box that causes a
icmp_reply (or other packet) to be generated, which IP address should be
used as the source
1. the destination address of the packet that generated the message
or.
2. the IP address that the machine would use by default if the machine
were to generate a new connection to the destination.
I understand that in many cases the historical approach has been #2, but
as more machines get multiple IP addresses on each interface, I believe
that it's less of a surprise to other systems if the default is #1. most
of the time the other systems don't care (and useusally don't want to
know) if the service they are contacting is on a dedicated machine or is
just one IP among many sharing a box.
it gets especially bad when you have load balancing going on and the
results could come from multiple boxes.
yes, sysadmins deal with this today, but it's a pain to do so and is a
continuing dribble of suprises when things don't quite work the way you
expect them to as you consoldate things onto more powerful systems (or
distribute them among multiple systems).
if the packet got to the machine and the machine is accepting it, replying
back from the destination IP of that packet should be legitimate (it's
what you would do if there was a full connection after all) and greatly
reduces the cases where things change.
David Lang
^ permalink raw reply
* Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
From: lepton @ 2007-09-18 3:25 UTC (permalink / raw)
To: david
In-Reply-To: <Pine.LNX.4.64.0709172000430.24221@asgard.lang.hm>
Hi,
Sorry for my error.
The problem is the current icmp_reply and ip_send_reply will
send out packets with wrong destination address. Not wrong source
address.
My point is that we should always use the source address of packets we
received as the destination address of our reply packets.
On Mon, Sep 17, 2007 at 08:14:56PM -0700, david@lang.hm wrote:
> On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B wrote:
>
> >In article <20070917.192044.48396034.davem@davemloft.net> (at Mon, 17 Sep
> >2007 19:20:44 -0700 (PDT)), David Miller <davem@davemloft.net> says:
> >
> >>From: lepton <ytht.net@gmail.com>
> >>Date: Tue, 18 Sep 2007 10:16:17 +0800
> >>
> >>>Hi,
> >>> In some situation, icmp_reply and ip_send_reply will send
> >>> out packet with the wrong source addr, the following patch
> >>> will fix this.
> >>>
> >>> I don't understand why we must use rt->rt_src in the current
> >>> code, if this is a wrong fix, please correct me.
> >>>
> >>>Signed-off-by: Lepton Wu <ytht.net@gmail.com>
> >>
> >>That the address is wrong is your opinion only :-)
> >>
> >>Source address selection is a rather complex topic, and
> >>here we are definitely purposefully using the source
> >>address selected by the routing lookup for the reply.
> >
> >And, if you do think something is "wrong", you need to describe it
> >in detail, at least.
>
> I missed the beginning of the discussion, so apologies if I'm way off
> base.
>
> it sounds like the question is, when a packet hits the box that causes a
> icmp_reply (or other packet) to be generated, which IP address should be
> used as the source
>
> 1. the destination address of the packet that generated the message
>
> or.
>
> 2. the IP address that the machine would use by default if the machine
> were to generate a new connection to the destination.
>
> I understand that in many cases the historical approach has been #2, but
> as more machines get multiple IP addresses on each interface, I believe
> that it's less of a surprise to other systems if the default is #1. most
> of the time the other systems don't care (and useusally don't want to
> know) if the service they are contacting is on a dedicated machine or is
> just one IP among many sharing a box.
>
> it gets especially bad when you have load balancing going on and the
> results could come from multiple boxes.
>
> yes, sysadmins deal with this today, but it's a pain to do so and is a
> continuing dribble of suprises when things don't quite work the way you
> expect them to as you consoldate things onto more powerful systems (or
> distribute them among multiple systems).
>
> if the packet got to the machine and the machine is accepting it, replying
> back from the destination IP of that packet should be legitimate (it's
> what you would do if there was a full connection after all) and greatly
> reduces the cases where things change.
>
> David Lang
^ permalink raw reply
* [PATCH] sky2: fix VLAN receive processing
From: Stephen Hemminger @ 2007-09-18 5:08 UTC (permalink / raw)
To: Laurence Withers, Jeff Garzik, Pierre-Yves Ritschard; +Cc: netdev
In-Reply-To: <200709162129.53978.l@lwithers.me.uk>
The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Original patch by Pierre-Yves Ritschard but with additions.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-09-17 16:51:53.000000000 -0700
+++ b/drivers/net/sky2.c 2007-09-17 17:03:25.000000000 -0700
@@ -2103,6 +2103,13 @@ static struct sk_buff *sky2_receive(stru
struct sky2_port *sky2 = netdev_priv(dev);
struct rx_ring_info *re = sky2->rx_ring + sky2->rx_next;
struct sk_buff *skb = NULL;
+ u16 count = (status & GMR_FS_LEN) >> 16;
+
+#ifdef SKY2_VLAN_TAG_USED
+ /* Account for vlan tag */
+ if (sky2->vlgrp && (status & GMR_FS_VLAN))
+ count -= VLAN_HLEN;
+#endif
if (unlikely(netif_msg_rx_status(sky2)))
printk(KERN_DEBUG PFX "%s: rx slot %u status 0x%x len %d\n",
@@ -2117,7 +2124,8 @@ static struct sk_buff *sky2_receive(stru
if (!(status & GMR_FS_RX_OK))
goto resubmit;
- if (status >> 16 != length)
+ /* if length reported by DMA does not match PHY, packet was truncated */
+ if (length != count)
goto len_mismatch;
if (length < copybreak)
@@ -2133,6 +2141,10 @@ len_mismatch:
/* Truncation of overlength packets
causes PHY length to not match MAC length */
++sky2->net_stats.rx_length_errors;
+ if (netif_msg_rx_err(sky2) && net_ratelimit())
+ pr_info(PFX "%s: rx length mismatch: length %d status %#x\n",
+ dev->name, length, status);
+ goto resubmit;
error:
++sky2->net_stats.rx_errors;
--- a/drivers/net/sky2.h 2007-09-17 16:51:53.000000000 -0700
+++ b/drivers/net/sky2.h 2007-09-17 16:53:25.000000000 -0700
@@ -1668,7 +1668,7 @@ enum {
/* Receive Frame Status Encoding */
enum {
- GMR_FS_LEN = 0xffff<<16, /* Bit 31..16: Rx Frame Length */
+ GMR_FS_LEN = 0x7fff<<16, /* Bit 30..16: Rx Frame Length */
GMR_FS_VLAN = 1<<13, /* VLAN Packet */
GMR_FS_JABBER = 1<<12, /* Jabber Packet */
GMR_FS_UN_SIZE = 1<<11, /* Undersize Packet */
^ permalink raw reply
* Re: e1000 driver and samba
From: Bill Fink @ 2007-09-18 6:03 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: L F, Kok, Auke-jan H, James Chapman, netdev
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203592D77@orsmsx418.amr.corp.intel.com>
On Mon, 17 Sep 2007, Brandeburg, Jesse wrote:
> L F wrote:
> > On 9/17/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> >> The statistic we were looking at _will_ increase when running in
> >> half duplex, but if it increases when running in full duplex might
> >> indicate a hardware failure. Probably you have fixed the issue with
> >> the CAT6 cable.
> > Uhm, 'fixed' may be premature: I restarted the machine and with 22
> > hours uptime I am getting:
> > tx_deferred_ok: 36254
> >
> >> Can you run this new configuration with the old cable? that would
> >> eliminate the cable (or not)
> > I most certainly can. This seems to have gotten worse by a factor or
> > 100 or more.. so am I to suspect the new cable?
> >
> >> A single port failure on a switch can also happen, and samba is
> >> definately
> >> a good test for defective hardware. I cannot rule out anything from
> >> the information we have gotten yet.
> > True, but I tried changing the switch ports with little change.
> > Putting a client on the same switch port yielded no errors on the
> > client, although unfortunately I don't have ethtool statistics on XP.
> > The switch, btw, is a fairly generic GS108 from Netgear (there
> > actually are two).
>
> it may be not well documented, but the hardware has several states that
> it can get into that can cause tx_deferred counter to increment. None
> of them are fatal to traffic, it is mainly an informational statistic.
>
> in this case it is in the "due to receiving flow control; tx is paused"
> state...
>
> he has 488 rx flow control xoff/xon, which means the switch is being
> overloaded and sending flow control, or the switch is passing through
> flow control packets (which it should not since they are multicast) and
> (some) client is overloaded.
>
> can you turn off flow control at the server? ethtool -A ethX rx off tx
> off or load the driver with parameter FlowControl=0 With the 7.6.5
> driver at least you'll get confirmation of the flow control change on
> the "Link Up:" line.
It may also be a useful test to disable hardware TSO support
via "ethtool -K ethX tso off".
-Bill
^ permalink raw reply
* Re: [PATCH 7/7] CAN: Add documentation
From: Bill Fink @ 2007-09-18 6:51 UTC (permalink / raw)
To: Urs Thuermann
Cc: Thomas Gleixner, Randy Dunlap, netdev, David Miller,
Patrick McHardy, Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <ygflkb5rp9d.fsf@janus.isnogud.escape.de>
On 17 Sep 2007, Urs Thuermann wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > Please do, having the patch in mail makes it easier to review and to
> > comment.
>
> OK, here it is:
One more typo.
> This patch adds documentation for the PF_CAN protocol family.
>
> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
> Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
>
> ---
> Documentation/networking/00-INDEX | 2
> Documentation/networking/can.txt | 635 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 637 insertions(+)
>
> Index: net-2.6.24/Documentation/networking/can.txt
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ net-2.6.24/Documentation/networking/can.txt 2007-09-17 21:57:29.000000000 +0200
> @@ -0,0 +1,635 @@
> +============================================================================
> +
> +can.txt
> +
> +Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
> +
> +This file contains
> +
> + 1 Overview / What is Socket CAN
> +
> + 2 Motivation / Why using the socket API
> +
...
> +============================================================================
> +
> +1. Overview / What is Socket CAN
> +--------------------------------
> +
> +The socketcan package is an implementation of CAN protocols
> +(Controller Area Network) for Linux. CAN is a networking technology
> +which has widespread use in automation, embedded devices, and
> +automotive fields. While there have been other CAN implementations
> +for Linux based on character devices, Socket CAN uses the Berkeley
> +socket API, the Linux network stack and implements the CAN device
> +drivers as network interfaces. The CAN socket API has been designed
> +as similar as possible to the TCP/IP protocols to allow programmers,
> +familiar with network programming, to easily learn how to use CAN
> +sockets.
> +
> +2. Motivation / Why using the socket API
> +----------------------------------------
> +
> +There have been CAN implementations for Linux before Socket CAN so the
> +question arises, why we have started another project. Most existing
> +implementations come as a device driver for some CAN hardware, they
> +are based on character devices and provide comparatively little
> +functionality. Usually, there is only a hardware-specific device
> +driver which provides a character device interface to send and
> +receive raw CAN frames, directly to/from the controller hardware.
> +Queueing of frames and higher-level transport protocols like ISO-TP
> +have to be implemented in user space applications. Also, most
> +character-device implementations support only one single process to
> +open the device at a time, similar to a serial interface. Exchanging
> +the CAN controller requires employment of another device driver and
> +often the need for adaption of large parts of the application to the
> +new driver's API.
> +
> +Socket CAN was designed to overcome all of these limitations. A new
> +protocol family has been implemented which provides a socket interface
> +to user space applications and which builds upon the Linux network
> +layer, so to use all of the provided queueing functionality. A device
> +driver for CAN controller hardware registers itself with the Linux
> +network layer as a network device, so that CAN frames from the
> +controller can be passed up to the network layer and on to the CAN
> +protocol family module and also vice-versa. Also, the protocol family
> +module provides an API for transport protocol modules to register, so
> +that any number of transport protocols can be loaded or unloaded
> +dynamically. In fact, the can core module alone does not provide any
> +protocol and cannot be used without loading at least one additional
> +protocol module. Multiple sockets can be opened at the same time,
> +on different or the same protocol module and they can listen/send
> +frames on different or the same CAN IDs. Several sockets listening on
> +the same interface for frames with the same CAN ID are all passed the
> +same received matching CAN frames. An application wishing to
> +communicate using a specific transport protocol, e.g. ISO-TP, just
> +selects that protocol when opening the socket, and then can read and
> +write application data byte streams, without having to deal with
> +CAN-IDs, frames, etc.
> +
> +Similar functionality visible from user-space could be provided by a
> +character decive, too, but this would lead to a technically inelegant
> +solution for a couple of reasons:
"decive" -> "device" above.
-Bill
^ permalink raw reply
* Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
From: Jack Morgenstein @ 2007-09-18 7:09 UTC (permalink / raw)
To: general; +Cc: Roland Dreier, linux-kernel, netdev, tziporet
In-Reply-To: <adahclymos8.fsf@cisco.com>
On Thursday 13 September 2007 20:57, Roland Dreier wrote:
> HW specific:
>
> - I already merged patches to enable MSI-X by default for mthca and
> mlx4. I hope there aren't too many systems that get hosed if a
> MSI-X interrupt is generated.
>
> - Jack and Michael's mlx4 FMR support. Will merge I guess, although
> I do hope to have time to address the DMA API abuse that is being
> copied from mthca, so that mlx4 and mthca work in Xen domU.
>
> - ehca patch queue. Will merge, pending fixes for the few minor
> issues I commented on.
>
> - Steve's mthca router mode support. Would be nice to see a review
> from someone at Mellanox.
>
> - Arthur's mthca doorbell alignment fixes. I will experiment with a
> few different approaches and post what I like (and fix mlx4 as
> well). I hope Arthur can review.
>
> - Michael's mlx4 WQE shrinking patch. Not sure yet; I'll reply to
> the latest patch directly.
>
Missing from this list (IMPORTANT patch!):
[ofa-general] [PATCH 2 of 2] IB/mlx4: Handle new FW requirement for send request prefetching, for WQE sg lists
(Posted by me to list on Sept 4)
{patch header:
This is an addendum to Roland's commit 0e6e74162164d908edf7889ac66dca09e7505745
(June 18). This addendum adds prefetch headroom marking processing for s/g segments.
We write s/g segments in reverse order into the WQE, in order to guarantee
that the first dword of all cachelines containing s/g segments is written last
(overwriting the headroom invalidation pattern). The entire cacheline will thus
contain valid data when the invalidation pattern is overwritten.
}
This patch series (1 of 2 is for libmlx4, the same issue).
============================================================
Also, I'm now posting (in a separate post) the following patch to mlx4, which is important:
display the following device information via sysfs:
board_id, fw_ver, hw_rev, hca_type.
The info is displayed under directory /sys/class/infiniband/mlx4_x, where x is
the pci bus sequence number (starting from zero).
This patch makes information available to ibstat and ibv_devinfo under the
same directory as is used for tavor/arbel/sinai -- thus requiring no userspace
modifications.
- Jack
^ 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