* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-14 22:14 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <4D7E928C.1030707@cbnco.com>
From: Michael Smith <msmith@cbnco.com>
Date: Mon, 14 Mar 2011 18:11:24 -0400
> David Miller wrote:
>> I was trying to get you to think out of the box and come up with
>> something clever, but that isn't working. :-)
>
> Yes, I got that, but I don't know what you are looking for, and don't
> expect to succeed by trying something else at random.
Existing arguments might be large enough to carry more than one piece
of information :-)
>> In short, fib_validate_source() is nothing but completely unnecessary
>> overhead in the common case.
>
> I'm not entitled to an opinion about fib_validate_source(). It feels
> like it might be trying to do one too many things. If it were my code
> I might split the RPF out from the spec_dst calculation, move the
> whole lot into net/ipv4/route.c, and only do the fib_lookup() if RPF
> is enabled or CONFIG_IP_ROUTE_CLASSID (i.e. we need to know the itag).
Can't split two two things up, because spec_dst is a product of the
reverse FIB lookup, in the form of FIB_RES_PREFSRC().
^ permalink raw reply
* Re: [PATCH NEXT 1/2] netxen: Notify firmware of Flex-10 interface down
From: David Miller @ 2011-03-14 22:14 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1299837003-5616-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 11 Mar 2011 01:50:02 -0800
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> Notify firmware when a Flex-10 interface is brought down
> so that virtual connect manager can display the correct link status.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: David Miller @ 2011-03-14 22:15 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1299837003-5616-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Fri, 11 Mar 2011 01:50:03 -0800
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> o Allow setting speed and auto negotiation parameters for GbE ports.
> o Log an error message to indicate duplex setting is not supported in
> the hardware currently.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
The kernel log is not the place to transmit this information.
Please work with Ben Hutchings who is working for ways to report
this to the user in the proper location, via ethtool.
^ permalink raw reply
* Re: [PATCH net-next-2.6] be2net: changes for BE3 native mode support
From: David Miller @ 2011-03-14 22:17 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <9260707d-e902-4497-a550-a5125c46e2c4@exht1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 11 Mar 2011 18:19:26 +0530
> So far be2net has been using BE3 in legacy mode. It now checks for native
> mode capability and if available it sets it. In native mode, the RX_COMPL
> structure is different from that in legacy mode.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT/PATCH v5] xen network backend driver
From: Ian Campbell @ 2011-03-14 22:17 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, netdev@vger.kernel.org,
xen-devel@lists.xensource.com, jeremy@goop.org,
herbert@gondor.apana.org.au, konrad.wilk@oracle.com,
romieu@fr.zoreil.com, shemminger@vyatta.com, mirqus@gmail.com
In-Reply-To: <20110314.132355.226777213.davem@davemloft.net>
On Mon, 2011-03-14 at 20:23 +0000, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Date: Mon, 14 Mar 2011 19:30:40 +0000
>
> > On Mon, 2011-03-14 at 18:40 +0000, Ben Hutchings wrote:
> >> I know you have asked for this to be pulled, in order to retain its
> >> history, but I'm not sure that David Miller will do this unless the
> >> driver is at least buildable at each stage in the history. (However,
> >> given that the driver wouldn't be enabled before it's added, I'm not
> >> sure it matters in this case.)
> >
> > I think it should be, at least from the second commit onwards (modulo
> > any mistakes made in the past).
>
> I don't want to retain all of that history, there are so many broken
> points in the history that the only thing you can do is go back and
> add Kconfig commits to depend the driver upon BROKEN, and that in effect
> changes the history devalueing it even further.
>
> I just want one patch that adds the driver in it's most current state,
> and that's all.
Would you consider a commit patch which imports the baseline driver as
is from xen.git (this builds and is functional but needed clean up)
followed by the cleanup series? I made sure the cleanup part builds and
works at each step as I went (but I will run through it again to be
sure).
There is real value (to me at least) in keeping the cleanup separate and
being able to (even manually) associate the first upstream commit with
an equivalent point in the historical code.
IOW 1952b4d9e6c8..072407c789a0 collapse to a single commit followed by
(s/0724.../$COLLAPSED COMMIT ID/):
The following changes since commit 072407c789a0cdc6b8adba49d5bbfac5d5feb9d3:
Ian Campbell (1):
xen: netback: handle incoming GSO SKBs which are not CHECKSUM_PARTIAL
are available in the git repository at:
git://xenbits.xen.org/people/ianc/linux-2.6.git upstream/dom0/backend/netback
Ian Campbell (38):
xen: netback: rationalise types used in count_skb_slots
xen: netback: refactor logic for moving to a new receive buffer.
xen: netback: refactor code to get next rx buffer into own function.
xen: netback: simplify use of netbk_add_frag_responses
xen: netback: cleanup coding style
xen: netback: drop private ?PRINTK macros in favour of pr_*
xen: netback: move under drivers/net/xen-netback/
xen: netback: remove queue_length module option
xen: netback: correct error return from ethtool hooks.
xen: netback: avoid leading _ in function parameter names.
xen: netback: drop unused debug interrupt handler.
xen: netif: properly namespace the Xen netif protocol header.
xen: netif: improve Kconfig help text for front- and backend drivers.
xen: netback: drop ethtool drvinfo callback
xen: netback: use xen_netbk prefix where appropriate
xen: netback: refactor to make all xen_netbk knowledge internal to netback.c
xen: netback: use xenvif_ prefix where appropriate
xen: netback: add reference from xenvif to xen_netbk
xen: netback: refactor to separate network device from worker pools
xen: netback: switch to kthread mode and drop tasklet mode
xen: netback: handle frames whose head crosses a page boundary
xen: netback: return correct values from start_xmit
xen: netback: remove useless memset to zero.
xen: netback: use register_netdev()
xen: netback: simplify unwinding netback_init's work on failure.
xen: netback: use core network carrier flag.
xen: netback: s/xenvif_queue_full/xenvif_rx_queue_full/
xen: netback: add xenvif_rx_schedulable
xen: netback: further separate xen_netbk and xenvif
xen: netback: use netdev_LEVEL instead of pr_LEVEL
xen: netback: drop rx_notify and notify_list array in favour of a normal list
xen: netback: Make dependency on PageForeign conditional
xen: netback: completely drop foreign page support
xen: netback: ethtool stats fields should be unsigned long
xen: netback: do not update last_rx on receive.
xen: netback: Allow headroom for VLAN header in SG MTU calculation.
xen: netback: use stats from struct net_device
xen: netback: netdevice features should be u32
drivers/net/Kconfig | 38 +-
drivers/net/Makefile | 1 +
drivers/{xen/netback => net/xen-netback}/Makefile | 0
drivers/net/xen-netback/common.h | 161 ++
drivers/net/xen-netback/interface.c | 424 +++++
drivers/net/xen-netback/netback.c | 1745 +++++++++++++++++++
drivers/{xen/netback => net/xen-netback}/xenbus.c | 155 +-
drivers/net/xen-netfront.c | 20 +-
drivers/xen/Kconfig | 7 -
drivers/xen/Makefile | 1 -
drivers/xen/netback/common.h | 326 ----
drivers/xen/netback/interface.c | 471 -----
drivers/xen/netback/netback.c | 1902 ---------------------
include/xen/interface/io/netif.h | 80 +-
14 files changed, 2483 insertions(+), 2848 deletions(-)
rename drivers/{xen/netback => net/xen-netback}/Makefile (100%)
create mode 100644 drivers/net/xen-netback/common.h
create mode 100644 drivers/net/xen-netback/interface.c
create mode 100644 drivers/net/xen-netback/netback.c
rename drivers/{xen/netback => net/xen-netback}/xenbus.c (75%)
delete mode 100644 drivers/xen/netback/common.h
delete mode 100644 drivers/xen/netback/interface.c
delete mode 100644 drivers/xen/netback/netback.c
^ permalink raw reply
* Re: [GIT/PATCH v5] xen network backend driver
From: David Miller @ 2011-03-14 22:22 UTC (permalink / raw)
To: Ian.Campbell
Cc: bhutchings, netdev, xen-devel, jeremy, herbert, konrad.wilk,
romieu, shemminger, mirqus
In-Reply-To: <1300141060.32696.36.camel@localhost.localdomain>
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
Date: Mon, 14 Mar 2011 22:17:40 +0000
> Would you consider a commit patch which imports the baseline driver as
> is from xen.git (this builds and is functional but needed clean up)
> followed by the cleanup series? I made sure the cleanup part builds and
> works at each step as I went (but I will run through it again to be
> sure).
>
> There is real value (to me at least) in keeping the cleanup separate and
> being able to (even manually) associate the first upstream commit with
> an equivalent point in the historical code.
Do you have any idea what that thing is going to do for poor souls trying
to bisect?
GIT is going to hop in and out of your line of development for any GIT
bisect that traverses any period of time in which those driver commits
exists.
It's too messy.
You can keep your tree online somewhere to publish the history, just
like we do for the old bitkeeper import and similar.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-14 22:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110314.151424.212690587.davem@davemloft.net>
David Miller wrote:
> Existing arguments might be large enough to carry more than one piece
> of information :-)
If it's encoded into another argument, would there be more overhead from
bit-shifting it out than you'd save by losing an argument?
>> I might split the RPF out from the spec_dst calculation, move the
>> whole lot into net/ipv4/route.c, and only do the fib_lookup() if RPF
>> is enabled or CONFIG_IP_ROUTE_CLASSID (i.e. we need to know the itag).
>
> Can't split two two things up, because spec_dst is a product of the
> reverse FIB lookup, in the form of FIB_RES_PREFSRC().
True, but the result of the reverse FIB lookup could be passed around.
Mike
^ permalink raw reply
* Re: [PATCH 1/2] NET: cdc-phonet, fix stop-queue handling
From: David Miller @ 2011-03-14 22:23 UTC (permalink / raw)
To: remi.denis-courmont
Cc: jslaby, jirislaby, netdev, gregkh, linux-usb, linux-kernel
In-Reply-To: <201103140939.57056.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Mon, 14 Mar 2011 09:39:56 +0200
> On Sunday 13 March 2011 18:54:30 ext Jiri Slaby, you wrote:
>> Currently there is a warning emitted by the cdc-phonet driver:
>> WARNING: at include/linux/netdevice.h:1557 usbpn_probe+0x3bb/0x3f0
>> [cdc_phonet]() Modules linked in: ...
>> Pid: 5877, comm: insmod Not tainted 2.6.37.3-16-desktop #1
>> Call Trace:
>> [<ffffffff810059b9>] dump_trace+0x79/0x340
>> [<ffffffff81520fdc>] dump_stack+0x69/0x6f
>> [<ffffffff810580eb>] warn_slowpath_common+0x7b/0xc0
>> [<ffffffffa00254fb>] usbpn_probe+0x3bb/0x3f0 [cdc_phonet]
>> ...
>> ---[ end trace f5d3e02908603ab4 ]---
>> netif_stop_queue() cannot be called before register_netdev()
>>
>> So remove netif_stop_queue from the probe funtction to avoid that.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>> Cc: David S. Miller <davem@davemloft.net>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] NET: cdc-phonet, handle empty phonet header
From: David Miller @ 2011-03-14 22:24 UTC (permalink / raw)
To: remi.denis-courmont
Cc: jslaby, jirislaby, netdev, gregkh, linux-usb, linux-kernel
In-Reply-To: <201103140949.04760.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Mon, 14 Mar 2011 09:49:04 +0200
> On Sunday 13 March 2011 18:54:31 ext Jiri Slaby, you wrote:
>> Currently, for N 5800 XM I get:
>> cdc_phonet: probe of 1-6:1.10 failed with error -22
>>
>> It's because phonet_header is empty. Extra altsetting looks like
>> there:
>> E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd .$....$..$....$.
>> E 00 .
>>
>> I don't see the header used anywhere so just check if the phonet
>> descriptor is there, not the structure itself.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>> Cc: David S. Miller <davem@davemloft.net>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] af_unix: update locking comment
From: David Miller @ 2011-03-14 22:26 UTC (permalink / raw)
To: dbaluta; +Cc: eric.dumazet, netdev, daniel.baluta
In-Reply-To: <1300047106-8545-1-git-send-email-dbaluta@ixiacom.com>
From: dbaluta@ixiacom.com
Date: Sun, 13 Mar 2011 22:11:46 +0200
> We latch our state using a spinlock not a r/w kind of lock.
>
> Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-14 22:27 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <4D7E9558.7030102@cbnco.com>
From: Michael Smith <msmith@cbnco.com>
Date: Mon, 14 Mar 2011 18:23:20 -0400
> David Miller wrote:
>
>> Existing arguments might be large enough to carry more than one piece
>> of information :-)
>
> If it's encoded into another argument, would there be more overhead
> from bit-shifting it out than you'd save by losing an argument?
It sure will if it's the different between the argument being passed
in a register vs. on the stack.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Ben Hutchings @ 2011-03-14 22:30 UTC (permalink / raw)
To: David Miller
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <20110314.151531.233692938.davem@davemloft.net>
On Mon, 2011-03-14 at 15:15 -0700, David Miller wrote:
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Date: Fri, 11 Mar 2011 01:50:03 -0800
>
> > From: Sony Chacko <sony.chacko@qlogic.com>
> >
> > o Allow setting speed and auto negotiation parameters for GbE ports.
> > o Log an error message to indicate duplex setting is not supported in
> > the hardware currently.
> >
> > Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> The kernel log is not the place to transmit this information.
>
> Please work with Ben Hutchings who is working for ways to report
> this to the user in the proper location, via ethtool.
I am? Well, patches welcome, at least.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: David Miller @ 2011-03-14 22:32 UTC (permalink / raw)
To: bhutchings
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <1300141822.2584.71.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Mar 2011 22:30:22 +0000
> On Mon, 2011-03-14 at 15:15 -0700, David Miller wrote:
>> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>> Date: Fri, 11 Mar 2011 01:50:03 -0800
>>
>> > From: Sony Chacko <sony.chacko@qlogic.com>
>> >
>> > o Allow setting speed and auto negotiation parameters for GbE ports.
>> > o Log an error message to indicate duplex setting is not supported in
>> > the hardware currently.
>> >
>> > Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
>> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>>
>> The kernel log is not the place to transmit this information.
>>
>> Please work with Ben Hutchings who is working for ways to report
>> this to the user in the proper location, via ethtool.
>
> I am? Well, patches welcome, at least.
You were discussing a scheme, I think with Intel folks, about letting
such changes through then making ethtool re-read the settings and see
which changes were not integrated by the driver.
Then you'd emit a diagnostic from ethtool over stderr to report any
such discrepencies.
^ permalink raw reply
* Re: [PATCH] Fix possible null pointer dereference in ehea_qmr.c
From: David Miller @ 2011-03-14 22:34 UTC (permalink / raw)
To: huzaifas; +Cc: netdev, leitao
In-Reply-To: <1300088764-9330-1-git-send-email-huzaifas@redhat.com>
From: huzaifas@redhat.com
Date: Mon, 14 Mar 2011 13:16:04 +0530
> From: Huzaifa Sidhpurwala <huzaifas@redhat.com>
>
> If queue is zero, dont reference it
>
> Signed-off-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
There is no code path where hw_queue_dtor() is called with a NULL
"queue". I've checked all of the code paths.
Therefore it's better to simply remove the NULL check.
^ permalink raw reply
* Re: [PATCH] Fix possible null pointer dereference in davinci_cpdma.c
From: David Miller @ 2011-03-14 22:36 UTC (permalink / raw)
To: huzaifas; +Cc: netdev, khilman, cyril
In-Reply-To: <1300091954-10367-1-git-send-email-huzaifas@redhat.com>
From: huzaifas@redhat.com
Date: Mon, 14 Mar 2011 14:09:14 +0530
> From: Huzaifa Sidhpurwala <huzaifas@redhat.com>
>
> Check if chan exists before dereferencing it
>
> Signed-off-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
Just like your EHEA driver patch, this situation is such that
cpdma_chan_destroy() is never called with a NULL "chan" argument.
Therefore it's better to simply remove the NULL check.
^ permalink raw reply
* Re: [PATCH] bonding: documentation update: mailing lists.
From: David Miller @ 2011-03-14 22:37 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: fubar, andy, netdev
In-Reply-To: <1300048462-4486-1-git-send-email-nicolas.2p.debian@free.fr>
From: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Date: Sun, 13 Mar 2011 21:34:22 +0100
> In commit a6c36ee677607b02d8ecc88e8a12785418b88107 ("bonding: change list
> contact to netdev@vger.kernel.org"), the mailing list for bonding
> developpement was changed from bonding-devel to netdev.
>
> Update the bonding documentation to reflect this change:
>
> - bonding-devel is used for usage discussions (despite the name).
> - netdev is used for developpement discussions.
>
> Also remove the reference to the sourceforge bonding page, which is
> deprecated.
>
> Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Applied, thanks Nicolas.
^ permalink raw reply
* Re: [patch 1/1] [PATCH] qeth: change some configurations defaults
From: David Miller @ 2011-03-14 22:40 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20110314132127.374926261@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Mon, 14 Mar 2011 14:20:54 +0100
> This patch turns on RX checksum and GRO by default. To improve
> receiving performance and reduce congestion in case of network
> bursts we also increase the default number of inbound buffers.
>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Applied, thanks Frank.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] ftmac100: use GFP_ATOMIC allocations where needed
From: David Miller @ 2011-03-14 22:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: ratbert.chuang, netdev, linux-kernel, ratbert
In-Reply-To: <1300112791.3423.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Mar 2011 15:26:31 +0100
> When running in softirq context, we should use GFP_ATOMIC allocations
> instead of GFP_KERNEL ones.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Po-Yu Chuang <ratbert@faraday-tech.com>
> Acked-by: Po-Yu Chuang <ratbert@faraday-tech.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Ben Hutchings @ 2011-03-14 22:44 UTC (permalink / raw)
To: David Miller
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <20110314.153240.241445951.davem@davemloft.net>
On Mon, 2011-03-14 at 15:32 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 14 Mar 2011 22:30:22 +0000
>
> > On Mon, 2011-03-14 at 15:15 -0700, David Miller wrote:
> >> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> >> Date: Fri, 11 Mar 2011 01:50:03 -0800
> >>
> >> > From: Sony Chacko <sony.chacko@qlogic.com>
> >> >
> >> > o Allow setting speed and auto negotiation parameters for GbE ports.
> >> > o Log an error message to indicate duplex setting is not supported in
> >> > the hardware currently.
> >> >
> >> > Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> >> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> >>
> >> The kernel log is not the place to transmit this information.
> >>
> >> Please work with Ben Hutchings who is working for ways to report
> >> this to the user in the proper location, via ethtool.
> >
> > I am? Well, patches welcome, at least.
>
> You were discussing a scheme, I think with Intel folks, about letting
> such changes through then making ethtool re-read the settings and see
> which changes were not integrated by the driver.
>
> Then you'd emit a diagnostic from ethtool over stderr to report any
> such discrepencies.
Only for offload settings, where the API makes it clear which flags the
user is deliberately setting and the kernel or driver can reasonably fix
up others. For link settings, that isn't clear, and drivers should
simply reject invalid combinations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: David Miller @ 2011-03-14 22:54 UTC (permalink / raw)
To: bhutchings
Cc: amit.salecha, netdev, ameen.rahman, anirban.chakraborty,
sony.chacko
In-Reply-To: <1300142648.2584.76.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Mar 2011 22:44:08 +0000
> For link settings, that isn't clear, and drivers should simply
> reject invalid combinations.
Ok, makes sense.
Amit please update your patch to silently reject link setting attempts
that are unsupported by the device.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/7] TCP CUBIC Hystart fixes
From: David Miller @ 2011-03-14 22:58 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110314175211.788224699@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 14 Mar 2011 10:52:11 -0700
> This is the merge of my patches and recent update Sangtae.
> It addresses the problems reported by Lucas Nussbaum that Hystart causes
> poor startup performance over links with lots of buffering.
Ok, I've applied all of this to net-2.6 and did test builds with HZ={100,250,1000}
on both sparc64 and x86.
I'll let it cook for a day or two before pushing it out to Linus.
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS
From: Simon Horman @ 2011-03-14 23:13 UTC (permalink / raw)
To: Patrick McHardy
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Hans Schillstrom,
Julian Anastasov
In-Reply-To: <4D7E5BBE.7060702@trash.net>
On Mon, Mar 14, 2011 at 07:17:34PM +0100, Patrick McHardy wrote:
> On 13.03.2011 23:44, Simon Horman wrote:
> > Hi Patrick,
> >
> > please consider pulling
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
> > to get the following changes.
> >
> > Jesper Juhl (1):
> > Fix variable assignment in ip_vs_notrack
> >
> > Julian Anastasov (2):
> > ipvs: avoid lookup for fwmark 0
> > ipvs: remove _bh from percpu stats reading
> >
> > Shan Wei (1):
> > netfilter:ipvs: use kmemdup
> >
> > include/net/ip_vs.h | 2 +-
> > net/netfilter/ipvs/ip_vs_ctl.c | 8 +++++---
> > net/netfilter/ipvs/ip_vs_est.c | 8 ++++----
> > net/netfilter/ipvs/ip_vs_pe_sip.c | 9 ++++-----
> > net/netfilter/ipvs/ip_vs_sync.c | 3 +--
> > 5 files changed, 15 insertions(+), 15 deletions(-)
>
> The pull contained quite a lot of other changes. I'm undoing the
> pull for now, please resubmit the patches you actually want me to
> pull. Thanks!
Sorry about that. I will double check things but
the list below looks like the second request that I sent out
yesterday.
>
> Jesper Juhl (1):
> Fix variable assignment in ip_vs_notrack
>
> Julian Anastasov (8):
> ipvs: avoid lookup for fwmark 0
> ipvs: remove _bh from percpu stats reading
> ipvs: move struct netns_ipvs
> ipvs: reorganize tot_stats
> ipvs: properly zero stats and rates
> ipvs: remove unused seqcount stats
> ipvs: optimize rates reading
> ipvs: rename estimator functions
>
> Patrick McHardy (1):
> Merge branch 'master' of git://git.kernel.org/.../horms/lvs-test-2.6
>
> Shan Wei (1):
> netfilter:ipvs: use kmemdup
>
> Simon Horman (14):
> IPVS: Add ip_vs_route_me_harder()
> IPVS: Add sysctl_snat_reroute()
> IPVS: Add sysctl_nat_icmp_send()
> IPVS: Add {sysctl_sync_threshold,period}()
> IPVS: Add sysctl_sync_ver()
> IPVS: Add sysctl_expire_nodest_conn()
> IPVS: Add expire_quiescent_template()
> IPVS: Conditinally use sysctl_lblc{r}_expiration
> IPVS: ip_vs_todrop() becomes a noop when CONFIG_SYSCTL is undefined
> IPVS: Conditional ip_vs_conntrack_enabled()
> IPVS: Minimise ip_vs_leave when CONFIG_SYSCTL is undefined
> IPVS: Conditionally define and use ip_vs_lblc{r}_table
> IPVS: Add __ip_vs_control_{init,cleanup}_sysctl()
> IPVS: Conditionally include sysctl members of struct netns_ipvs
>
^ permalink raw reply
* Multicast Fails Over Multipoint GRE Tunnel
From: Doug Kehn @ 2011-03-14 23:34 UTC (permalink / raw)
To: netdev
Hi All,
I'm running kernel version 2.6.36 on ARM XSCALE (big-endian) and multicast over a multipoint GRE tunnel isn't working. For my architecture, this worked on 2.6.26.8. For x86, multicast over a multipoint GRE tunnel worked with kernel version 2.6.31 but failed with version 2.6.35. Multicast over a multipoint GRE tunnel fails because ipgre_header() fails the 'if (iph->daddr)' check and reutrns -t->hlen. ipgre_header() is being called, from neigh_connected_output(), with a non-null daddr; the contents of daddr is zero.
Reverting the ip_gre.c patch posted in http://marc.info/?l=linux-netdev&m=126762491525281&w=2 resolves the problem. (Reviewing the HEAD of net-next-2.6 it appears that ipgre_header() remains unchanged from 2.6.36.)
The configuration used to discover/diagnose the problem:
ip tunnel add tun1 mode gre key 11223344 ttl 64 csum remote any
ip link set dev tun1 up
ip link set dev tun1 multicast on
ip addr flush dev tun1
ip addr add 10.40.92.114/24 broadcast 10.40.92.255 dev tun1
12: tun1: <MULTICAST,NOARP,UP,10000> mtu 1468 qdisc noqueue
link/gre 0.0.0.0 brd 0.0.0.0
inet 10.40.92.114/24 brd 10.40.92.255 scope global tun1
Then attempt:
ping -I tun1 224.0.0.9
Are additional configuration steps now required for multicast over multipoint GRE tunnel or is ipgre_header() in error?
Thanks,
...doug
^ permalink raw reply
* Re: [PATCH v2 0/2] CS89x0: add QQ2440 networking support
From: David Miller @ 2011-03-14 23:49 UTC (permalink / raw)
To: cavokz; +Cc: akpm, linux-arm-kernel, netdev
In-Reply-To: <20110314134627.GA11935@dandreoli.com>
From: Domenico Andreoli <cavokz@gmail.com>
Date: Mon, 14 Mar 2011 13:46:27 +0000
> this patchset cleans some bit left from the CS89x0_NONISA_IRQ
> transition and then enables the support of CS89x0 on QQ2440.
Both patches applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Changli Gao @ 2011-03-14 23:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1103141955180.21929@obet.zrqbmnf.qr>
On Tue, Mar 15, 2011 at 3:00 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Monday 2011-03-14 13:42, Changli Gao wrote:
>
>>
>>Yes, you are correct only when there is no SNAT rule. If there is an
>>SNAT rule:
>>
>>-t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to-source 192.168.0.1
>>
>>the final tuples will be:
>>src = home dst = router src=1.2.3.4 dst=192.168.0.1
>>
>>However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
>>conn will be removed later as there isn't any conntrack, which has
>>this tuple in any direction.
>
> But I don't yet see how your patch #1 can help. At the time
> conn->tuple = *tuple is done, *tuple still contains the non-SNATed
> tuple, and it is never updated again.
>
In this patch, conn->addr is used to save the destination/source
address instead of conn->tuple.src.u3, so the conn->tuple is used for
conntrack lookup only. Just as the original tuple isn't updated, we
can use it to looking up the associated conntrack all the time.
addr: 192.168.0.1
tuple: src = home, dst = router
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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