* Re: [Patch V2] bonding: fix netpoll in active-backup mode
From: Neil Horman @ 2011-03-08 21:41 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Amerigo Wang, linux-kernel, Jay Vosburgh, netdev
In-Reply-To: <20110308212405.GX11864@gospo.rdu.redhat.com>
On Tue, Mar 08, 2011 at 04:24:05PM -0500, Andy Gospodarek wrote:
> On Tue, Mar 08, 2011 at 05:58:56PM +0800, Amerigo Wang wrote:
> > V2: avoid calling slave_diable_netpoll() with write_lock_bh() held.
> >
> > netconsole doesn't work in active-backup mode, because we don't do anything
> > for nic failover in active-backup mode. We should disable netpoll on the
> > failing slave when it is detected down and enable netpoll when it becomes
> > the active slave.
> >
> > Tested by ifdown the current active slave and ifup it again for several times,
> > netconsole works well.
> >
> > Signed-off-by: WANG Cong <amwang@redhat.com>
> > Cc: Neil Horman <nhorman@tuxdriver.com>
> >
>
> It seems like you are going to a lot of trouble to fix a bug where
> netpoll will not be setup on any interface that is down when enslaved.
> That seems to be the only path that would not have slave->np setup
> properly at enslavement.
>
> Did you ever try just this?
>
+1, this is what I was suggesting. Just setup netpoll on all the slaves
regardless of status, and let their netpoll state follow that of the bond.
Neil
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 0592e6d..8d93044 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1352,8 +1352,6 @@ static int bond_netpoll_setup(struct net_device *dev, struct netpoll_info *ni)
>
> read_lock(&bond->lock);
> bond_for_each_slave(bond, slave, i) {
> - if (!IS_UP(slave->dev))
> - continue;
> err = slave_enable_netpoll(slave);
> if (err) {
> __bond_netpoll_cleanup(bond);
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [patch net-next-2.6] net: reinject arps into bonding slave instead of master
From: Nicolas de Pesloüan @ 2011-03-08 21:44 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet
In-Reply-To: <20110308134247.GW11864@gospo.rdu.redhat.com>
Le 08/03/2011 14:42, Andy Gospodarek a écrit :
> I'm pretty sure this patch will have the same catastrophic problem your
> last one did. By cloning and setting skb2->dev = orig_dev you just
> inserted a frame identical to the one we received right back into the
> stack. It only took a few minutes for my box to melt as one frame on
> the wire will cause an infinite number of frames to be received by the
> stack.
I agree with Andy. We still keep one reinject (netif_rx), which is probably better that two
(__netif_receive_skb), but not enough.
I really think we need a general framework for late delivery of final packets to packet handler
registered somewhere in the rx_handler path.
Jiri, is this patch the one you announced as "I have some kind nice solution in mind and I'm going
to submit that as a patch later (too many patches are in the wind atm)" ?
^ permalink raw reply
* Re: [PATCH] cnic: fix double initalization of bnx2 based cards
From: Michael Chan @ 2011-03-08 21:41 UTC (permalink / raw)
To: Neil Horman
Cc: Ben Hutchings, netdev@vger.kernel.org, David S. Miller,
Dmitry Kravkov, Eddie Wai, Eilon Greenstein
In-Reply-To: <20110308214028.GD19669@hmsreliant.think-freely.org>
On Tue, 2011-03-08 at 13:40 -0800, Neil Horman wrote:
> > No, that should not happen. When we compare NULL-terminated "bnx2" with
> > NULL-terminated "bnx2x", it won't match because the '\0' won't match the
> > 'x', right?
> >
> > I think the patch is good. We can avoid the unnecessary strcmp() when
> > we have a match with "bnx2" already. But we should not get both matches
> > even without the patch.
> >
> Crap, sorry, I rescind this (although you're right, it probably wouldn't hurt to
> roll this change in, just to save a potential second strcmp). Anywho, I'm
> getting this error on the ifup of my bnx2 interface:
> bnx2i: iSCSI not supported, dev=eth1
>
> That message appears to only get set (from my read) on cards driven by the bnx2x
> driver, and when I saw the 2 ifs rather than the if/else, I jumped to a
> conclusion that we must be using the bnx2x init path on a bnx2 driver.
> Apologies.
>
> /me wanders off to see where completion_status gets set to
> ISCSI_KCQE_COMPLETION_STATUS_ISCSI_NOT_SUPPORTED for bnx2.
On bnx2, this error code is set by the firmware if iSCSI is not
configured in NVRAM.
Thanks.
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-03-08 21:57 UTC (permalink / raw)
To: Rusty Russell
Cc: Michael S. Tsirkin, Krishna Kumar2, David Miller, kvm, netdev,
steved
In-Reply-To: <201102091107.20270.rusty@rustcorp.com.au>
On Wed, 2011-02-09 at 11:07 +1030, Rusty Russell wrote:
> I've finally read this thread... I think we need to get more serious
> with our stats gathering to diagnose these kind of performance issues.
>
> This is a start; it should tell us what is actually happening to the
> virtio ring(s) without significant performance impact...
Should we also add similar stat on vhost vq as well for monitoring
vhost_signal & vhost_notify?
Shirley
^ permalink raw reply
* kbench_mod
From: David Miller @ 2011-03-08 22:10 UTC (permalink / raw)
To: netdev
I just added a special kernel module to the net_test_tools tree,
it allows more accurate measurement of routing lookups.
It does cycle counts across one routing lookup.
The flow key is controlled by module parameters, iif != 0 means
input route lookup, otherwise we do an output lookup.
What's cool is you can jack-up the warmup_count value and then
run insmod under "perf record" and it just works.
^ permalink raw reply
* Re: [PATCH 1/2 net-2.6] r6040: fix multicast operations
From: David Miller @ 2011-03-08 22:22 UTC (permalink / raw)
To: florian; +Cc: netdev
In-Reply-To: <201103071109.40853.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 7 Mar 2011 11:09:40 +0100
> From: Shawn Lin <shawn@dmp.com.tw>
>
> The original code does not work well when the number of mulitcast
> address to handle is greater than MCAST_MAX. It only enable promiscous
> mode instead of multicast hash table mode, so the hash table function
> will not be activated and all multicast frames will be recieved in this
> condition.
>
> This patch fixes the following issues with the r6040 NIC operating in
> multicast:
>
> 1) When the IFF_ALLMULTI flag is set, we should write 0xffff to the NIC
> hash table registers to make it process multicast traffic.
>
> 2) When the number of multicast address to handle is smaller than
> MCAST_MAX, we should use the NIC multicast registers MID1_{L,M,H}.
>
> 3) The hashing of the address was not correct, due to an invalid
> substraction (15 - (crc & 0x0f)) instead of (crc & 0x0f) and an
> incorrect crc algorithm (ether_crc_le) instead of (ether_crc).
>
> 4) If necessary, we should set HASH_EN flag in MCR0 to enable multicast
> hash table function.
>
> Reported-by: Marc Leclerc <marc-leclerc@signaturealpha.com>
> Tested-by: Marc Leclerc <marc-leclerc@signaturealpha.com>
> Signed-off-by: Shawn Lin <shawn@dmp.com.tw>
> Signed-off-by: Albert Chen <albert.chen@rdc.com.tw>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2 net-2.6] r6040: bump to version 0.27 and date 23Feb2011
From: David Miller @ 2011-03-08 22:22 UTC (permalink / raw)
To: florian; +Cc: netdev
In-Reply-To: <201103071109.42377.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 7 Mar 2011 11:09:42 +0100
> From: Florian Fainelli <florian@openwrt.org>
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Applied.
^ permalink raw reply
* [PATCH net-next-2.6] ixgbe: fix compile failure in ixgbe_init_mbx_params_pf
From: Andy Gospodarek @ 2011-03-08 22:24 UTC (permalink / raw)
To: netdev, davem, Emil Tantilov, Jeff Kirsher
This commit:
commit d7c8a29fc8bd20ba45ec2f52577ed04a988a9500
Author: Emil Tantilov <emil.s.tantilov@intel.com>
Date: Thu Mar 3 09:25:02 2011 +0000
ixgbe: improve logic in ixgbe_init_mbx_params_pf
incorrectly added a line that accessed mbx->udelay. I'm sure the intent
was mbx->usec_delay. This patch fixes the compilation error.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
drivers/net/ixgbe/ixgbe_mbx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_mbx.c b/drivers/net/ixgbe/ixgbe_mbx.c
index 3cf8aec..c7ed82e 100644
--- a/drivers/net/ixgbe/ixgbe_mbx.c
+++ b/drivers/net/ixgbe/ixgbe_mbx.c
@@ -453,7 +453,7 @@ void ixgbe_init_mbx_params_pf(struct ixgbe_hw *hw)
return;
mbx->timeout = 0;
- mbx->udelay = 0;
+ mbx->usec_delay = 0;
mbx->stats.msgs_tx = 0;
mbx->stats.msgs_rx = 0;
^ permalink raw reply related
* Re: [PATCH] dsa/mv88e6060: support nonzero mii base address
From: David Miller @ 2011-03-08 22:24 UTC (permalink / raw)
To: buytenh; +Cc: jacmet, netdev
In-Reply-To: <20110307182413.GZ16649@mail.wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Mon, 7 Mar 2011 19:24:13 +0100
> On Mon, Mar 07, 2011 at 04:49:47PM +0100, Peter Korsgaard wrote:
>
>> The mv88e6060 uses either the lower 16 or upper 16 mii addresses,
>> depending on the value of the EE_CLK/ADDR4 pin. Support both
>> configurations by using the sw_addr setting as base address.
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> Looks good!
>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ixgbe: fix compile failure in ixgbe_init_mbx_params_pf
From: David Miller @ 2011-03-08 22:26 UTC (permalink / raw)
To: andy; +Cc: netdev, davem, emil.s.tantilov, jeffrey.t.kirsher
In-Reply-To: <1299623047-25656-1-git-send-email-andy@greyhouse.net>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Tue, 8 Mar 2011 17:24:07 -0500
> This commit:
>
> commit d7c8a29fc8bd20ba45ec2f52577ed04a988a9500
> Author: Emil Tantilov <emil.s.tantilov@intel.com>
> Date: Thu Mar 3 09:25:02 2011 +0000
>
> ixgbe: improve logic in ixgbe_init_mbx_params_pf
>
> incorrectly added a line that accessed mbx->udelay. I'm sure the intent
> was mbx->usec_delay. This patch fixes the compilation error.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Applied, thanks Andy.
^ permalink raw reply
* Re: [PATCH 11/17] mlx4_en: Enabling new steering
From: David Miller @ 2011-03-08 22:26 UTC (permalink / raw)
To: roland; +Cc: or.gerlitz, yevgenyp, netdev, vlad, nirmu, alekseys
In-Reply-To: <AANLkTim8XDT5YKJc4wroyEDJc1X+xZOFL9y_090F5eLr@mail.gmail.com>
From: Roland Dreier <roland@kernel.org>
Date: Tue, 8 Mar 2011 13:30:25 -0800
> On Tue, Mar 8, 2011 at 1:10 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
>>> + if (mdev->dev->caps.vep_mc_steering && ibqp->qp_type == IB_QPT_RAW_ETHERTYPE) {
>>
>> Guys,
>>
>> Didn't you want to refer here to the "raw ethernet QP" which is typed
>> to IB_QPT_RAW_PACKET by the series posted on December last year, see
>> http://marc.info/?l=linux-rdma&m=129162076818154 --
>> IB_QPT_RAW_ETHERTYPE is a rename of IB's IB_QPT_RAW_ETY done by
>> commit a2ebf07ae53e65bd073f96877e4818f2e89271ae
>
> Good catch. I think the drivers/infiniband part of this patch should
> just be dropped -- we don't have any raw QP support of any kind, right?
Once this is all sorted out, please someone respin this entire patch
set.
Thanks.
^ permalink raw reply
* Re: [PATCH] vxge: update MAINTAINERS
From: David Miller @ 2011-03-08 22:28 UTC (permalink / raw)
To: jdmason; +Cc: netdev
In-Reply-To: <1299517321-4567-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Mon, 7 Mar 2011 11:02:01 -0600
> Exar has exited the 10G Ethernet NIC market, orphaning both the s2io and
> vxge drivers. With the promise of free hardware, I'll take over
> maintainership.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Applied, thanks.
^ permalink raw reply
* [PATCH] inetpeer: Don't disable BH for initial fast RCU lookup.
From: David Miller @ 2011-03-08 22:59 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet
If modifications on other cpus are ok, then modifications to
the tree during lookup done by the local cpu are ok too.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/inetpeer.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index f604ffd..6442c35 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -206,16 +206,16 @@ static int addr_compare(const struct inetpeer_addr *a,
})
/*
- * Called with rcu_read_lock_bh()
+ * Called with rcu_read_lock()
* Because we hold no lock against a writer, its quite possible we fall
* in an endless loop.
* But every pointer we follow is guaranteed to be valid thanks to RCU.
* We exit from this function if number of links exceeds PEER_MAXDEPTH
*/
-static struct inet_peer *lookup_rcu_bh(const struct inetpeer_addr *daddr,
- struct inet_peer_base *base)
+static struct inet_peer *lookup_rcu(const struct inetpeer_addr *daddr,
+ struct inet_peer_base *base)
{
- struct inet_peer *u = rcu_dereference_bh(base->root);
+ struct inet_peer *u = rcu_dereference(base->root);
int count = 0;
while (u != peer_avl_empty) {
@@ -231,9 +231,9 @@ static struct inet_peer *lookup_rcu_bh(const struct inetpeer_addr *daddr,
return u;
}
if (cmp == -1)
- u = rcu_dereference_bh(u->avl_left);
+ u = rcu_dereference(u->avl_left);
else
- u = rcu_dereference_bh(u->avl_right);
+ u = rcu_dereference(u->avl_right);
if (unlikely(++count == PEER_MAXDEPTH))
break;
}
@@ -470,11 +470,11 @@ struct inet_peer *inet_getpeer(struct inetpeer_addr *daddr, int create)
/* Look up for the address quickly, lockless.
* Because of a concurrent writer, we might not find an existing entry.
*/
- rcu_read_lock_bh();
+ rcu_read_lock();
sequence = read_seqbegin(&base->lock);
- p = lookup_rcu_bh(daddr, base);
+ p = lookup_rcu(daddr, base);
invalidated = read_seqretry(&base->lock, sequence);
- rcu_read_unlock_bh();
+ rcu_read_unlock();
if (p) {
/* The existing node has been found.
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Stephen Hemminger @ 2011-03-08 23:21 UTC (permalink / raw)
To: David Miller; +Cc: rhee, lucas.nussbaum, xiyou.wangcong, netdev
In-Reply-To: <20110308.114346.48506864.davem@davemloft.net>
On Tue, 08 Mar 2011 11:43:46 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Injong Rhee <rhee@ncsu.edu>
> Date: Tue, 08 Mar 2011 10:26:36 -0500
>
> > Thanks for updating CUBIC hystart. You might want to test the
> > cases with more background traffic and verify whether this
> > threshold is too conservative.
>
> So let's get down to basics.
>
> What does Hystart do specially that allows it to avoid all of the
> problems that TCP VEGAS runs into.
>
> Specifically, that if you use RTTs to make congestion control
> decisions it is impossible to notice new bandwidth becomming available
> fast enough.
>
> Again, it's impossible to react fast enough. No matter what you tweak
> all of your various settings to, this problem will still exist.
>
> This is a core issue, you cannot get around it.
>
> This is why I feel that Hystart is fundamentally flawed and we should
> turn it off by default if not flat-out remove it.
>
> Distributions are turning it off by default already, therefore it's
> stupid for the upstream kernel to behave differently if that's what
> %99 of the world is going to end up experiencing.
The assumption in Hystart that spacing between ACK's is solely due to
congestion is a bad. If you read the paper, this is why FreeBSD's
estimation logic is dismissed. The Hystart problem is different
than the Vegas issue.
Algorithms that look at min RTT are ok, since the lower bound is
fixed; additional queuing and variation in network only increases RTT
it never reduces it. With a min RTT it is possible to compute the
upper bound on available bandwidth. i.e If all packets were as good as
this estimate minRTT then the available bandwidth is X. But then using
an individual RTT sample to estimate unused bandwidth is flawed. To
quote paper.
"Thus, by checking whether ∆(N ) is larger than Dmin , we
can detect whether cwnd has reached the available capacity
of the path"
So what goes wrong:
1. Dmin can be too large because this connection always sees delays
due to other traffic or hardware. i.e buffer bloat. This would cause
the bandwidth estimate to be too low and therefore TCP would leave
slow start too early (and not get up to full bandwidth).
2. Dmin can be smaller than the clock resolution. This would cause
either sample to be ignored, or Dmin to be zero. If Dmin is zero,
the bandwidth estimate would in theory be infinite, which would
lead to TCP not leaving slow start because of Hystart. Instead
TCP would leave slow start at first loss.
Other possible problems:
3. ACK's could be nudged together by variations in delay.
This would cause HyStart to exit slow start prematurely. To false
think it is an ACK train.
Noise in network is not catastrophic, it just
causes TCP to exit slow-start early and have to go into normal
window growth phase. The problem is that the original non-Hystart
behavior of Cubic is unfair; the first flow dominates the link
and other flows are unable to get in. If you run tests with two
flows one will get a larger share of the bandwidth.
I think Hystart is okay in concept but there may be issues
on low RTT links as well as other corner cases that need bug
fixing.
1. Needs to use better resolution than HZ. Since HZ can be 100.
2. Hardcoding 2ms as spacing between ACK's as train is wrong
for local networks.
^ permalink raw reply
* Re: [rds-devel] [PATCH] rds: prevent BUG_ON triggering on congestion map updates
From: Venkat Venkatsubra @ 2011-03-08 23:36 UTC (permalink / raw)
To: nhorman; +Cc: netdev, rds-devel, chris.mason, davem
I was trying to recreate on our test systems. It's not a ppc.
So far not successful in crashing even though rds_ib_xmit hits this path:
/* Do not send cong updates to IB loopback */
if (conn->c_loopback
&& rm->m_inc.i_hdr.h_flags & RDS_FLAG_CONG_BITMAP) {
rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
}
For the BUG_ON condition in rds_send_xmit:
ret=4096 conn->c_xmit_sg=1 rm->data.op_nents=2
BUG_ON(ret != 0 && conn->c_xmit_sg == rm->data.op.nents);
Venkat
----- Original Message -----
From: nhorman@tuxdriver.com
To: davem@davemloft.net
Cc: chris.mason@oracle.com, netdev@vger.kernel.org, rds-devel@oss.oracle.com, venkat.x.venkatsubra@oracle.com
Sent: Tuesday, March 8, 2011 1:36:50 PM GMT -06:00 US/Canada Central
Subject: Re: [rds-devel] [PATCH] rds: prevent BUG_ON triggering on congestion map updates
On Tue, Mar 08, 2011 at 11:22:58AM -0800, David Miller wrote:
> From: Chris Mason <chris.mason@oracle.com>
> Date: Tue, 08 Mar 2011 13:58:57 -0500
>
> > Excerpts from David Miller's message of 2011-03-08 13:52:23 -0500:
> >> From: Chris Mason <chris.mason@oracle.com>
> >> Date: Mon, 07 Mar 2011 15:41:04 -0500
> >>
> >> > Excerpts from David Miller's message of 2011-03-07 15:27:53 -0500:
> >> >> From: Neil Horman <nhorman@tuxdriver.com>
> >> >> Date: Wed, 2 Mar 2011 11:28:22 -0500
> >> >>
> >> >> > Recently had this bug halt reported to me:
> >> >>
> >> >> Well, does anyone on the RDS team care about this bug fix at all?
> >> >>
> >> >> Stuff like this should not sit for nearly a week without any reply
> >> >> whatsoever.
> >> >>
> >> >
> >> > The patch looks good to me, but I'm surprised we haven't seen it here.
> >> > Venkat please take a look (link to the patch below) Has it only been seen on ppc?
> >> >
> >> > http://permalink.gmane.org/gmane.linux.network/187933
> >>
> >> Can I get an ACK or something, _please_?
> >
> > Sorry, wasn't clear:
> >
> > Acked-by: Chris Mason <chris.mason@oracle.com>
>
> Applied, thanks everyone.
Thanks, Chris, Dave.
Neil
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2011-03-09 0:11 UTC (permalink / raw)
To: Dmitry Kravkov
Cc: David Miller, netdev@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Eilon Greenstein,
Vladislav Zolotarov
In-Reply-To: <1299577473.17233.41.camel@lb-tlvb-dmitry>
[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]
Hi Dmitry,
On Tue, 8 Mar 2011 11:44:33 +0200 "Dmitry Kravkov" <dmitry@broadcom.com> wrote:
>
> You are correct it's just an addition and it does not really matter
> where to do this. But the merge pushed new code in the middle
> of MAC configuration between MAC and multicast list.
> It's clearer to put it at the end of MAC/ML/UL block:
> ---
> drivers/net/bnx2x/bnx2x_cmn.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
> index b01b622..9e37675 100644
> --- a/drivers/net/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/bnx2x/bnx2x_cmn.c
> @@ -1498,6 +1498,11 @@ int bnx2x_nic_load(struct bnx2x *bp, int load_mode)
> /* Clear UC lists configuration */
> bnx2x_invalidate_uc_list(bp);
>
> + if (bp->pending_max) {
> + bnx2x_update_max_mf_config(bp, bp->pending_max);
> + bp->pending_max = 0;
> + }
> +
> if (bp->port.pmf)
> bnx2x_initial_phy_init(bp, load_mode);
OK, thanks. I have changed the conflict resolution to do that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] ipv4: Cache source address in nexthop entries.
From: Julian Anastasov @ 2011-03-09 0:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110308.103801.193702247.davem@davemloft.net>
Hello,
On Tue, 8 Mar 2011, David Miller wrote:
>> As the addresses have nothing to do with the link
>> state, I don't think it is correct to call fib_update_nh_saddrs
>> for DEV events.
>
> fib_update_nh_saddrs() gets called for "DEV" events since those
> are what are emitted when addresses are addded and removed.
But we still need to propagate the address events
to nexthops on all devices. Even if it is slow, I see it in
this way (not tested):
static inline void update_nh_saddr(const struct in_ifaddr *ifa,
struct net_device *dev,
struct fib_nh *nexthop_nh,
unsigned long event)
{
if (event == NETDEV_UP) {
if (ifa->ifa_local == nexthop_nh->nh_saddr)
return;
} else {
if (ifa->ifa_local != nexthop_nh->nh_saddr)
return;
}
if (ifa->ifa_scope > nexthop_nh->nh_cfg_scope)
return;
if (dev != nexthop_nh->nh_dev && ifa->ifa_scope >= RT_SCOPE_LINK)
return;
if (nexthop_nh->nh_flags & RTNH_F_DEAD)
return;
nexthop_nh->nh_saddr = inet_select_addr(nexthop_nh->nh_dev,
nexthop_nh->nh_gw,
nexthop_nh->nh_cfg_scope);
}
void fib_update_nh_saddrs(const struct in_ifaddr *ifa, unsigned long event)
{
struct net_device *dev = ifa->ifa_dev->dev;
int i;
for (i = 0; i < fib_hash_size; i++) {
struct hlist_head *head = &fib_info_hash[i];
struct hlist_node *node;
struct fib_info *fi;
hlist_for_each_entry(fi, node, head, fib_hash) {
if (fi->fib_prefsrc)
continue;
change_nexthops(fi) {
if (!nexthop_nh->nh_dev)
continue;
update_nh_saddr(ifa, dev, nexthop_nh, event);
} endfor_nexthops(fi);
}
}
}
Then may be fib_sync_up() should also refresh nh_saddr,
so that all alive nexthops get actual source address which
was not possible while device was down.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Injong Rhee @ 2011-03-09 1:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, lucas.nussbaum, xiyou.wangcong, netdev, sangtae.ha
In-Reply-To: <20110308152103.714f5f05@nehalam>
HyStart is a slow start algorithm, but not a congestion control
algorithm. So the difference between vegas and hystart is obvious. Yes.
Both hystart and vegas use delays for indication of congestion. But
hystart exits slow starts at the detection of congestion and enters
normal congestion avoidance; in some sense, it is much safer than vegas
as it does not change the regular behaviors of congestion control.
I think the main problem arising right now is not because it is using
noisy delays as congestion indication, but because of rather some
implementation issues like use of Hz, hardcoding 2ms, etc.
Then, you might ask why hystart can use delays while vegas can't. The
main motivation for use delays during slow start is that slow start
creates an environment where delay samples can be more trusted. That is
because it sends so many packets as a a burst because of doubling
windows, which can be used as packet train to estimate the available
capacity more reliably.
(tool 1) When many packets are sent in burst, the spacing in returning
ACKs can be a good indicator. Hystart also uses delays as an estimation.
(tool 2) If estimated avg delays increase beyond a certain threshold, it
sees that as a possible congestion.
Now, both tools can be wrong. But that is not catastrophic since
congestion avoidance can kick in to save the day. In a pipe where no
other flows are competing, then exiting slow start too early can slow
things down as the window can be still too small. But that is in fact
when delays are most reliable. So those tests that say bad performance
with hystart are in fact, where hystart is supposed to perform well.
Then why do we have a bad performance? I think the answer is again the
implementation flaws -- use different hardware, some hardwired codes,
etc, and also could be related to a few corner cases like very low RTT
links.
Let us examine Stephen's analysis in more detail.
1. Use of minRTT is ok. I agree.
2. Dmin can be too large at the beginning. But it is just like minRTT.
This cannot be too large. If you trust minRTT, then delay estimation
should say that there is a congestion. This is exactly the opposite case
to the cases we are seeing. If Dmin is too large, then hystart would not
exit the slow start as it does not detect the congestion. That is not
what we are seeing right now.
3. Dmin can be smaller than clock resolution. That is why we are using a
bunch of ACKs to get better accuracy. With a bunch of ACKs, we get
higher value of spacing so that we can take average.
4. If ACKs are nudged together, then hystart does not quit slow start.
Instead, it sees that there is no congestion. It is when it sees big
spacing between ACKs -- that is when it detects congestion.
On 3/8/11 6:21 PM, Stephen Hemminger wrote:
> On Tue, 08 Mar 2011 11:43:46 -0800 (PST)
> David Miller<davem@davemloft.net> wrote:
>
>> From: Injong Rhee<rhee@ncsu.edu>
>> Date: Tue, 08 Mar 2011 10:26:36 -0500
>>
>>> Thanks for updating CUBIC hystart. You might want to test the
>>> cases with more background traffic and verify whether this
>>> threshold is too conservative.
>> So let's get down to basics.
>>
>> What does Hystart do specially that allows it to avoid all of the
>> problems that TCP VEGAS runs into.
>>
>> Specifically, that if you use RTTs to make congestion control
>> decisions it is impossible to notice new bandwidth becomming available
>> fast enough.
>>
>> Again, it's impossible to react fast enough. No matter what you tweak
>> all of your various settings to, this problem will still exist.
>>
>> This is a core issue, you cannot get around it.
>>
>> This is why I feel that Hystart is fundamentally flawed and we should
>> turn it off by default if not flat-out remove it.
>>
>> Distributions are turning it off by default already, therefore it's
>> stupid for the upstream kernel to behave differently if that's what
>> %99 of the world is going to end up experiencing.
> The assumption in Hystart that spacing between ACK's is solely due to
> congestion is a bad. If you read the paper, this is why FreeBSD's
> estimation logic is dismissed. The Hystart problem is different
> than the Vegas issue.
>
> Algorithms that look at min RTT are ok, since the lower bound is
> fixed; additional queuing and variation in network only increases RTT
> it never reduces it. With a min RTT it is possible to compute the
> upper bound on available bandwidth. i.e If all packets were as good as
> this estimate minRTT then the available bandwidth is X. But then using
> an individual RTT sample to estimate unused bandwidth is flawed. To
> quote paper.
>
> "Thus, by checking whether ∆(N ) is larger than Dmin , we
> can detect whether cwnd has reached the available capacity
> of the path"
>
> So what goes wrong:
> 1. Dmin can be too large because this connection always sees delays
> due to other traffic or hardware. i.e buffer bloat. This would cause
> the bandwidth estimate to be too low and therefore TCP would leave
> slow start too early (and not get up to full bandwidth).
>
> 2. Dmin can be smaller than the clock resolution. This would cause
> either sample to be ignored, or Dmin to be zero. If Dmin is zero,
> the bandwidth estimate would in theory be infinite, which would
> lead to TCP not leaving slow start because of Hystart. Instead
> TCP would leave slow start at first loss.
>
> Other possible problems:
> 3. ACK's could be nudged together by variations in delay.
> This would cause HyStart to exit slow start prematurely. To false
> think it is an ACK train.
>
> Noise in network is not catastrophic, it just
> causes TCP to exit slow-start early and have to go into normal
> window growth phase. The problem is that the original non-Hystart
> behavior of Cubic is unfair; the first flow dominates the link
> and other flows are unable to get in. If you run tests with two
> flows one will get a larger share of the bandwidth.
>
> I think Hystart is okay in concept but there may be issues
> on low RTT links as well as other corner cases that need bug
> fixing.
>
> 1. Needs to use better resolution than HZ. Since HZ can be 100.
> 2. Hardcoding 2ms as spacing between ACK's as train is wrong
> for local networks.
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Sangtae Ha @ 2011-03-09 1:33 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, rhee, lucas.nussbaum, xiyou.wangcong, netdev
In-Reply-To: <20110308152103.714f5f05@nehalam>
Hi Stephen,
Thank you for your feedback. Please see my answers below.
On Tue, Mar 8, 2011 at 6:21 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Tue, 08 Mar 2011 11:43:46 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Injong Rhee <rhee@ncsu.edu>
>> Date: Tue, 08 Mar 2011 10:26:36 -0500
>>
>> > Thanks for updating CUBIC hystart. You might want to test the
>> > cases with more background traffic and verify whether this
>> > threshold is too conservative.
>>
>> So let's get down to basics.
>>
>> What does Hystart do specially that allows it to avoid all of the
>> problems that TCP VEGAS runs into.
>>
>> Specifically, that if you use RTTs to make congestion control
>> decisions it is impossible to notice new bandwidth becomming available
>> fast enough.
>>
>> Again, it's impossible to react fast enough. No matter what you tweak
>> all of your various settings to, this problem will still exist.
>>
>> This is a core issue, you cannot get around it.
>>
>> This is why I feel that Hystart is fundamentally flawed and we should
>> turn it off by default if not flat-out remove it.
>>
>> Distributions are turning it off by default already, therefore it's
>> stupid for the upstream kernel to behave differently if that's what
>> %99 of the world is going to end up experiencing.
>
> The assumption in Hystart that spacing between ACK's is solely due to
> congestion is a bad. If you read the paper, this is why FreeBSD's
> estimation logic is dismissed. The Hystart problem is different
> than the Vegas issue.
>
> Algorithms that look at min RTT are ok, since the lower bound is
> fixed; additional queuing and variation in network only increases RTT
> it never reduces it. With a min RTT it is possible to compute the
> upper bound on available bandwidth. i.e If all packets were as good as
> this estimate minRTT then the available bandwidth is X. But then using
> an individual RTT sample to estimate unused bandwidth is flawed. To
> quote paper.
>
> "Thus, by checking whether ∆(N ) is larger than Dmin , we
> can detect whether cwnd has reached the available capacity
> of the path"
>
> So what goes wrong:
> 1. Dmin can be too large because this connection always sees delays
> due to other traffic or hardware. i.e buffer bloat. This would cause
> the bandwidth estimate to be too low and therefore TCP would leave
> slow start too early (and not get up to full bandwidth).
This is true. But the idea is that running the congestion avoidance
algorithm of CUBIC for this case is better than hurting other flows
with abrupt perturbation, since the growth of CUBIC is quite
responsive and grab the bandwidth quickly in normal network
conditions.
>
> 2. Dmin can be smaller than the clock resolution. This would cause
> either sample to be ignored, or Dmin to be zero. If Dmin is zero,
> the bandwidth estimate would in theory be infinite, which would
> lead to TCP not leaving slow start because of Hystart. Instead
> TCP would leave slow start at first loss.
True. But since HyStart didn't clamp the threshold, ca->delay_min>>4,
it can prematurely leave slow start for very small Dmin. I think this
needs to be fixed, along with the hard-coded 2ms you mentioned below.
>
> Other possible problems:
> 3. ACK's could be nudged together by variations in delay.
> This would cause HyStart to exit slow start prematurely. To false
> think it is an ACK train.
This doesn't happen when the delay is not too small (in typical WAN
including DSL), but it is possible with very small delays since the
code checking the valid ACK train uses the 2ms fixed value, which is
large for LAN.
>
> Noise in network is not catastrophic, it just
> causes TCP to exit slow-start early and have to go into normal
> window growth phase. The problem is that the original non-Hystart
> behavior of Cubic is unfair; the first flow dominates the link
> and other flows are unable to get in. If you run tests with two
> flows one will get a larger share of the bandwidth.
>
> I think Hystart is okay in concept but there may be issues
> on low RTT links as well as other corner cases that need bug
> fixing.
We do not use the delay as indication of congestion, but we use it for
improving the stability and overall performance.
Preventing burst losses quite help for mid to large BDP paths and the
performance results with non-TCP-SACK receivers are also encouraging.
I will work on the fix for the issues below.
>
> 1. Needs to use better resolution than HZ. Since HZ can be 100.
> 2. Hardcoding 2ms as spacing between ACK's as train is wrong
> for local networks.
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* [net-next-2.6 PATCH] enic: Support newer version of firmware devcmd CMD_MCPU_FW_INFO
From: Vasanthy Kolluri @ 2011-03-09 1:35 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Vasanthy Kolluri <vkolluri@cisco.com>
This patch provides support to the newer version of firmware devcmd CMD_MCPU_FW_INFO
that returns additional information (ASIC type and revision) about the underlying hardware.
This knowledge is required by the driver to implement any hardware specific features.
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/vnic_dev.c | 7 +++++++
drivers/net/enic/vnic_devcmd.h | 38 ++++++++++++++++++++++++++++++++++++--
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index e816bbb..3a3c3c8 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.10"
+#define DRV_VERSION "2.1.1.12"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
diff --git a/drivers/net/enic/vnic_dev.c b/drivers/net/enic/vnic_dev.c
index c489e72..c089b36 100644
--- a/drivers/net/enic/vnic_dev.c
+++ b/drivers/net/enic/vnic_dev.c
@@ -408,10 +408,17 @@ int vnic_dev_fw_info(struct vnic_dev *vdev,
if (!vdev->fw_info)
return -ENOMEM;
+ memset(vdev->fw_info, 0, sizeof(struct vnic_devcmd_fw_info));
+
a0 = vdev->fw_info_pa;
+ a1 = sizeof(struct vnic_devcmd_fw_info);
/* only get fw_info once and cache it */
err = vnic_dev_cmd(vdev, CMD_MCPU_FW_INFO, &a0, &a1, wait);
+ if (err == ERR_ECMDUNKNOWN) {
+ err = vnic_dev_cmd(vdev, CMD_MCPU_FW_INFO_OLD,
+ &a0, &a1, wait);
+ }
}
*fw_info = vdev->fw_info;
diff --git a/drivers/net/enic/vnic_devcmd.h b/drivers/net/enic/vnic_devcmd.h
index 9abb3d5..d833a07 100644
--- a/drivers/net/enic/vnic_devcmd.h
+++ b/drivers/net/enic/vnic_devcmd.h
@@ -80,8 +80,34 @@
enum vnic_devcmd_cmd {
CMD_NONE = _CMDC(_CMD_DIR_NONE, _CMD_VTYPE_NONE, 0),
- /* mcpu fw info in mem: (u64)a0=paddr to struct vnic_devcmd_fw_info */
- CMD_MCPU_FW_INFO = _CMDC(_CMD_DIR_WRITE, _CMD_VTYPE_ALL, 1),
+ /*
+ * mcpu fw info in mem:
+ * in:
+ * (u64)a0=paddr to struct vnic_devcmd_fw_info
+ * action:
+ * Fills in struct vnic_devcmd_fw_info (128 bytes)
+ * note:
+ * An old definition of CMD_MCPU_FW_INFO
+ */
+ CMD_MCPU_FW_INFO_OLD = _CMDC(_CMD_DIR_WRITE, _CMD_VTYPE_ALL, 1),
+
+ /*
+ * mcpu fw info in mem:
+ * in:
+ * (u64)a0=paddr to struct vnic_devcmd_fw_info
+ * (u16)a1=size of the structure
+ * out:
+ * (u16)a1=0 for in:a1 = 0,
+ * data size actually written for other values.
+ * action:
+ * Fills in first 128 bytes of vnic_devcmd_fw_info for in:a1 = 0,
+ * first in:a1 bytes for 0 < in:a1 <= 132,
+ * 132 bytes for other values of in:a1.
+ * note:
+ * CMD_MCPU_FW_INFO and CMD_MCPU_FW_INFO_OLD have the same enum 1
+ * for source compatibility.
+ */
+ CMD_MCPU_FW_INFO = _CMDC(_CMD_DIR_RW, _CMD_VTYPE_ALL, 1),
/* dev-specific block member:
* in: (u16)a0=offset,(u8)a1=size
@@ -291,11 +317,19 @@ enum vnic_devcmd_error {
ERR_EMAXRES = 10,
};
+/*
+ * note: hw_version and asic_rev refer to the same thing,
+ * but have different formats. hw_version is
+ * a 32-byte string (e.g. "A2") and asic_rev is
+ * a 16-bit integer (e.g. 0xA2).
+ */
struct vnic_devcmd_fw_info {
char fw_version[32];
char fw_build[32];
char hw_version[32];
char hw_serial_number[32];
+ u16 asic_type;
+ u16 asic_rev;
};
struct vnic_devcmd_notify {
^ permalink raw reply related
* Re: Network performance with small packets
From: Andrew Theurer @ 2011-03-09 2:21 UTC (permalink / raw)
To: Shirley Ma
Cc: Rusty Russell, Michael S. Tsirkin, Krishna Kumar2, David Miller,
kvm, netdev, steved, Tom Lendacky
In-Reply-To: <1299621444.25664.77.camel@localhost.localdomain>
On Tue, 2011-03-08 at 13:57 -0800, Shirley Ma wrote:
> On Wed, 2011-02-09 at 11:07 +1030, Rusty Russell wrote:
> > I've finally read this thread... I think we need to get more serious
> > with our stats gathering to diagnose these kind of performance issues.
> >
> > This is a start; it should tell us what is actually happening to the
> > virtio ring(s) without significant performance impact...
>
> Should we also add similar stat on vhost vq as well for monitoring
> vhost_signal & vhost_notify?
Tom L has started using Rusty's patches and found some interesting
results, sent yesterday:
http://marc.info/?l=kvm&m=129953710930124&w=2
-Andrew
>
> Shirley
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2011-03-09 2:42 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Emil Tantilov, Stephen Ko, Jeff Kirsher
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
Hi all,
After merging the net tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/net/ixgbe/ixgbe_mbx.c: In function 'ixgbe_init_mbx_params_pf':
drivers/net/ixgbe/ixgbe_mbx.c:456: error: 'struct ixgbe_mbx_info' has no member named 'udelay'
Caused by commit d7c8a29fc8bd20ba45ec2f52577ed04a988a9500 ("ixgbe:
improve logic in ixgbe_init_mbx_params_pf").
I am wondering if that was ever built ...
I have used the net tree from next-20110308 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: bonding can't change to another slave if you ifdown the active slave
From: Weiping Pan @ 2011-03-09 2:40 UTC (permalink / raw)
To: WANG Cong; +Cc: netdev
In-Reply-To: <il58p9$3ka$2@dough.gmane.org>
On 03/08/2011 08:51 PM, WANG Cong wrote:
> On Tue, 08 Mar 2011 14:52:52 +0800, Weiping Pan wrote:
>
>> ok, I use "Host-only mode" and get
>>
>>
>>
>> an conclusion, that if the first enslaved nic is pulled out, bonding
>> can't handle well.
>>
>> First test.
>> I first enslave eth6, then pull it out, bonding doesn't work. on host,
> ...
>>
>> Second test
>> I first enslave eth6, then pull eth7 out, bonding works well. on guest,
> Can you show me your /proc/net/bonding/bond0 before and after pulling down
> eth6 or eth7? And what does `ip link show` say?
>
Ok, let me repeat my test, and gather more information.
on host,
[root@localhost ~]# VBoxManage -v
4.0.2r69518
[root@localhost ~]# VBoxManage showvminfo
67b83c47-0ee2-46bc-b0ff-e0eb43edc1c2|grep ^NIC
NIC 1: MAC: 0800270481A8, Attachment: Host-only Interface
'vboxnet0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 2: MAC: 08002778F641, Attachment: Host-only Interface
'vboxnet0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 3: MAC: 080027C408BA, Attachment: Host-only Interface
'vboxnet0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 4: MAC: 080027DB339A, Attachment: Host-only Interface
'vboxnet0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
[root@localhost ~]# ifconfig
vboxnet0 Link encap:Ethernet HWaddr 0A:00:27:00:00:00
inet addr:192.168.56.1 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::800:27ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3438 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:296716 (289.7 KiB)
vboxnet0:0 Link encap:Ethernet HWaddr 0A:00:27:00:00:00
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
vboxnet0:1 Link encap:Ethernet HWaddr 0A:00:27:00:00:00
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[root@localhost ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.1.0 * 255.255.255.0 U 0 0 0
vboxnet0
192.168.56.0 * 255.255.255.0 U 0 0 0
vboxnet0
10.66.64.0 * 255.255.254.0 U 1 0 0 eth0
default corerouter.nay. 0.0.0.0 UG 0 0 0 eth0
[root@localhost ~]# ip neigh show
10.66.65.254 dev eth0 lladdr 00:1d:45:20:d5:ff REACHABLE
then restart guest,
[root@localhost ~]# ifconfig
eth6 Link encap:Ethernet HWaddr 08:00:27:78:F6:41
inet addr:192.168.56.101 Bcast:192.168.56.255
Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe78:f641/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6772 (6.6 KiB) TX bytes:1152 (1.1 KiB)
eth7 Link encap:Ethernet HWaddr 08:00:27:04:81:A8
inet addr:192.168.56.102 Bcast:192.168.56.255
Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe04:81a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6772 (6.6 KiB) TX bytes:1152 (1.1 KiB)
eth8 Link encap:Ethernet HWaddr 08:00:27:DB:33:9A
inet addr:192.168.56.104 Bcast:192.168.56.255
Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fedb:339a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6772 (6.6 KiB) TX bytes:1152 (1.1 KiB)
eth9 Link encap:Ethernet HWaddr 08:00:27:C4:08:BA
inet addr:192.168.56.103 Bcast:192.168.56.255
Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fec4:8ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6772 (6.6 KiB) TX bytes:1152 (1.1 KiB)
so according to mac address,
NIC 1: eth7
NIC 2: eth6
NIC 3: eth9
NIC 4: eth8
[root@localhost ~]# ifconfig eth6 down
[root@localhost ~]# ifconfig eth7 down
[root@localhost ~]# ifconfig eth8 down
[root@localhost ~]# ifconfig eth9 down
[root@localhost ~]# modprobe bonding mode=0 miimon=100
[root@localhost ~]# ifconfig bond0 192.168.1.2 netmask 255.255.255.0 up
[root@localhost ~]# ifenslave bond0 eth6
[root@localhost ~]# ifenslave bond0 eth7
[root@localhost ~]# dmesg
[ 1436.344751] bonding: Ethernet Channel Bonding Driver: v3.6.0
(September 26, 2009)
[ 1436.344756] bonding: MII link monitoring set to 100 ms
[ 1480.485933] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 1490.087608] e1000: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
[ 1490.091795] bonding: bond0: enslaving eth6 as an active interface
with an up link.
[ 1490.092326] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 1492.676643] e1000: eth7 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
[ 1492.684839] bonding: bond0: enslaving eth7 as an active interface
with an up link.
[root@localhost ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth6
MII Status: up
Link Failure Count: 0
Permanent HW addr: 08:00:27:78:f6:41
Slave Interface: eth7
MII Status: up
Link Failure Count: 0
Permanent HW addr: 08:00:27:04:81:a8
[root@localhost ~]# ifconfig
bond0 Link encap:Ethernet HWaddr 08:00:27:78:F6:41
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe78:f641/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19632 (19.1 KiB) TX bytes:4070 (3.9 KiB)
eth6 Link encap:Ethernet HWaddr 08:00:27:78:F6:41
inet addr:192.168.56.101 Bcast:192.168.56.255
Mask:255.255.255.0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:21 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10158 (9.9 KiB) TX bytes:1802 (1.7 KiB)
eth7 Link encap:Ethernet HWaddr 08:00:27:78:F6:41
inet addr:192.168.56.101 Bcast:192.168.56.255
Mask:255.255.255.0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:19 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9474 (9.2 KiB) TX bytes:2268 (2.2 KiB)
[root@localhost ~]# ping 192.168.1.100 -c 5
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_req=1 ttl=64 time=3.69 ms
64 bytes from 192.168.1.100: icmp_req=2 ttl=64 time=0.242 ms
64 bytes from 192.168.1.100: icmp_req=3 ttl=64 time=0.154 ms
64 bytes from 192.168.1.100: icmp_req=4 ttl=64 time=0.270 ms
64 bytes from 192.168.1.100: icmp_req=5 ttl=64 time=0.278 ms
--- 192.168.1.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.154/0.928/3.696/1.384 ms
[root@localhost ~]# dmesg -c &>/dev/null
on host,
[root@localhost ~]# VBoxManage controlvm
67b83c47-0ee2-46bc-b0ff-e0eb43edc1c2 setlinkstate2 off
on guest,
[root@localhost ~]# dmesg
[ 1731.945272] e1000: eth6 NIC Link is Down
[ 1732.026207] bonding: bond0: link status definitely down for interface
eth6, disabling it
[root@localhost ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth6
MII Status: down
Link Failure Count: 1
Permanent HW addr: 08:00:27:78:f6:41
Slave Interface: eth7
MII Status: up
Link Failure Count: 0
Permanent HW addr: 08:00:27:04:81:a8
[root@localhost ~]# ping 192.168.1.100 -c 5
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
From 192.168.1.2 icmp_seq=4 Destination Host Unreachable
From 192.168.1.2 icmp_seq=5 Destination Host Unreachable
--- 192.168.1.100 ping statistics ---
5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4001ms
pipe 3
[root@localhost ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth7: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast master bond0 state UP qlen 1000
link/ether 08:00:27:78:f6:41 brd ff:ff:ff:ff:ff:ff
3: eth6: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc
pfifo_fast master bond0 state DOWN qlen 1000
link/ether 08:00:27:78:f6:41 brd ff:ff:ff:ff:ff:ff
4: eth9: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen
1000
link/ether 08:00:27:c4:08:ba brd ff:ff:ff:ff:ff:ff
5: eth8: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen
1000
link/ether 08:00:27:db:33:9a brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP
link/ether 08:00:27:78:f6:41 brd ff:ff:ff:ff:ff:ff
[root@localhost ~]# ip neigh show
192.168.1.100 dev bond0 FAILED
on host,
[root@localhost ~]# ip neigh show
10.66.65.254 dev eth0 lladdr 00:1d:45:20:d5:ff STALE
192.168.1.2 dev vboxnet0 lladdr 08:00:27:78:f6:41 STALE
on guest, ping while tcpdump
[root@localhost ~]# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=11 Destination Host Unreachable
From 192.168.1.2 icmp_seq=12 Destination Host Unreachable
From 192.168.1.2 icmp_seq=13 Destination Host Unreachable
From 192.168.1.2 icmp_seq=15 Destination Host Unreachable
From 192.168.1.2 icmp_seq=16 Destination Host Unreachable
From 192.168.1.2 icmp_seq=17 Destination Host Unreachable
From 192.168.1.2 icmp_seq=19 Destination Host Unreachable
From 192.168.1.2 icmp_seq=20 Destination Host Unreachable
From 192.168.1.2 icmp_seq=21 Destination Host Unreachable
From 192.168.1.2 icmp_seq=23 Destination Host Unreachable
From 192.168.1.2 icmp_seq=24 Destination Host Unreachable
From 192.168.1.2 icmp_seq=25 Destination Host Unreachable
From 192.168.1.2 icmp_seq=27 Destination Host Unreachable
From 192.168.1.2 icmp_seq=28 Destination Host Unreachable
From 192.168.1.2 icmp_seq=29 Destination Host Unreachable
^C
--- 192.168.1.100 ping statistics ---
30 packets transmitted, 0 received, +15 errors, 100% packet loss, time
29011ms
pipe 3
[root@localhost ~]# tcpdump -i bond0 -p arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:22:40.694058 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:41.695875 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:42.698067 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:44.689068 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:45.689837 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:46.692076 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:48.691080 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:49.693828 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:50.696074 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:52.693070 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:53.693837 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:54.696075 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:56.694072 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:57.696063 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:22:58.698096 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:23:00.696065 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:23:01.698072 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:23:02.700063 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:23:04.698071 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:23:05.700504 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
21:23:06.702009 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
^C
21 packets captured
21 packets received by filter
0 packets dropped by kernel
meanwhile on host,
[root@localhost ~]# tcpdump -i vboxnet0 -p arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:22:56.936833 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:22:56.936839 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:22:57.938415 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:22:57.938422 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:22:58.939875 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:22:58.939881 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:00.937292 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:00.937299 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:01.939242 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:01.939249 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:02.940559 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:02.940565 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:04.938148 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:04.938156 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:05.939688 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:05.939695 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:06.941288 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
10:23:06.941295 ARP, Request who-has 192.168.1.100 tell 192.168.1.2,
length 28
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel
Maybe this is the cause of the problem.
The guest can't receive correct ARP reply, maybe the virtual network of
VirtualBox doesn't transfer it.
on host,
[root@localhost ~]# VBoxManage controlvm
67b83c47-0ee2-46bc-b0ff-e0eb43edc1c2 setlinkstate2 on
on guest,
[root@localhost ~]# dmesg
[ 2392.304591] e1000: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: RX
[ 2392.381223] bonding: bond0: link status definitely up for interface eth6.
[root@localhost ~]# ping 192.168.1.100 -c5
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_req=1 ttl=64 time=0.648 ms
64 bytes from 192.168.1.100: icmp_req=2 ttl=64 time=0.208 ms
64 bytes from 192.168.1.100: icmp_req=3 ttl=64 time=0.187 ms
64 bytes from 192.168.1.100: icmp_req=4 ttl=64 time=0.274 ms
64 bytes from 192.168.1.100: icmp_req=5 ttl=64 time=0.216 ms
--- 192.168.1.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.187/0.306/0.648/0.174 ms
[root@localhost ~]# ip neigh show
192.168.1.100 dev bond0 lladdr 0a:00:27:00:00:00 REACHABLE
thanks
Weiping Pan
^ permalink raw reply
* Re: bonding can't change to another slave if you ifdown the active slave
From: Weiping Pan @ 2011-03-09 3:38 UTC (permalink / raw)
To: WANG Cong; +Cc: netdev
In-Reply-To: <il58p9$3ka$2@dough.gmane.org>
On 03/08/2011 08:51 PM, WANG Cong wrote:
> On Tue, 08 Mar 2011 14:52:52 +0800, Weiping Pan wrote:
>
>> ok, I use "Host-only mode" and get
>>
>>
>>
>> an conclusion, that if the first enslaved nic is pulled out, bonding
>> can't handle well.
>>
>> First test.
>> I first enslave eth6, then pull it out, bonding doesn't work. on host,
> ...
>>
>> Second test
>> I first enslave eth6, then pull eth7 out, bonding works well. on guest,
> Can you show me your /proc/net/bonding/bond0 before and after pulling down
> eth6 or eth7? And what does `ip link show` say?
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
And I test it again, there is no problem with kvm.
Maybe there is bug in virtualbox.
thanks
Weiping Pan
^ permalink raw reply
* [PATCH 1/2] net: Allow no-cache copy from user on transmit
From: Tom Herbert @ 2011-03-09 5:05 UTC (permalink / raw)
To: davem, netdev
This patch uses __copy_from_user_nocache (from skb_copy_to_page)
on transmit to bypass data cache for a performance improvement.
This functionality is configurable per device using ethtool, the
device must also be doing TX csum offload to enable. It seems
reasonable to set this when the device does not copy or
otherwise touch the data.
This patch was tested using 200 instances of netperf TCP_RR with
1400 byte request and one byte reply. Platform is 16 core AMD.
No-cache copy disabled:
672703 tps, 97.13% client utilization
50/90/99% latency 244.31 484.205 1028.41
No-cache copy enabled:
702113 tps, 96.16% client utilization,
50/90/99% latency 238.56 467.56 956.955
This seems to provide a nice little performance improvement and is
consistent in the tests I ran. Presumably, this would provide
the greatest benfits in the presence of an application workload
stressing the cache and a lot of transmit data happening. I don't
yet see a downside to using this.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/ethtool.h | 4 ++++
include/linux/netdevice.h | 4 +++-
include/net/sock.h | 5 +++++
net/core/ethtool.c | 11 ++++++++++-
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index aac3e2e..2cf3cc9 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -833,6 +833,10 @@ struct ethtool_ops {
#define ETHTOOL_GFEATURES 0x0000003a /* Get device offload settings */
#define ETHTOOL_SFEATURES 0x0000003b /* Change device offload settings */
+#define ETHTOOL_GNCCOPY 0x0000003c /* Get no-cache-copy enable
+ * (ethtool_value). */
+#define ETHTOOL_SNCCOPY 0x0000003d /* Set no-cache-copy enable
+ * (ethtool_value). */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
#define SPARC_ETH_SSET ETHTOOL_SSET
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 71563e7..1b72f29 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -978,6 +978,7 @@ struct net_device {
#define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */
#define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */
#define NETIF_F_RXCSUM (1 << 29) /* Receive checksumming offload */
+#define NETIF_F_NOCACHE_COPY (1 << 30) /* Use no-cache copyfromuser */
/* Segmentation offload features */
#define NETIF_F_GSO_SHIFT 16
@@ -1020,7 +1021,8 @@ struct net_device {
NETIF_F_FRAGLIST)
/* changeable features with no special hardware requirements */
-#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
+#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO | \
+ NETIF_F_NOCACHE_COPY)
/* Interface index. Unique device identifier */
int ifindex;
diff --git a/include/net/sock.h b/include/net/sock.h
index da0534d..55b1385 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1401,6 +1401,11 @@ static inline int skb_copy_to_page(struct sock *sk, char __user *from,
if (err)
return err;
skb->csum = csum_block_add(skb->csum, csum, skb->len);
+ } else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
+ if (!access_ok(VERIFY_READ, from, copy)
+ || __copy_from_user_nocache(page_address(page) + off,
+ from, copy))
+ return -EFAULT;
} else if (copy_from_user(page_address(page) + off, from, copy))
return -EFAULT;
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c1a71bb..a8b2638 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -328,6 +328,7 @@ static const char netdev_features_strings[ETHTOOL_DEV_FEATURE_WORDS * 32][ETH_GS
/* NETIF_F_NETNS_LOCAL */ "netns-local",
/* NETIF_F_GRO */ "rx-gro",
/* NETIF_F_LRO */ "rx-lro",
+ /* NETIF_F_NOCACHE_COPY */ "tx-nocache-copy",
/* NETIF_F_TSO */ "tx-tcp-segmentation",
/* NETIF_F_UFO */ "tx-udp-fragmentation",
@@ -336,7 +337,6 @@ static const char netdev_features_strings[ETHTOOL_DEV_FEATURE_WORDS * 32][ETH_GS
/* NETIF_F_TSO6 */ "tx-tcp6-segmentation",
/* NETIF_F_FSO */ "tx-fcoe-segmentation",
"",
- "",
/* NETIF_F_FCOE_CRC */ "tx-checksum-fcoe-crc",
/* NETIF_F_SCTP_CSUM */ "tx-checksum-sctp",
@@ -400,6 +400,9 @@ static u32 ethtool_get_feature_mask(u32 eth_cmd)
case ETHTOOL_GGRO:
case ETHTOOL_SGRO:
return NETIF_F_GRO;
+ case ETHTOOL_GNCCOPY:
+ case ETHTOOL_SNCCOPY:
+ return NETIF_F_NOCACHE_COPY;
default:
BUG();
}
@@ -1487,6 +1490,9 @@ static int __ethtool_set_tx_csum(struct net_device *dev, u32 data)
return err;
}
+ if (!data)
+ dev->features &= ~NETIF_F_NOCACHE_COPY;
+
return dev->ethtool_ops->set_tx_csum(dev, data);
}
@@ -1768,6 +1774,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GUFO:
case ETHTOOL_GGSO:
case ETHTOOL_GGRO:
+ case ETHTOOL_GNCCOPY:
case ETHTOOL_GFLAGS:
case ETHTOOL_GPFLAGS:
case ETHTOOL_GRXFH:
@@ -1924,6 +1931,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GUFO:
case ETHTOOL_GGSO:
case ETHTOOL_GGRO:
+ case ETHTOOL_GNCCOPY:
rc = ethtool_get_one_feature(dev, useraddr, ethcmd);
break;
case ETHTOOL_STXCSUM:
@@ -1933,6 +1941,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SUFO:
case ETHTOOL_SGSO:
case ETHTOOL_SGRO:
+ case ETHTOOL_SNCCOPY:
rc = ethtool_set_one_feature(dev, useraddr, ethcmd);
break;
default:
--
1.7.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox