* [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: Jeff Kirsher @ 2010-06-30 4:38 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
x86 architectures can handle unaligned accesses in hardware, and it has
been shown that unaligned DMA accesses can be expensive on Nehalem
architectures. As such we should overwrite NET_IP_ALIGN to resolve
this issue.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
arch/x86/include/asm/system.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index b8fe48e..b4293fc 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -457,4 +457,13 @@ static inline void rdtsc_barrier(void)
alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
}
+#ifdef CONFIG_MCORE2
+/*
+ * We handle most unaligned accesses in hardware. On the other hand
+ * unaligned DMA can be quite expensive on some Nehalem processors.
+ *
+ * Based on this we disable the IP header alignment in network drivers.
+ */
+#define NET_IP_ALIGN 0
+#endif
#endif /* _ASM_X86_SYSTEM_H */
^ permalink raw reply related
* Re: static inline int xfrm_mark_get() broken
From: Simon Horman @ 2010-06-30 4:46 UTC (permalink / raw)
To: Andreas Steffen; +Cc: netdev
In-Reply-To: <4C28EE19.2090502@hsr.ch>
On Mon, Jun 28, 2010 at 08:46:49PM +0200, Andreas Steffen wrote:
> Hi,
>
> experimenting with the new XFRM_MARK feature of the 2.6.34 kernel
> I found out that the extraction of the mark mask might accidentally
> work on 64 bit platforms but on 32 bit platforms the function is
> awfully broken. The rather trivial patch attached to this mail fixes
> the problem. Otherwise the XFRM_MARK feature seems quite promising!
>
> Best regards
>
> Andreas
>
> ======================================================================
> Andreas Steffen e-mail: andreas.steffen@hsr.ch
> Institute for Internet Technologies and Applications
> Hochschule fuer Technik Rapperswil phone: +41 55 222 42 68
> CH-8640 Rapperswil (Switzerland) mobile: +41 76 340 25 56
> ===========================================================[ITA-HSR]==
> --- linux/include/net/xfrm.h.ori 2010-06-28 18:53:28.229489876 +0200
> +++ linux/include/net/xfrm.h 2010-06-28 18:53:50.745487383 +0200
> @@ -1587,7 +1587,7 @@
> static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
> {
> if (attrs[XFRMA_MARK])
> - memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
> + memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
This fix looks correct to me, but
I believe that sizeof(*m) is the preferred style.
> else
> m->v = m->m = 0;
>
^ permalink raw reply
* Re: nonlocal_bind & IPv6
From: Simon Horman @ 2010-06-30 4:48 UTC (permalink / raw)
To: Michal Humpula; +Cc: netdev
In-Reply-To: <201006262242.16346.michal.humpula@hudrydum.cz>
On Sat, Jun 26, 2010 at 10:42:16PM +0200, Michal Humpula wrote:
> On Saturday 26 of June 2010 15:25:40 Simon Horman wrote:
> > On Fri, Jun 25, 2010 at 09:10:08PM +0200, Michal Humpula wrote:
> > > Ok, more detail example.
> > >
> > > Let on each node be an apache (just for an example), and you configure
> > > VirtualHost for specific IP. So when node A fails, keepalived move IP to
> > > the node B and everything is still running. No need for restart of apache
> > > or anything else. There is a probably a better solution, but I can't find
> > > anything more simple than the posted patch:)
> >
> > Not an answer to your original question, but that sounds like a problem
> > that can be resolved using IP_TRANSPARENT. Although I have only tested
> > that feature in conjunction with IPv4, it seems to support IPv6 too.
> >
> > See Documentation/networking/tproxy.txt
>
> Thanks for redirection. I don't think that IP_TRANSPARENT is suited well
> for my problem, but I did find the IP_FREEBIND in the process.
> Unfortunately it seems that both are enabled only for IPv4 and IPv6
> mapped addresses.
>
> So, is there any reason why IP_FREEBIND or nonlocal_bind sysctl is not in
> current IPv6 kernel implementation?
My suspicion is that its just an oversight. A good way to either get it
fixed or have the idea buried would be to send some patches.
^ permalink raw reply
* Re: [RFC] [PATCH] ethtool: Change ethtool_op_set_flags to validate flags
From: Jeff Garzik @ 2010-06-30 5:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: Stanislaw Gruszka, Amit Salecha, netdev@vger.kernel.org,
Amerigo Wang, Anirban Chakraborty
In-Reply-To: <1277827261.2112.48.camel@achroite.uk.solarflarecom.com>
On 06/29/2010 12:01 PM, Ben Hutchings wrote:
> This is the sort of change I'd like to see.
>
> Ben.
>
> ---
> ethtool_op_set_flags() does not check for unsupported flags, and has
> no way of doing so. This means it is not suitable for use as a
> default implementation of ethtool_ops::set_flags.
>
> Add a 'supported' parameter specifying the flags that the driver and
> hardware support, validate the requested flags against this, and
> change all current callers to pass this parameter.
>
> Change some other trivial implementations of ethtool_ops::set_flags to
> call ethtool_op_set_flags().
> ---
> drivers/net/cxgb4/cxgb4_main.c | 9 +--------
> drivers/net/enic/enic_main.c | 1 -
> drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
> drivers/net/mv643xx_eth.c | 7 ++++++-
> drivers/net/myri10ge/myri10ge.c | 10 +++++++---
> drivers/net/niu.c | 9 +--------
> drivers/net/sfc/ethtool.c | 5 +----
> drivers/net/sky2.c | 16 ++++++----------
> include/linux/ethtool.h | 2 +-
> net/core/ethtool.c | 28 +++++-----------------------
> 10 files changed, 32 insertions(+), 60 deletions(-)
Acked-by: Jeff Garzik <jgarzik@redhat.com>
I think that's a better way to do it...
^ permalink raw reply
* Re: [PATCH 0/4] Extend Time Stamping
From: Richard Cochran @ 2010-06-30 6:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100629.153134.25136559.davem@davemloft.net>
On Tue, Jun 29, 2010 at 03:31:34PM -0700, David Miller wrote:
> --------------------
> By this I mean you should provide these inline helpers by default
> then we can begin to put them into the drivers.
> --------------------
>
> This means no config option.
Okay, but what about the PHY time stamping hooks?
I anticipate that people will complain about the "performance penalty"
of these extra checks in a critical path.
Richard
static inline void phy_tx_timestamp(struct phy_device *phy, struct sk_buff *skb)
{
union skb_shared_tx *shtx = skb_tx(skb);
if (shtx->hardware && phy && phy->drv->txtstamp)
phy->drv->txtstamp(phy, skb);
}
static inline void phy_rx_timestamp(struct phy_device *phy, struct sk_buff *skb)
{
if (phy && phy->drv->rxtstamp)
phy->drv->rxtstamp(phy, skb);
}
^ permalink raw reply
* Re: [PATCH 0/4] Extend Time Stamping
From: David Miller @ 2010-06-30 5:37 UTC (permalink / raw)
To: richardcochran; +Cc: netdev
In-Reply-To: <20100630062806.GA3646@riccoc20.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Wed, 30 Jun 2010 08:28:06 +0200
> On Tue, Jun 29, 2010 at 03:31:34PM -0700, David Miller wrote:
>> --------------------
>> By this I mean you should provide these inline helpers by default
>> then we can begin to put them into the drivers.
>> --------------------
>>
>> This means no config option.
>
> Okay, but what about the PHY time stamping hooks?
>
> I anticipate that people will complain about the "performance penalty"
> of these extra checks in a critical path.
If you want to conditionalize the PHY hooks, fine.
But at a minimum, the software timestamping bits should be there by
default.
^ permalink raw reply
* Re: static inline int xfrm_mark_get() broken
From: Andreas Steffen @ 2010-06-30 5:03 UTC (permalink / raw)
To: Simon Horman
Cc: Steffen Andreas (asteffen@hsr.ch), netdev@vger.kernel.org, jamal
In-Reply-To: <20100630044637.GV2138@verge.net.au>
Hello Simon,
actually I don't care how this bug is going to be fixed, but with
sizeof(struct xfrm_mark) I'm dead certain that both the mark
value and mask are being copied. Actually in the next inline
function right below sizeof(struct xfrm_mark) is used, too:
static inline int xfrm_mark_put(struct sk_buff *skb, struct xfrm_mark *m)
{
if (m->m | m->v)
NLA_PUT(skb, XFRMA_MARK, sizeof(struct xfrm_mark), m);
return 0;
Regards
Andreas
On 06/30/2010 06:46 AM, Simon Horman wrote:
> On Mon, Jun 28, 2010 at 08:46:49PM +0200, Andreas Steffen wrote:
>> Hi,
>>
>> experimenting with the new XFRM_MARK feature of the 2.6.34 kernel
>> I found out that the extraction of the mark mask might accidentally
>> work on 64 bit platforms but on 32 bit platforms the function is
>> awfully broken. The rather trivial patch attached to this mail fixes
>> the problem. Otherwise the XFRM_MARK feature seems quite promising!
>>
>> Best regards
>>
>> Andreas
>>
>> ======================================================================
>> Andreas Steffen e-mail: andreas.steffen@hsr.ch
>> Institute for Internet Technologies and Applications
>> Hochschule fuer Technik Rapperswil phone: +41 55 222 42 68
>> CH-8640 Rapperswil (Switzerland) mobile: +41 76 340 25 56
>> ===========================================================[ITA-HSR]==
>
>> --- linux/include/net/xfrm.h.ori 2010-06-28 18:53:28.229489876 +0200
>> +++ linux/include/net/xfrm.h 2010-06-28 18:53:50.745487383 +0200
>> @@ -1587,7 +1587,7 @@
>> static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
>> {
>> if (attrs[XFRMA_MARK])
>> - memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
>> + memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
>
> This fix looks correct to me, but
> I believe that sizeof(*m) is the preferred style.
>
>> else
>> m->v = m->m = 0;
======================================================================
Andreas Steffen e-mail: andreas.steffen@hsr.ch
Institute for Internet Technologies and Applications
Hochschule fuer Technik Rapperswil phone: +41 55 222 42 68
CH-8640 Rapperswil (Switzerland) mobile: +41 76 340 25 56
===========================================================[ITA-HSR]==
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/4] e1000e: don't inadvertently re-set INTX_DISABLE
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, dnelson, stable
In-Reply-To: <20100630040959.8652.31147.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:05 -0700
> From: Dean Nelson <dnelson@redhat.com>
>
> Should e1000_test_msi() fail to see an msi interrupt, it attempts to
> fallback to legacy INTx interrupts. But an error in the code may prevent
> this from happening correctly.
...
> The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
> part of its attempt to re-enable SERR.
>
> During debugging/testing of this issue I found that not all the systems
> I ran on had the SERR bit set to begin with. And on some of the systems
> the same could be said for the INTX_DISABLE bit. Needless to say these
> latter systems didn't have a problem falling back to legacy INTx
> interrupts with the code as is.
>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
> CC: stable@kernel.org
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/4] e1000e: suppress compile warnings on certain archs
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100630041228.8652.61761.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:30 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Commit 84f4ee902ad3ee964b7b3a13d5b7cf9c086e9916 causes compile warnings on
> architectures that have unsigned long long's that are not 64-bit, e.g.
> ia64.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] e1000e: remove EEE module parameter
From: David Miller @ 2010-06-30 6:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100630041249.8652.67388.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:12:52 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> As requested by Dave Miller. A follow-on set of patches will allow for
> ethtool to enable/disable the feature instead.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 4/4] e1000e: disable EEE support by default
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bhutchings, bruce.w.allan
In-Reply-To: <20100630041311.8652.42432.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:13:13 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Based on community feedback, EEE should be disabled by default until the
> IEEE802.3az specification has been finalized.
>
> Cc: bhutchings@solarflare.com
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: fix panic when shutting down system with WoL enabled
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, andy, jesse.brandeburg
In-Reply-To: <20100630042739.8925.24962.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:28:12 -0700
> From: Andy Gospodarek <andy@greyhouse.net>
>
> This patch added to 2.6.34:
>
> commit 5f6c01819979afbfec7e0b15fe52371b8eed87e8
> Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Date: Wed Apr 14 16:04:23 2010 -0700
>
> ixgbe: fix bug with vlan strip in promsic mode
>
> among other things added a function called ixgbe_vlan_filter_enable.
> This new function wants to access and set some rx_ring parameters, but
> adapter->rx_ring has already been freed. This simply moves the free
> until after the access and makes __ixgbe_shutdown look more like
> ixgbe_remove.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: disable tx engine before disabling tx laser
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, john.r.fastabend, peter.p.waskiewicz.jr
In-Reply-To: <20100630042836.8925.82492.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:28:36 -0700
> From: John Fastabend <john.r.fastabend@intel.com>
>
> Disabling the tx laser while receiving DMA requests
> can hang the device. After this occurs the device
> is in a bad state. The GPIO bit never clears when
> PCI master access is disabled and a reboot is required
> to get the device in a good state again.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: skip non IPv4 packets in ATR filter
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, guillaume.gaudonville,
peter.p.waskiewicz.jr, donald.c.skidmore
In-Reply-To: <20100630042859.8925.23844.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:29:00 -0700
> From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>
> In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
> add a test to check skb->protocol. It may crash on short packets due
> to ip_hdr() access.
>
> Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net-next-2.6] 3c59x: Use fine-grained locks for MII and windowed register access
From: David Miller @ 2010-06-30 6:15 UTC (permalink / raw)
To: ben; +Cc: steffen.klassert, netdev, chase.douglas, nordmark
In-Reply-To: <1277861216.28819.36.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 30 Jun 2010 02:26:56 +0100
> This avoids scheduling in atomic context and also means that IRQs
> will only be deferred for relatively short periods of time.
>
> Previously discussed in:
> http://article.gmane.org/gmane.linux.network/155024
>
> Reported-by: Arne Nordmark <nordmark@mech.kth.se>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: RFC: Allow 'ip' to run in daemon mode?
From: Stephen Hemminger @ 2010-06-30 7:00 UTC (permalink / raw)
To: Ben Greear, NetDev; +Cc: Stephen Hemminger
write a new service rather than bloating the existing code or just use netlink or libnl
Ben Greear <greearb@candelatech.com> wrote:
>I'm considering modifying 'ip' to be able to run in daemon
>mode so that I can do lots of IP commands without having to
>pay the startup cost of iproute.
>
>The -batch option almost works, but it's hard to programatically
>figure out failure codes.
>
>I'm thinking about making these changes:
>
>1) Move all of the error printing code into common methods (basically,
> wrap printf). In daemon mode this text can be sent back to the
> calling process, and in normal mode, it will be printed to stdout/stderr
> as it is currently.
>
>2) Remove all or most calls to 'exit' and instead return error codes
> to the calling logic.
>
>3) Add ability to listen on a unix socket for commands, basically treat
> them just like batch commands, one command per packet.
>
>4) Return well formatted error code and text response to calling process
> over the unix socket, maybe something like:
>
>RV: [errno or equiv, zero for success]\n
>CMD: [ command string this relates to ]\n
>[ Optional free form text ]
>
>
>Does something like this have any chance of upstream inclusion?
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: static inline int xfrm_mark_get() broken
From: Simon Horman @ 2010-06-30 7:01 UTC (permalink / raw)
To: Andreas Steffen
Cc: Steffen Andreas (asteffen@hsr.ch), netdev@vger.kernel.org, jamal
In-Reply-To: <4C2AD009.40306@hsr.ch>
On Wed, Jun 30, 2010 at 07:03:05AM +0200, Andreas Steffen wrote:
> Hello Simon,
>
> actually I don't care how this bug is going to be fixed, but with
> sizeof(struct xfrm_mark) I'm dead certain that both the mark
> value and mask are being copied. Actually in the next inline
> function right below sizeof(struct xfrm_mark) is used, too:
>
> static inline int xfrm_mark_put(struct sk_buff *skb, struct xfrm_mark *m)
> {
> if (m->m | m->v)
> NLA_PUT(skb, XFRMA_MARK, sizeof(struct xfrm_mark), m);
> return 0;
In that case I withdraw my suggestion.
^ permalink raw reply
* ip6 route output() and ip_route_output_key() by drivers
From: Parav Pandit @ 2010-06-30 7:24 UTC (permalink / raw)
To: netdev
Hi,
Our device driver uses ip6 route output() and typecast the return value of dst_entry to rt6_info (similar to (net/ip6/icmp.c)
Driver uses (a) rt6i_dst.addr, (b) rt6i_dst.plen and (c) rt6i_gateway to get the route entry (ip/mask, gw, netdev).
Can anyone please confirm that drivers and/or netfilter kernel modules are allowed to use them? netdev drivers like : cnic.c, cxgb3, nes are using the ipv4 API (but not IPv6 API).
Also ip_route_output_key() rtable and dst_entry doesn't seem to provide route entry's subnet mask/prefix value. how drivers/netfilter kernel module can get a ip/mask gateway value while given a destination IP address as input?
I really appreciate your inputs. I hope I am asking it on the relevant mailing list.
Regards,
Parav Pandit
^ permalink raw reply
* Re: [Bridge] Bridge blocking network traffic
From: ratheesh k @ 2010-06-30 7:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netfilter mailing list, netdev, bridge
In-Reply-To: <20100422130919.70206765@nehalam>
>>On Fri, Apr 23, 2010 at 1:39 AM, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>>You are supposed to assign IP address to bridge not the member of the bridge
Why is it so ?
I have a linux machine with interfaces eth0 (192.168.1.100 ) and
eth1 ( 192.168.2.100 ) . . I can connect both eth0 an eth1 to a
hardware HUB . How could i do this in linux machine itself using
brctl ?
Thanks,
Ratheesh
> On Thu, 22 Apr 2010 10:48:09 +1000
> benno joy <bennojoy@gmail.com> wrote:
>
>> Dear Team,
>>
>> I have a strange problem...... This is my problem i have a linux box running
>> Xen kernel (2.2). and i have the a bonding interface called bond0.497(eth0
>> and eth1 and also des Vlan tagging).
>> the bond0.497 is part of the bridge "xenbrv497", the issue is as soon as i
>> make the bond a part of the bridge my network traffic stops to work.
>> I did some prelimanary tests and found the following:
>> 1) if i assighn an ip to the bond and do a ping to the gateway it works
>> (provided it is not part of bridge xenbrv497)
>> 2) if i add the bondig interface to the brodge xenbrv497 (brclt addif
>> xenbrv497 bond0.497) the ping tests fails.
>> 3) i did a tcpdump and found that arp requests are going out of the
>> interface and we are getting response also. but soemhow
>> the arp entries are not gettign registered. i did some googling and found it
>> may be because of filtering so i disabled it by
>> echo 0 > in /proc/sys/net/bridge/bridge-nf-*.
>> But even this did not help still the arp entries are not getting registered
>> due to which my network traffic is gettign dropped.
>> This problem can be resolved by a reboot. but i would like to troubleshoot
>> it.
>> Could you please let me know how i can get more debugging message from the
>> bridge calls so i can figure out what exactly is happening.
>>
>> # uname -a
>> Linux vmclkxstgh04.espdev.aurdev.national.com.au 2.6.18-128.2.1.4.13.el5xen
>> #1 SMP Mon Dec 7 14:34:40 EST 2009 i686 i686 i386 GNU/Linux
>>
>> [root@vmclkxstgh04 ~]# brctl show
>> bridge name bridge id STP enabled interfaces
>> vlan441 8000.0017a4770470 no bond0.441
>> xenbrv205 8000.0017a477046c no bond1.205
>> xenbrv208 8000.0017a477046c no bond1.208
>> xenbrv220 8000.000000000000 no
>> xenbrv221 8000.000000000000 no
>> xenbrv226 8000.0017a477046c no vif40.1
>> vif39.1
>> vif37.1
>> vif26.1
>> vif25.1
>> vif24.1
>> vif13.1
>> bond1.226
>> xenbrv227 8000.0017a4770470 no vif40.0
>> vif39.0
>> vif37.0
>> vif26.0
>> vif25.0
>> vif24.0
>> vif13.0
>> bond0.227
>> xenbrv420 8000.0017a4770470 no bond0.420
>> xenbrv422 8000.0017a4770470 no vif35.0
>> vif7.0
>> vif6.0
>> vif4.0
>> vif3.0
>> vif2.0
>> tap2.0
>> bond0.422
>> xenbrv425 8000.0017a4770470 no bond0.425
>> xenbrv450 8000.0017a4770470 no bond0.450
>> xenbrv492 8000.0017a4770470 no bond0.492
>> xenbrv493 8000.0017a4770470 no bond0.493
>> xenbrv494 8000.0017a4770470 no bond0.494
>> xenbrv495 8000.0017a4770470 no bond0.495
>> xenbrv496 8000.0017a4770470 no bond0.496
>> xenbrv497 8000.0017a4770470 no bond0.497
>> xenbrv701 8000.0017a477046c no vif44.1
>> bond1.701
>>
>> bond0.497 Link encap:Ethernet HWaddr 00:17:A4:77:04:70
>> inet addr:10.12.166.231 Bcast:10.12.166.255 Mask:255.255.255.224
>> UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
>> RX packets:3807595 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:3304 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:188847200 (180.0 MiB) TX bytes:138768 (135.5 KiB)
>
> You are supposed to assign IP address to bridge not the member of the bridge.
>
>
> --
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply
* [PATCH] igbvf: avoid name clash between PF and VF
From: Stefan Assmann @ 2010-06-30 8:53 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, Andy Gospodarek, jeffrey.t.kirsher, gregory.v.rose
From: Stefan Assmann <sassmann@redhat.com>
It looks like the VFs get initialized before all the PFs are. Therefore
the udev mapping MAC <-> ethX (for PFs) gets screwed because the VFs
may grab the ethX interface names (reserved by udev) for the PFs.
Example:
igb max_vfs=0
eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
eth1 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
eth2 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
eth3 Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
igb max_vfs=1
eth0 Link encap:Ethernet HWaddr 00:13:20:F7:A5:9E
eth1 Link encap:Ethernet HWaddr 0A:CF:41:69:F7:A9
eth2 Link encap:Ethernet HWaddr 3A:FE:20:4C:2A:3B
eth3 Link encap:Ethernet HWaddr C6:C3:B1:56:C9:A4
eth3_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:9F
eth4 Link encap:Ethernet HWaddr 6E:8A:8A:A3:5F:69
eth4_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A0
eth5_rename Link encap:Ethernet HWaddr 00:13:20:F7:A5:A1
In the example above VF 0A:CF:41:69:F7:A9 grabs eth1 but udev
has a rule that says eth1 should be assigned PF 00:13:20:F7:A5:9F
(eth3_rename) and waits for the VF to disappear to rename eth3_rename
to eth1. Unfortunately eth1 is not going to disappear.
This is not a udev bug since udev doesn't create persistent rules for
VFs as their MAC address changes every reboot.
To avoid this problem we could change the kernel name for the VFs and
thus avoid confusion between VFs and PFs.
I've already discussed this with Alexander Duyck and Greg Rose, so far
they have no objection. However this problem appears for all drivers that
support PFs and VFs and thus the changes should be applied consistently
to all of these drivers.
Signed-off-by: Stefan Assmann <sassmann@redhat.com>
---
drivers/net/igbvf/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igbvf/netdev.c b/drivers/net/igbvf/netdev.c
index 5e2b2a8..2fb665b 100644
--- a/drivers/net/igbvf/netdev.c
+++ b/drivers/net/igbvf/netdev.c
@@ -2787,7 +2787,7 @@ static int __devinit igbvf_probe(struct pci_dev *pdev,
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- strcpy(netdev->name, "eth%d");
+ strcpy(netdev->name, "veth%d");
err = register_netdev(netdev);
if (err)
goto err_hw_init;
--
1.6.5.2
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* [PATCH] act_mirred: combine duplicate code
From: Changli Gao @ 2010-06-30 8:54 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, linux-kernel, Changli Gao
act_mirred: combine duplicate code
tcf_bstats is updated in any way, so we can do it earlier to reduce the size of
the code.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_mirred.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 2e9a7b9..a16b017 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -160,6 +160,8 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
spin_lock(&m->tcf_lock);
m->tcf_tm.lastuse = jiffies;
+ m->tcf_bstats.bytes += qdisc_pkt_len(skb);
+ m->tcf_bstats.packets++;
dev = m->tcfm_dev;
if (!(dev->flags & IFF_UP)) {
@@ -174,8 +176,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
if (skb2 == NULL)
goto out;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
- m->tcf_bstats.packets++;
if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
@@ -193,8 +193,6 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
out:
if (err) {
m->tcf_qstats.overlimits++;
- m->tcf_bstats.bytes += qdisc_pkt_len(skb);
- m->tcf_bstats.packets++;
/* should we be asking for packet to be dropped?
* may make sense for redirect case only
*/
^ permalink raw reply related
* [PATCH v2] net/core: use ntohs for skb->protocol
From: Sebastian Andrzej Siewior @ 2010-06-30 9:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100629.151740.135534374.davem@davemloft.net>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This is only noticed by people that are not doing everything correct in
the first place.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
net/core/dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index eb4be99..8e61dc5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1537,7 +1537,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
if (net_ratelimit())
printk(KERN_CRIT "protocol %04x is "
"buggy, dev %s\n",
- skb2->protocol, dev->name);
+ ntohs(skb2->protocol),
+ dev->name);
skb_reset_network_header(skb2);
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH] act_nat: use stack variable
From: Changli Gao @ 2010-06-30 9:07 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: Herbert Xu, David S. Miller, netdev, Changli Gao
act_nat: use stack variable
structure tc_nat isn't too big for stack, so we can put it in stack.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_nat.c | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
index 5709494..0be49a4 100644
--- a/net/sched/act_nat.c
+++ b/net/sched/act_nat.c
@@ -265,40 +265,29 @@ static int tcf_nat_dump(struct sk_buff *skb, struct tc_action *a,
{
unsigned char *b = skb_tail_pointer(skb);
struct tcf_nat *p = a->priv;
- struct tc_nat *opt;
+ struct tc_nat opt;
struct tcf_t t;
- int s;
- s = sizeof(*opt);
+ opt.old_addr = p->old_addr;
+ opt.new_addr = p->new_addr;
+ opt.mask = p->mask;
+ opt.flags = p->flags;
- /* netlink spinlocks held above us - must use ATOMIC */
- opt = kzalloc(s, GFP_ATOMIC);
- if (unlikely(!opt))
- return -ENOBUFS;
+ opt.index = p->tcf_index;
+ opt.action = p->tcf_action;
+ opt.refcnt = p->tcf_refcnt - ref;
+ opt.bindcnt = p->tcf_bindcnt - bind;
- opt->old_addr = p->old_addr;
- opt->new_addr = p->new_addr;
- opt->mask = p->mask;
- opt->flags = p->flags;
-
- opt->index = p->tcf_index;
- opt->action = p->tcf_action;
- opt->refcnt = p->tcf_refcnt - ref;
- opt->bindcnt = p->tcf_bindcnt - bind;
-
- NLA_PUT(skb, TCA_NAT_PARMS, s, opt);
+ NLA_PUT(skb, TCA_NAT_PARMS, sizeof(opt), &opt);
t.install = jiffies_to_clock_t(jiffies - p->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - p->tcf_tm.lastuse);
t.expires = jiffies_to_clock_t(p->tcf_tm.expires);
NLA_PUT(skb, TCA_NAT_TM, sizeof(t), &t);
- kfree(opt);
-
return skb->len;
nla_put_failure:
nlmsg_trim(skb, b);
- kfree(opt);
return -1;
}
^ permalink raw reply related
* [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: Andreas Steffen @ 2010-06-30 7:57 UTC (permalink / raw)
To: netdev; +Cc: jamal, David Miller
Determine the size of the xfrm_mark struct, not of its pointer.
Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
---
include/net/xfrm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 1913af6..fc8f36d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1586,7 +1586,7 @@ static inline struct xfrm_state *xfrm_input_state(struct sk_buff *skb)
static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
{
if (attrs[XFRMA_MARK])
- memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
+ memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(struct xfrm_mark));
else
m->v = m->m = 0;
--
1.7.0.4
^ permalink raw reply related
* Re: nat bypass
From: ratheesh k @ 2010-06-30 9:24 UTC (permalink / raw)
To: Simon Horman; +Cc: Netfilter mailing list, netdev
In-Reply-To: <20100630023718.GU2138@verge.net.au>
> Let me try and understand this.
>
> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
> As A is on the 192.168.1.0/24 side of R.
> But to give A an 10.232.18.0/24 address (dynamically)?
>
> Why?
>
For some clients , R should act as a mere bridge , Not a router .
On Wed, Jun 30, 2010 at 8:07 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Jun 28, 2010 at 03:43:46PM +0530, ratheesh k wrote:
>> Hi,
>>
>> A -------> R ------->S
>>
>> I have a linux machine A is connected to Linux machine R . Machine R
>> is having two network interfaces and acting as a router .
>> It has a dhcp server running . It will assign ip in 192.168.1.0/24
>> subnet to all machine connected on lan side ( A is connected also in
>> lan side ) . Wan side of R is connected to HTTP server S . There is
>> also a DHCP server running on S to assign ip in 10.232.18.0/24 subnet
>> . Is there any way , in which NAT should be bypassed to get ip from
>> DHCP server running on S . My question is : How can A will get an ip
>> from 10.232.18.0/24 pool ip .?
>> ebtables is an option ? How can we make it ?
>> Is there any other optimal way ?
>
> Let me try and understand this.
>
> R is routing between 192.168.1.0/24 and 10.232.18.0/24.
> As A is on the 192.168.1.0/24 side of R.
> But to give A an 10.232.18.0/24 address (dynamically)?
>
> Why?
>
>
^ 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