* [PATCH net-next 1/2] bonding: add sysfs /slave dir for bond slave devices.
From: Scott Feldman @ 2014-01-16 5:54 UTC (permalink / raw)
To: vfalico, fubar, andy; +Cc: netdev, roopa, shm
Add sub-directory under /sys/class/net/<interface>/slave with
read-only attributes for slave. Directory only appears when
<interface> is a slave.
$ tree /sys/class/net/eth2/slave/
/sys/class/net/eth2/slave/
├── ad_aggregator_id
├── link_failure_count
├── mii_status
├── perm_hwaddr
├── queue_id
└── state
$ cat /sys/class/net/eth2/slave/*
2
0
up
40:02:10:ef:06:01
0
active
Signed-off-by: Scott Feldman <sfeldma@cumulusnetworks.com>
---
drivers/net/bonding/Makefile | 2
drivers/net/bonding/bond_main.c | 27 ++++++
drivers/net/bonding/bond_procfs.c | 12 ---
drivers/net/bonding/bond_sysfs_slave.c | 142 ++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 4 +
5 files changed, 174 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/bonding/bond_sysfs_slave.c
diff --git a/drivers/net/bonding/Makefile b/drivers/net/bonding/Makefile
index 5a5d720..6f4e808 100644
--- a/drivers/net/bonding/Makefile
+++ b/drivers/net/bonding/Makefile
@@ -4,7 +4,7 @@
obj-$(CONFIG_BONDING) += bonding.o
-bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_debugfs.o bond_netlink.o bond_options.o
+bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_sysfs_slave.o bond_debugfs.o bond_netlink.o bond_options.o
proc-$(CONFIG_PROC_FS) += bond_procfs.o
bonding-objs += $(proc-y)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index f2fe6cb..4f1adae 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -466,6 +466,22 @@ static void bond_update_speed_duplex(struct slave *slave)
return;
}
+const char *bond_slave_link_status(s8 link)
+{
+ switch (link) {
+ case BOND_LINK_UP:
+ return "up";
+ case BOND_LINK_FAIL:
+ return "going down";
+ case BOND_LINK_DOWN:
+ return "down";
+ case BOND_LINK_BACK:
+ return "going back";
+ default:
+ return "unknown";
+ }
+}
+
/*
* if <dev> supports MII link status reporting, check its link status.
*
@@ -1576,6 +1592,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
goto err_unregister;
}
+ res = bond_sysfs_slave_add(new_slave);
+ if (res) {
+ pr_debug("Error %d calling bond_sysfs_slave_add\n", res);
+ goto err_upper_unlink;
+ }
+
bond->slave_cnt++;
bond_compute_features(bond);
bond_set_carrier(bond);
@@ -1595,6 +1617,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
return 0;
/* Undo stages on error */
+err_upper_unlink:
+ bond_upper_dev_unlink(bond_dev, slave_dev);
+
err_unregister:
netdev_rx_handler_unregister(slave_dev);
@@ -1687,6 +1712,8 @@ static int __bond_release_one(struct net_device *bond_dev,
/* release the slave from its bond */
bond->slave_cnt--;
+ bond_sysfs_slave_del(slave);
+
bond_upper_dev_unlink(bond_dev, slave_dev);
/* unregister rx_handler early so bond_handle_frame wouldn't be called
* for this slave anymore.
diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
index fb868d6..8515b344 100644
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -159,18 +159,6 @@ static void bond_info_show_master(struct seq_file *seq)
}
}
-static const char *bond_slave_link_status(s8 link)
-{
- static const char * const status[] = {
- [BOND_LINK_UP] = "up",
- [BOND_LINK_FAIL] = "going down",
- [BOND_LINK_DOWN] = "down",
- [BOND_LINK_BACK] = "going back",
- };
-
- return status[link];
-}
-
static void bond_info_show_slave(struct seq_file *seq,
const struct slave *slave)
{
diff --git a/drivers/net/bonding/bond_sysfs_slave.c b/drivers/net/bonding/bond_sysfs_slave.c
new file mode 100644
index 0000000..28390af
--- /dev/null
+++ b/drivers/net/bonding/bond_sysfs_slave.c
@@ -0,0 +1,142 @@
+/* Sysfs attributes of bond slaves
+ *
+ * Copyright (c) 2014 Scott Feldman <sfeldma@cumulusnetworks.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/capability.h>
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+
+#include "bonding.h"
+
+struct slave_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct slave *, char *);
+};
+
+#define SLAVE_ATTR(_name, _mode, _show) \
+const struct slave_attribute slave_attr_##_name = { \
+ .attr = {.name = __stringify(_name), \
+ .mode = _mode }, \
+ .show = _show, \
+};
+#define SLAVE_ATTR_RO(_name) \
+ SLAVE_ATTR(_name, S_IRUGO, _name##_show)
+
+static ssize_t state_show(struct slave *slave, char *buf)
+{
+ switch (bond_slave_state(slave)) {
+ case BOND_STATE_ACTIVE:
+ return sprintf(buf, "active\n");
+ case BOND_STATE_BACKUP:
+ return sprintf(buf, "backup\n");
+ default:
+ return sprintf(buf, "UNKONWN\n");
+ }
+}
+static SLAVE_ATTR_RO(state);
+
+static ssize_t mii_status_show(struct slave *slave, char *buf)
+{
+ return sprintf(buf, "%s\n", bond_slave_link_status(slave->link));
+}
+static SLAVE_ATTR_RO(mii_status);
+
+static ssize_t link_failure_count_show(struct slave *slave, char *buf)
+{
+ return sprintf(buf, "%d\n", slave->link_failure_count);
+}
+static SLAVE_ATTR_RO(link_failure_count);
+
+static ssize_t perm_hwaddr_show(struct slave *slave, char *buf)
+{
+ return sprintf(buf, "%pM\n", slave->perm_hwaddr);
+}
+static SLAVE_ATTR_RO(perm_hwaddr);
+
+static ssize_t queue_id_show(struct slave *slave, char *buf)
+{
+ return sprintf(buf, "%d\n", slave->queue_id);
+}
+static SLAVE_ATTR_RO(queue_id);
+
+static ssize_t ad_aggregator_id_show(struct slave *slave, char *buf)
+{
+ const struct aggregator *agg;
+
+ if (slave->bond->params.mode == BOND_MODE_8023AD) {
+ agg = SLAVE_AD_INFO(slave).port.aggregator;
+ if (agg)
+ return sprintf(buf, "%d\n",
+ agg->aggregator_identifier);
+ }
+
+ return sprintf(buf, "N/A\n");
+}
+static SLAVE_ATTR_RO(ad_aggregator_id);
+
+static const struct slave_attribute *slave_attrs[] = {
+ &slave_attr_state,
+ &slave_attr_mii_status,
+ &slave_attr_link_failure_count,
+ &slave_attr_perm_hwaddr,
+ &slave_attr_queue_id,
+ &slave_attr_ad_aggregator_id,
+ NULL
+};
+
+#define to_slave_attr(_at) container_of(_at, struct slave_attribute, attr)
+#define to_slave(obj) container_of(obj, struct slave, kobj)
+
+static ssize_t slave_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct slave_attribute *slave_attr = to_slave_attr(attr);
+ struct slave *slave = to_slave(kobj);
+
+ return slave_attr->show(slave, buf);
+}
+
+const struct sysfs_ops slave_sysfs_ops = {
+ .show = slave_show,
+};
+
+static struct kobj_type slave_ktype = {
+#ifdef CONFIG_SYSFS
+ .sysfs_ops = &slave_sysfs_ops,
+#endif
+};
+
+int bond_sysfs_slave_add(struct slave *slave)
+{
+ const struct slave_attribute **a;
+ int err;
+
+ err = kobject_init_and_add(&slave->kobj, &slave_ktype,
+ &(slave->dev->dev.kobj), "slave");
+ if (err)
+ return err;
+
+ for (a = slave_attrs; *a; ++a) {
+ err = sysfs_create_file(&slave->kobj, &((*a)->attr));
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+void bond_sysfs_slave_del(struct slave *slave)
+{
+ const struct slave_attribute **a;
+
+ for (a = slave_attrs; *a; ++a)
+ sysfs_remove_file(&slave->kobj, &((*a)->attr));
+
+ kobject_del(&slave->kobj);
+}
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 955dc48..309757d 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -203,6 +203,7 @@ struct slave {
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *np;
#endif
+ struct kobject kobj;
};
/*
@@ -421,6 +422,8 @@ int bond_create(struct net *net, const char *name);
int bond_create_sysfs(struct bond_net *net);
void bond_destroy_sysfs(struct bond_net *net);
void bond_prepare_sysfs_group(struct bonding *bond);
+int bond_sysfs_slave_add(struct slave *slave);
+void bond_sysfs_slave_del(struct slave *slave);
int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
int bond_xmit_hash(struct bonding *bond, struct sk_buff *skb, int count);
@@ -469,6 +472,7 @@ int bond_option_lacp_rate_set(struct bonding *bond, int lacp_rate);
int bond_option_ad_select_set(struct bonding *bond, int ad_select);
struct net_device *bond_option_active_slave_get_rcu(struct bonding *bond);
struct net_device *bond_option_active_slave_get(struct bonding *bond);
+const char *bond_slave_link_status(s8 link);
struct bond_net {
struct net * net; /* Associated network namespace */
^ permalink raw reply related
* [PATCH net-next 0/2] bonding: add slave netlink and sysfs support
From: Scott Feldman @ 2014-01-16 5:54 UTC (permalink / raw)
To: vfalico, fubar, andy; +Cc: netdev, roopa, shm
The following series adds bonding slave netlink and sysfs interfaces.
Slave interfaces get a new IFLA_SLAVE set of netlink attributes, along
with RTM_NEWLINK notification when slave's active status changes. The
sysfs interface adds read-only nodes for slave attributes under a /slave
dir, simliar to how bond interfaces get a /bonding dir for bonding
attributes.
---
Scott Feldman (2):
bonding: add sysfs /slave dir for bond slave devices.
bonding: add netlink attributes to slave link dev
drivers/net/bonding/Makefile | 2
drivers/net/bonding/bond_main.c | 28 ++++++
drivers/net/bonding/bond_netlink.c | 36 ++++++++
drivers/net/bonding/bond_procfs.c | 12 ---
drivers/net/bonding/bond_sysfs_slave.c | 142 ++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 15 +++
include/linux/netdevice.h | 5 +
include/uapi/linux/if_link.h | 13 +++
net/core/rtnetlink.c | 54 ++++++++++++
9 files changed, 292 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/bonding/bond_sysfs_slave.c
--
Signature
^ permalink raw reply
* Re: [PATCH net-next 0/6] bonding: only rely on arp packets if arp monitor is used
From: David Miller @ 2014-01-16 5:53 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy
In-Reply-To: <1389837916-5377-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Thu, 16 Jan 2014 03:05:10 +0100
> Currently, if arp_validate is off (0), slave_last_rx() returns the
> slave->dev->last_rx, which is always updated on *any* packet received by
> slave, and not only arps. This means that, if the validation of arps is
> off, we're treating *any* incoming packet as a proof of slave being up, and
> not only arps.
>
> This might seem logical at the first glance, however it can cause a lot of
> troubles and false-positives, one example would be:
>
> The arp_ip_target is NOT accessible, however someone in the broadcast domain
> spams with any broadcast traffic. This way bonding will be tricked that the
> slave is still up (as in - can access arp_ip_target), while it's not.
>
> The documentation for arp_validate also states that *ARPs* will (not) be
> validated if it's on/off, and that the arp monitoring works on arps as
> traffic generators.
>
> Also, the net_device->last_rx is already used in a lot of drivers (even
> though the comment states to NOT do it :)), and it's also ugly to modify it
> from bonding.
>
> So, to fix this, remove the last_rx from bonding, *always* call
> bond_arp_rcv() in slave's rx_handler (bond_handle_frame), and if we spot an
> arp there - update the slave->last_arp_rx - and use it instead of
> net_device->last_rx. Finally, rename slave_last_rx() to slave_last_arp_rx()
> to reflect the changes.
>
> As the changes touch really sensitive parts, I've tried to split them as
> much as possible, for easier debugging/bisecting.
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
This series looks really good, applied, thanks Veaceslav.
^ permalink raw reply
* Re: [net-next 0/2] Intel Wired LAN Driver Updates
From: David Miller @ 2014-01-16 5:49 UTC (permalink / raw)
To: aaron.f.brown; +Cc: netdev, gospo, sassmann
In-Reply-To: <1389836321-17013-1-git-send-email-aaron.f.brown@intel.com>
From: Aaron Brown <aaron.f.brown@intel.com>
Date: Wed, 15 Jan 2014 17:38:39 -0800
> This series contains several updates from Alex to ixgbe.
>
> To avoid head of line blocking in the event a VF stops cleaning Rx descriptors
> he makes sure QDE bits are set for a VF before the Rx queues are enabled.
>
> To avoid a situation where the head write-back registers can remain set ofter
> the driver is unloaded he clears them on a VF reset.
Series applied, thanks Aaron.
^ permalink raw reply
* Re: [PATCH net-next] tun/macvtap: limit the packets queued through rcvbuf
From: Michael S. Tsirkin @ 2014-01-16 5:47 UTC (permalink / raw)
To: Jason Wang
Cc: davem, netdev, linux-kernel, Vlad Yasevich, John Fastabend,
Stephen Hemminger, Herbert Xu
In-Reply-To: <52D7602F.8090800@redhat.com>
On Thu, Jan 16, 2014 at 12:29:35PM +0800, Jason Wang wrote:
> On 01/15/2014 03:21 PM, Michael S. Tsirkin wrote:
> >On Wed, Jan 15, 2014 at 11:36:01AM +0800, Jason Wang wrote:
> >>On 01/14/2014 05:52 PM, Michael S. Tsirkin wrote:
> >>>On Tue, Jan 14, 2014 at 04:45:24PM +0800, Jason Wang wrote:
> >>>>>On 01/14/2014 04:25 PM, Michael S. Tsirkin wrote:
> >>>>>>>On Tue, Jan 14, 2014 at 02:53:07PM +0800, Jason Wang wrote:
> >>>>>>>>>We used to limit the number of packets queued through tx_queue_length. This
> >>>>>>>>>has several issues:
> >>>>>>>>>
> >>>>>>>>>- tx_queue_length is the control of qdisc queue length, simply reusing it
> >>>>>>>>> to control the packets queued by device may cause confusion.
> >>>>>>>>>- After commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 ("macvtap: Add
> >>>>>>>>> support of packet capture on macvtap device."), an unexpected qdisc
> >>>>>>>>> caused by non-zero tx_queue_length will lead qdisc lock contention for
> >>>>>>>>> multiqueue deivce.
> >>>>>>>>>- What we really want is to limit the total amount of memory occupied not
> >>>>>>>>> the number of packets.
> >>>>>>>>>
> >>>>>>>>>So this patch tries to solve the above issues by using socket rcvbuf to
> >>>>>>>>>limit the packets could be queued for tun/macvtap. This was done by using
> >>>>>>>>>sock_queue_rcv_skb() instead of a direct call to skb_queue_tail(). Also two
> >>>>>>>>>new ioctl() were introduced for userspace to change the rcvbuf like what we
> >>>>>>>>>have done for sndbuf.
> >>>>>>>>>
> >>>>>>>>>With this fix, we can safely change the tx_queue_len of macvtap to
> >>>>>>>>>zero. This will make multiqueue works without extra lock contention.
> >>>>>>>>>
> >>>>>>>>>Cc: Vlad Yasevich<vyasevic@redhat.com>
> >>>>>>>>>Cc: Michael S. Tsirkin<mst@redhat.com>
> >>>>>>>>>Cc: John Fastabend<john.r.fastabend@intel.com>
> >>>>>>>>>Cc: Stephen Hemminger<stephen@networkplumber.org>
> >>>>>>>>>Cc: Herbert Xu<herbert@gondor.apana.org.au>
> >>>>>>>>>Signed-off-by: Jason Wang<jasowang@redhat.com>
> >>>>>>>No, I don't think we can change userspace-visible behaviour like that.
> >>>>>>>
> >>>>>>>This will break any existing user that tries to control
> >>>>>>>queue length through sysfs,netlink or device ioctl.
> >>>>>But it looks like a buggy API, since tx_queue_len should be for qdisc
> >>>>>queue length instead of device itself.
> >>>Probably, but it's been like this since 2.6.x time.
> >>>Also, qdisc queue is unused for tun so it seemed kind of
> >>>reasonable to override tx_queue_len.
> >>>
> >>>>>If we really want to preserve the
> >>>>>behaviour, how about using a new feature flag and change the behaviour
> >>>>>only when the device is created (TUNSETIFF) with the new flag?
> >>>OK this addresses the issue partially, but there's also an issue
> >>>of permissions: tx_queue_len can only be changed if
> >>>capable(CAP_NET_ADMIN). OTOH in your patch a regular user
> >>>can change the amount of memory consumed per queue
> >>>by calling TUNSETRCVBUF.
> >>Yes, but we have the same issue for TUNSETSNDBUF.
> >To an extent, but TUNSETSNDBUF is different. It limits how much device can queue
> >*in the networking stack* but each queue in the stack is also
> >limited, when we exceed that we star dropping packets.
> >So while with infinite value (which is the default btw)
> >you can keep host pretty busy, you will not be able to run
> >it out of memory.
> >
> >The proposed TUNSETRCVBUF would keep configured amount
> >of memory around indefinitely so you can run host out of memory.
> >
> >So assuming all this
> >How about an ethtool or netlink command to configure this
> >instead?
> >
>
> Ok, so we can add net admin check for before trying to set rcvbuf.
No, in practice I think using ioctl for sndbuf was also a mistake.
Applications have no idea what to set it to - you need to know what else
is running on the system, after a while
QEMU ended up setting it back to infinity otherwise things kept
breaking.
ethtool or netlink would not have this problem.
Which of the two is preferable I'm not sure.
I wonder what do management tools such as libvirt prefer.
> I
> think it's better to use ioctl since we've already use it for
> sndbuf. Using ethool means you need a dedicated new ethtool method
> just for tuntap which seems sub-optimal.
> Netlink looks better, but
> we should also implement other ioctl also.
I'm not sure what this last phrase means. Can you clarify pls?
> >>>>>>>Take a look at my patch in msg ID 20140109071721.GD19559@redhat.com
> >>>>>>>which gives one way to set tx_queue_len to zero without
> >>>>>>>breaking userspace.
> >>>>>If I read the patch correctly, it will make no way for the user who
> >>>>>really want to change the qdisc queue length for tun.
> >>>Why would this matter? As far as I can see qdisc queue is currently unused.
> >>>
> >>User may use qdisc to do port mirroring, bandwidth limitation, traffic
> >>prioritization or more for a VM. So we do have users and maybe more
> >>consider the case of vpn.
> >Well it's not used by default at least.
> >I remember that we discussed this previously actually.
> >
> >If all we want to do actually is utilize no_qdisc by default,
> >we can simply use Eric's patch:
> >
> >http://article.gmane.org/gmane.linux.kernel/1279597
> >
> >and a similar patch for macvtap.
> >I tried it at the time and it didn't seem to help performance
> >at all, but a lot has changed since, in particular I didn't
> >test mq.
> >
> >If you now have results showing how it's beneficial, pls post them.
> >
>
> I will have a test to see the difference.
^ permalink raw reply
* Re: [PATCH net-next 0/6] bonding: only rely on arp packets if arp monitor is used
From: Jay Vosburgh @ 2014-01-16 5:09 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev, Andy Gospodarek, David S. Miller
In-Reply-To: <1389837916-5377-1-git-send-email-vfalico@redhat.com>
Veaceslav Falico <vfalico@redhat.com> wrote:
>Currently, if arp_validate is off (0), slave_last_rx() returns the
>slave->dev->last_rx, which is always updated on *any* packet received by
>slave, and not only arps. This means that, if the validation of arps is
>off, we're treating *any* incoming packet as a proof of slave being up, and
>not only arps.
The "any incoming packet" part is intentional.
>This might seem logical at the first glance, however it can cause a lot of
>troubles and false-positives, one example would be:
>
>The arp_ip_target is NOT accessible, however someone in the broadcast domain
>spams with any broadcast traffic. This way bonding will be tricked that the
>slave is still up (as in - can access arp_ip_target), while it's not.
This type of situation is why arp_validate was added.
The specific situation was when multiple hosts using bonding
with the ARP monitor were set up behind a common gateway (in the same
Ethernet broadcast domain). The arp_ip_target is unreachable for
whatever reason. In that case, the various bonding instances on the
different hosts will each issue broadcast ARP requests, and (in the
absence of arp_validate) those requests would trick the other bonds into
believing that they are up.
I don't think this patch set will resolve that problem, since
you explicitly permit any incoming ARP to count.
>The documentation for arp_validate also states that *ARPs* will (not) be
>validated if it's on/off, and that the arp monitoring works on arps as
>traffic generators.
I wrote most of that text in the documentation, and the intent
was not to imply that only ARPs should count for "up-ness" even without
arp_validate enabled. The intent was to distinguish it from
"non-validate," in which any incoming traffic counted for "up-ness."
The main reason for preserving the non-validate behavior (any
traffic counts) is for the loadbalance (xor and rr) modes. In those
modes, the switch decides which slave receives the incoming traffic, and
so it's to our advantage to permit any incoming traffic to count for
"up-ness." The arp_validate option is not allowed in these modes
because it won't work.
With these changes, I suspect that the loadbalance ARP monitor
will be less reliable with these changes (granted that it's already a
bit dodgy in its dependence on the switch to hit all slaves with
incoming packets regularly). Particularly if the switch ports are
configured into an Etherchannel ("static link aggregation") group, in
which case only one slave will receive any given frame (broadcast /
multicast traffic will not be duplicated across all slaves).
I'm not sure that this change (the "only count ARPs even without
arp_validate" bit) won't break existing configurations. Did you test
the -rr and -xor modes with ARP monitor after your changes (with and
without configuring a channel group on the switch ports)?
>Also, the net_device->last_rx is already used in a lot of drivers (even
>though the comment states to NOT do it :)), and it's also ugly to modify it
>from bonding.
I didn't check, but I suspect those are mostly leftovers from
the distant past, when the drivers were expected to update last_rx, or
perhaps drivers using it for their own purposes.
I don't really see an issue in decoupling bonding from the
net_device->last_rx; it's pretty much the same thing that was done for
trans_start some time ago.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>So, to fix this, remove the last_rx from bonding, *always* call
>bond_arp_rcv() in slave's rx_handler (bond_handle_frame), and if we spot an
>arp there - update the slave->last_arp_rx - and use it instead of
>net_device->last_rx. Finally, rename slave_last_rx() to slave_last_arp_rx()
>to reflect the changes.
>
>As the changes touch really sensitive parts, I've tried to split them as
>much as possible, for easier debugging/bisecting.
>
>CC: Jay Vosburgh <fubar@us.ibm.com>
>CC: Andy Gospodarek <andy@greyhouse.net>
>CC: "David S. Miller" <davem@davemloft.net>
>CC: netdev@vger.kernel.org
>Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
>
>---
> drivers/net/bonding/bond_main.c | 18 ++++++++----------
> drivers/net/bonding/bond_options.c | 12 ++----------
> drivers/net/bonding/bonding.h | 16 ++++++----------
> include/linux/netdevice.h | 8 +-------
> 4 files changed, 17 insertions(+), 37 deletions(-)
>
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: Check skb->rxhash in gro_receive
From: Jerry Chu @ 2014-01-16 5:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David Miller, netdev@vger.kernel.org
In-Reply-To: <1389806708.31367.354.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Jan 15, 2014 at 9:25 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-01-15 at 08:58 -0800, Tom Herbert wrote:
>> When initializing a gro_list for a packet, first check the rxhash of
>> the incoming skb against that of the skb's in the list. This should be
>> a very strong inidicator of whether the flow is going to be matched,
>> and potentially allows a lot of other checks to be short circuited.
>> Use skb_hash_raw so that we don't force the hash to be calculated.
>>
>> Tested by running netperf 200 TCP_STREAMs between two machines with
>> GRO, HW rxhash, and 1G. Saw no performance degration, slight reduction
>> of time in dev_gro_receive.
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> net/core/dev.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 20c834e..c063c7c 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -3818,10 +3818,18 @@ static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
>> {
>> struct sk_buff *p;
>> unsigned int maclen = skb->dev->hard_header_len;
>> + u32 hash = skb_get_hash_raw(skb);
>>
>> for (p = napi->gro_list; p; p = p->next) {
>> unsigned long diffs;
>>
>> + NAPI_GRO_CB(p)->flush = 0;
>> +
>> + if (hash != skb_get_hash_raw(p)) {
>> + NAPI_GRO_CB(p)->same_flow = 0;
>> + continue;
>> + }
>> +
>> diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
>> diffs |= p->vlan_tci ^ skb->vlan_tci;
>> if (maclen == ETH_HLEN)
>> @@ -3832,7 +3840,6 @@ static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
>> skb_gro_mac_header(skb),
>> maclen);
>> NAPI_GRO_CB(p)->same_flow = !diffs;
>> - NAPI_GRO_CB(p)->flush = 0;
>> }
>> }
>>
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
> Hmm, this looks like we should clear flush_id in ipv6 handler,
> otherwise we might reuse a flush_id set from a prior gro invocation in
> ipv4 (skb can be reused in napi_reuse_skb())
Good catch! It's also needed for the IPv6 encaped in IPv4 case (i forgot
there is no frag/id hence no such check for IPv6).
>
> Jerry, what do you think of following fix ?
>
> diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
> index 1e8683b135bb..598acd76ca4a 100644
> --- a/net/ipv6/ip6_offload.c
> +++ b/net/ipv6/ip6_offload.c
> @@ -256,6 +256,7 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
> /* flush if Traffic Class fields are different */
> NAPI_GRO_CB(p)->flush |= !!(first_word & htonl(0x0FF00000));
> NAPI_GRO_CB(p)->flush |= flush;
> + NAPI_GRO_CB(p)->flush_id = 0;
> }
>
> NAPI_GRO_CB(skb)->flush |= flush;
Acked-by: H.K. Jerry Chu <hkchu@google.com>
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] tun/macvtap: limit the packets queued through rcvbuf
From: Jason Wang @ 2014-01-16 4:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: davem, netdev, linux-kernel, Vlad Yasevich, John Fastabend,
Stephen Hemminger, Herbert Xu
In-Reply-To: <20140115072104.GA32078@redhat.com>
On 01/15/2014 03:21 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 15, 2014 at 11:36:01AM +0800, Jason Wang wrote:
>> On 01/14/2014 05:52 PM, Michael S. Tsirkin wrote:
>>> On Tue, Jan 14, 2014 at 04:45:24PM +0800, Jason Wang wrote:
>>>>> On 01/14/2014 04:25 PM, Michael S. Tsirkin wrote:
>>>>>>> On Tue, Jan 14, 2014 at 02:53:07PM +0800, Jason Wang wrote:
>>>>>>>>> We used to limit the number of packets queued through tx_queue_length. This
>>>>>>>>> has several issues:
>>>>>>>>>
>>>>>>>>> - tx_queue_length is the control of qdisc queue length, simply reusing it
>>>>>>>>> to control the packets queued by device may cause confusion.
>>>>>>>>> - After commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 ("macvtap: Add
>>>>>>>>> support of packet capture on macvtap device."), an unexpected qdisc
>>>>>>>>> caused by non-zero tx_queue_length will lead qdisc lock contention for
>>>>>>>>> multiqueue deivce.
>>>>>>>>> - What we really want is to limit the total amount of memory occupied not
>>>>>>>>> the number of packets.
>>>>>>>>>
>>>>>>>>> So this patch tries to solve the above issues by using socket rcvbuf to
>>>>>>>>> limit the packets could be queued for tun/macvtap. This was done by using
>>>>>>>>> sock_queue_rcv_skb() instead of a direct call to skb_queue_tail(). Also two
>>>>>>>>> new ioctl() were introduced for userspace to change the rcvbuf like what we
>>>>>>>>> have done for sndbuf.
>>>>>>>>>
>>>>>>>>> With this fix, we can safely change the tx_queue_len of macvtap to
>>>>>>>>> zero. This will make multiqueue works without extra lock contention.
>>>>>>>>>
>>>>>>>>> Cc: Vlad Yasevich<vyasevic@redhat.com>
>>>>>>>>> Cc: Michael S. Tsirkin<mst@redhat.com>
>>>>>>>>> Cc: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>> Cc: Stephen Hemminger<stephen@networkplumber.org>
>>>>>>>>> Cc: Herbert Xu<herbert@gondor.apana.org.au>
>>>>>>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>>>>>> No, I don't think we can change userspace-visible behaviour like that.
>>>>>>>
>>>>>>> This will break any existing user that tries to control
>>>>>>> queue length through sysfs,netlink or device ioctl.
>>>>> But it looks like a buggy API, since tx_queue_len should be for qdisc
>>>>> queue length instead of device itself.
>>> Probably, but it's been like this since 2.6.x time.
>>> Also, qdisc queue is unused for tun so it seemed kind of
>>> reasonable to override tx_queue_len.
>>>
>>>>> If we really want to preserve the
>>>>> behaviour, how about using a new feature flag and change the behaviour
>>>>> only when the device is created (TUNSETIFF) with the new flag?
>>> OK this addresses the issue partially, but there's also an issue
>>> of permissions: tx_queue_len can only be changed if
>>> capable(CAP_NET_ADMIN). OTOH in your patch a regular user
>>> can change the amount of memory consumed per queue
>>> by calling TUNSETRCVBUF.
>> Yes, but we have the same issue for TUNSETSNDBUF.
> To an extent, but TUNSETSNDBUF is different. It limits how much device can queue
> *in the networking stack* but each queue in the stack is also
> limited, when we exceed that we star dropping packets.
> So while with infinite value (which is the default btw)
> you can keep host pretty busy, you will not be able to run
> it out of memory.
>
> The proposed TUNSETRCVBUF would keep configured amount
> of memory around indefinitely so you can run host out of memory.
>
> So assuming all this
> How about an ethtool or netlink command to configure this
> instead?
>
Ok, so we can add net admin check for before trying to set rcvbuf. I
think it's better to use ioctl since we've already use it for sndbuf.
Using ethool means you need a dedicated new ethtool method just for
tuntap which seems sub-optimal. Netlink looks better, but we should also
implement other ioctl also.
>>>>>>> Take a look at my patch in msg ID 20140109071721.GD19559@redhat.com
>>>>>>> which gives one way to set tx_queue_len to zero without
>>>>>>> breaking userspace.
>>>>> If I read the patch correctly, it will make no way for the user who
>>>>> really want to change the qdisc queue length for tun.
>>> Why would this matter? As far as I can see qdisc queue is currently unused.
>>>
>> User may use qdisc to do port mirroring, bandwidth limitation, traffic
>> prioritization or more for a VM. So we do have users and maybe more
>> consider the case of vpn.
> Well it's not used by default at least.
> I remember that we discussed this previously actually.
>
> If all we want to do actually is utilize no_qdisc by default,
> we can simply use Eric's patch:
>
> http://article.gmane.org/gmane.linux.kernel/1279597
>
> and a similar patch for macvtap.
> I tried it at the time and it didn't seem to help performance
> at all, but a lot has changed since, in particular I didn't
> test mq.
>
> If you now have results showing how it's beneficial, pls post them.
>
I will have a test to see the difference.
^ permalink raw reply
* [PATCH 2/2 Net-next] ixgbe: set driver_max_VFs should be done before enabling SRIOV
From: ethan zhao @ 2014-01-16 4:27 UTC (permalink / raw)
To: aaron.f.brown, jeffrey.t.kirsher
Cc: e1000-devel, netdev, ethan.kernel, linux-kernel
commit 43dc4e01 Limit number of reported VFs to device specific value
It doesn't work and always returns -EBUSY because VFs ware already enabled.
ixgbe_enable_sriov()
pci_enable_sriov()
sriov_enable()
{
... ..
iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE;
pci_cfg_access_lock(dev);
... ...
}
pci_sriov_set_totalvfs()
{
... ...
if (dev->sriov->ctrl & PCI_SRIOV_CTRL_VFE)
return -EBUSY;
...
}
So should set driver_max_VFs with pci_sriov_set_totalvfs() before
enable VFs with ixgbe_enable_sriov().
V2: revised for net-next tree.
Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
Signed-off-by: Ethan Zhao <ethan.kernel@gmail.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index bea2cec..6e6af0d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7972,8 +7972,8 @@ static int ixgbe_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
/* Mailbox */
ixgbe_init_mbx_params_pf(hw);
memcpy(&hw->mbx.ops, ii->mbx_ops, sizeof(hw->mbx.ops));
- ixgbe_enable_sriov(adapter);
pci_sriov_set_totalvfs(pdev, IXGBE_MAX_VFS_DRV_LIMIT);
+ ixgbe_enable_sriov(adapter);
skip_sriov:
#endif
--
1.7.1
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
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 1/2 Net-next] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
From: ethan zhao @ 2014-01-16 4:25 UTC (permalink / raw)
To: aaron.f.brown, jeffrey.t.kirsher
Cc: e1000-devel, netdev, ethan.kernel, linux-kernel
Because ixgbe driver limit the max number of VF functions could be enalbed
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
v3: revised for net-next tree.
Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
Signed-off-by: Ethan Zhao <ethan.kernel@gmail.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 +++++
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cc06854..bea2cec 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5028,7 +5028,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter
*adapter)
/* assign number of SR-IOV VFs */
if (hw->mac.type != ixgbe_mac_82598EB) {
- if (max_vfs > 63) {
+ if (max_vfs > IXGBE_MAX_VFS_DRV_LIMIT) {
adapter->num_vfs = 0;
e_dev_warn("max_vfs parameter out of range. Not assigning
any SR-IOV VFs\n");
} else {
@@ -7973,7 +7973,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
ixgbe_init_mbx_params_pf(hw);
memcpy(&hw->mbx.ops, ii->mbx_ops, sizeof(hw->mbx.ops));
ixgbe_enable_sriov(adapter);
- pci_sriov_set_totalvfs(pdev, 63);
+ pci_sriov_set_totalvfs(pdev, IXGBE_MAX_VFS_DRV_LIMIT);
skip_sriov:
#endif
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 359f6e6..b324260 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -148,7 +148,7 @@ void ixgbe_enable_sriov(struct ixgbe_adapter *adapter)
* physical function. If the user requests greater thn
* 63 VFs then it is an error - reset to default of zero.
*/
- adapter->num_vfs = min_t(unsigned int, adapter->num_vfs, 63);
+ adapter->num_vfs = min_t(unsigned int, adapter->num_vfs,
IXGBE_MAX_VFS_DRV_LIMIT);
err = pci_enable_sriov(adapter->pdev, adapter->num_vfs);
if (err) {
@@ -257,7 +257,7 @@ static int ixgbe_pci_sriov_enable(struct pci_dev
*dev, int num_vfs)
* PF. The PCI bus driver already checks for other values out of
* range.
*/
- if (num_vfs > 63) {
+ if (num_vfs > IXGBE_MAX_VFS_DRV_LIMIT) {
err = -EPERM;
goto err_out;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
index 4713f9f..8bd2919 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h
@@ -28,6 +28,11 @@
#ifndef _IXGBE_SRIOV_H_
#define _IXGBE_SRIOV_H_
+/* ixgbe driver limit the max number of VFs could be enabled to
+ * 63 (IXGBE_MAX_VF_FUNCTIONS - 1)
+ */
+#define IXGBE_MAX_VFS_DRV_LIMIT (IXGBE_MAX_VF_FUNCTIONS - 1)
+
void ixgbe_restore_vf_multicasts(struct ixgbe_adapter *adapter);
void ixgbe_msg_task(struct ixgbe_adapter *adapter);
int ixgbe_vf_configuration(struct pci_dev *pdev, unsigned int event_mask);
--
1.7.1
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
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
* Re: [PATCH net-next RFC] virtio-net: drop rq->max and rq->num
From: Jason Wang @ 2014-01-16 4:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <20140115.164649.533508366980529205.davem@davemloft.net>
On 01/16/2014 08:46 AM, David Miller wrote:
> From: Rusty Russell<rusty@rustcorp.com.au>
> Date: Thu, 16 Jan 2014 10:25:26 +1030
>
>> Rusty Russell<rusty@rustcorp.com.au> writes:
>>> Jason Wang<jasowang@redhat.com> writes:
>>>> It looks like there's no need for those two fields:
>>>>
>>>> - Unless there's a failure for the first refill try, rq->max should be always
>>>> equal to the vring size.
>>>> - rq->num is only used to determine the condition that we need to do the refill,
>>>> we could check vq->num_free instead.
>>>> - rq->num was required to be increased or decreased explicitly after each
>>>> get/put which results a bad API.
>>>>
>>>> So this patch removes them both to make the code simpler.
>>> Nice. These fields date from when the vq struct was opaque.
>>>
>>> Applied,
>>> Rusty.
>> Oops, this doesn't require any core virtio changes, so it's for DaveM:
>>
>> Acked-by: Rusty Russell<rusty@rustcorp.com.au>
> Jason please repost this with Rusty's ACK, thanks.
Sure, will repost.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/3] virtio_net: add aRFS support
From: Jason Wang @ 2014-01-16 4:23 UTC (permalink / raw)
To: Zhi Yong Wu; +Cc: netdev, therbert, edumazet, davem, Zhi Yong Wu
In-Reply-To: <1389795654-28381-1-git-send-email-zwu.kernel@gmail.com>
On 01/15/2014 10:20 PM, Zhi Yong Wu wrote:
> From: Zhi Yong Wu<wuzhy@linux.vnet.ibm.com>
>
> HI, folks
>
> The patchset is trying to integrate aRFS support to virtio_net. In this case,
> aRFS will be used to select the RX queue. To make sure that it's going ahead
> in the correct direction, although it is still one RFC and isn't tested, it's
> post out ASAP. Any comment are appreciated, thanks.
>
> If anyone is interested in playing with it, you can get this patchset from my
> dev git on github:
> git://github.com/wuzhy/kernel.git virtnet_rfs
>
> Zhi Yong Wu (3):
> virtio_pci: Introduce one new config api vp_get_vq_irq()
> virtio_net: Introduce one dummy function virtnet_filter_rfs()
> virtio-net: Add accelerated RFS support
>
> drivers/net/virtio_net.c | 67 ++++++++++++++++++++++++++++++++++++++++-
> drivers/virtio/virtio_pci.c | 11 +++++++
> include/linux/virtio_config.h | 12 +++++++
> 3 files changed, 89 insertions(+), 1 deletions(-)
>
Please run get_maintainter.pl before sending the patch. You'd better at
least cc virtio maintainer/list for this.
The core aRFS method is a noop in this RFC which make this series no
much sense to discuss. You should at least mention the big picture here
in the cover letter. I suggest you should post a RFC which can run and
has expected result or you can just raise a thread for the design
discussion.
And this method has been discussed before, you can search "[net-next RFC
PATCH 5/5] virtio-net: flow director support" in netdev archive for a
very old prototype implemented by me. It can work and looks like most of
this RFC have already done there.
A basic question is whether or not we need this, not all the mq cards
use aRFS (see ixgbe ATR). And whether or not it can bring extra
overheads? For virtio, we want to reduce the vmexits as much as possible
but this aRFS seems introduce a lot of more of this. Making a complex
interfaces just for an virtual device may not be good, simple method may
works for most of the cases.
We really should consider to offload this to real nic. VMDq and L2
forwarding offload may help in this case.
^ permalink raw reply
* Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
From: Ethan Zhao @ 2014-01-16 4:20 UTC (permalink / raw)
To: Brown, Aaron F
Cc: ethan zhao, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Allan, Bruce W, Brandeburg, Jesse,
linux-kernel@vger.kernel.org, davem@davemloft.net
In-Reply-To: <CABawtvPJ1ObkwbKjVtzajQnn_181CTo-jmLc0uGY2nqZw9_jtg@mail.gmail.com>
Aaron,
Revised those patches for Dave Miller's net-next OK, passed
building. resent.
Thanks,
Ethan
On Thu, Jan 16, 2014 at 11:08 AM, Ethan Zhao <ethan.kernel@gmail.com> wrote:
> Aaron,
> Ok, Dave Miler's net-next tree.
>
> Thanks,
> Etan
>
> On Thu, Jan 16, 2014 at 10:51 AM, Brown, Aaron F
> <aaron.f.brown@intel.com> wrote:
>> On Thu, 2014-01-16 at 09:58 +0800, Ethan Zhao wrote:
>>> Aaron,
>>>
>>> Is this your net-next repo ? if so, I rebuild the patch with this repo
>>> right now .
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>>>
>>> Thanks,
>>> Ethan
>>>
>> Only sort of. Jeff uses it to push patches up, but I don't have an
>> account there so am simply sending them up the old fashioned way, via
>> email, hence it is probably not getting updated while Jeff is out.
>>
>> As long as your patch can apply cleanly to Dave Miller's net-next tree I
>> should be able to pull it into our internal ones.
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
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
* Re: [PATCH iproute2 v2 2/2] netem: add 64bit rates support
From: Eric Dumazet @ 2014-01-16 3:17 UTC (permalink / raw)
To: Yang Yingliang; +Cc: stephen, netdev
In-Reply-To: <1389841754-22008-3-git-send-email-yangyingliang@huawei.com>
On Thu, 2014-01-16 at 11:09 +0800, Yang Yingliang wrote:
> netem support 64bit rates start from linux-3.13.
> Add 64bit rates support in tc tools.
>
> tc qdisc show dev eth0
> qdisc netem 1: dev eth4 root refcnt 2 limit 1000 rate 35Gbit
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
> tc/q_netem.c | 29 ++++++++++++++++++++++++-----
> 1 file changed, 24 insertions(+), 5 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] random32: add prandom_u32_lt_N and convert "misuses" of reciprocal_divide
From: Eric Dumazet @ 2014-01-16 3:14 UTC (permalink / raw)
To: Daniel Borkmann
Cc: davem, netdev, linux-kernel, Jakub Zawadzki, Hannes Frederic Sowa
In-Reply-To: <1389828228-30312-2-git-send-email-dborkman@redhat.com>
On Thu, 2014-01-16 at 00:23 +0100, Daniel Borkmann wrote:
> @@ -1220,7 +1219,7 @@ static unsigned int fanout_demux_hash(struct packet_fanout *f,
> struct sk_buff *skb,
> unsigned int num)
> {
> - return reciprocal_divide(skb->rxhash, num);
> + return (u32)(((u64) skb->rxhash * num) >> 32);
> }
>
This is unfortunate.
(This reverts one of your patch : f55d112e529386 )
Please add a helper to explain what's going on here, and on many other
spots we do this computation (as in get_rps_cpu()).
Few people really understand this.
Or keep reciprocal_divide() as is, and introduce a new set of functions
for people really wanting the precise divides.
^ permalink raw reply
* [PATCH iproute2 v2 0/2] two improvements in tc
From: Yang Yingliang @ 2014-01-16 3:09 UTC (permalink / raw)
To: stephen; +Cc: netdev, eric.dumazet
Support sending burst/mtu to kernel directly in tbf.
Support 64bit rate in netem.
v1 -> v2:
patch 2/2: Use rta_getattr_u64() to get value of rate64.
Yang Yingliang (2):
tbf: support sending burst/mtu to kernel directly
netem: add 64bit rates support
tc/q_netem.c | 29 ++++++++++++++++++++++++-----
tc/q_tbf.c | 2 ++
2 files changed, 26 insertions(+), 5 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH iproute2 v2 1/2] tbf: support sending burst/mtu to kernel directly
From: Yang Yingliang @ 2014-01-16 3:09 UTC (permalink / raw)
To: stephen; +Cc: netdev, eric.dumazet
In-Reply-To: <1389841754-22008-1-git-send-email-yangyingliang@huawei.com>
To avoid loss when transforming burst to buffer in userspace, send
burst/mtu to kernel directly.
Kernel commit 2e04ad424b("sch_tbf: add TBF_BURST/TBF_PBURST attribute")
make it can handle burst/mtu.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
tc/q_tbf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tc/q_tbf.c b/tc/q_tbf.c
index 2fbfd3b..f3022b6 100644
--- a/tc/q_tbf.c
+++ b/tc/q_tbf.c
@@ -232,12 +232,14 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
tail = NLMSG_TAIL(n);
addattr_l(n, 1024, TCA_OPTIONS, NULL, 0);
addattr_l(n, 2024, TCA_TBF_PARMS, &opt, sizeof(opt));
+ addattr_l(n, 2124, TCA_TBF_BURST, &buffer, sizeof(buffer));
if (rate64 >= (1ULL << 32))
addattr_l(n, 2124, TCA_TBF_RATE64, &rate64, sizeof(rate64));
addattr_l(n, 3024, TCA_TBF_RTAB, rtab, 1024);
if (opt.peakrate.rate) {
if (prate64 >= (1ULL << 32))
addattr_l(n, 3124, TCA_TBF_PRATE64, &prate64, sizeof(prate64));
+ addattr_l(n, 3224, TCA_TBF_PBURST, &mtu, sizeof(mtu));
addattr_l(n, 4096, TCA_TBF_PTAB, ptab, 1024);
}
tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
--
1.8.0
^ permalink raw reply related
* [PATCH iproute2 v2 2/2] netem: add 64bit rates support
From: Yang Yingliang @ 2014-01-16 3:09 UTC (permalink / raw)
To: stephen; +Cc: netdev, eric.dumazet
In-Reply-To: <1389841754-22008-1-git-send-email-yangyingliang@huawei.com>
netem support 64bit rates start from linux-3.13.
Add 64bit rates support in tc tools.
tc qdisc show dev eth0
qdisc netem 1: dev eth4 root refcnt 2 limit 1000 rate 35Gbit
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
tc/q_netem.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/tc/q_netem.c b/tc/q_netem.c
index 9dd8712..946007c 100644
--- a/tc/q_netem.c
+++ b/tc/q_netem.c
@@ -183,6 +183,7 @@ static int netem_parse_opt(struct qdisc_util *qu, int argc, char **argv,
__s16 *dist_data = NULL;
__u16 loss_type = NETEM_LOSS_UNSPEC;
int present[__TCA_NETEM_MAX];
+ __u64 rate64 = 0;
memset(&cor, 0, sizeof(cor));
memset(&reorder, 0, sizeof(reorder));
@@ -391,7 +392,7 @@ static int netem_parse_opt(struct qdisc_util *qu, int argc, char **argv,
} else if (matches(*argv, "rate") == 0) {
++present[TCA_NETEM_RATE];
NEXT_ARG();
- if (get_rate(&rate.rate, *argv)) {
+ if (get_rate64(&rate64, *argv)) {
explain1("rate");
return -1;
}
@@ -496,9 +497,18 @@ static int netem_parse_opt(struct qdisc_util *qu, int argc, char **argv,
addattr_nest_end(n, start);
}
- if (present[TCA_NETEM_RATE] &&
- addattr_l(n, 1024, TCA_NETEM_RATE, &rate, sizeof(rate)) < 0)
- return -1;
+ if (present[TCA_NETEM_RATE]) {
+ if (rate64 >= (1ULL << 32)) {
+ if (addattr_l(n, 1024,
+ TCA_NETEM_RATE64, &rate64, sizeof(rate64)) < 0)
+ return -1;
+ rate.rate = ~0U;
+ } else {
+ rate.rate = rate64;
+ }
+ if (addattr_l(n, 1024, TCA_NETEM_RATE, &rate, sizeof(rate)) < 0)
+ return -1;
+ }
if (dist_data) {
if (addattr_l(n, MAX_DIST * sizeof(dist_data[0]),
@@ -522,6 +532,7 @@ static int netem_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
struct tc_netem_qopt qopt;
const struct tc_netem_rate *rate = NULL;
int len = RTA_PAYLOAD(opt) - sizeof(qopt);
+ __u64 rate64 = 0;
SPRINT_BUF(b1);
if (opt == NULL)
@@ -572,6 +583,11 @@ static int netem_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
return -1;
ecn = RTA_DATA(tb[TCA_NETEM_ECN]);
}
+ if (tb[TCA_NETEM_RATE64]) {
+ if (RTA_PAYLOAD(tb[TCA_NETEM_RATE64]) < sizeof(rate64))
+ return -1;
+ rate64 = rta_getattr_u64(tb[TCA_NETEM_RATE64]);
+ }
}
fprintf(f, "limit %d", qopt.limit);
@@ -632,7 +648,10 @@ static int netem_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
}
if (rate && rate->rate) {
- fprintf(f, " rate %s", sprint_rate(rate->rate, b1));
+ if (rate64)
+ fprintf(f, " rate %s", sprint_rate(rate64, b1));
+ else
+ fprintf(f, " rate %s", sprint_rate(rate->rate, b1));
if (rate->packet_overhead)
fprintf(f, " packetoverhead %d", rate->packet_overhead);
if (rate->cell_size)
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
From: Ethan Zhao @ 2014-01-16 3:08 UTC (permalink / raw)
To: Brown, Aaron F
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, Allan, Bruce W,
Wyborny, Carolyn, davem@davemloft.net,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <309B89C4C689E141A5FF6A0C5FB2118B7312DF41@ORSMSX101.amr.corp.intel.com>
Aaron,
Ok, Dave Miler's net-next tree.
Thanks,
Etan
On Thu, Jan 16, 2014 at 10:51 AM, Brown, Aaron F
<aaron.f.brown@intel.com> wrote:
> On Thu, 2014-01-16 at 09:58 +0800, Ethan Zhao wrote:
>> Aaron,
>>
>> Is this your net-next repo ? if so, I rebuild the patch with this repo
>> right now .
>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>>
>> Thanks,
>> Ethan
>>
> Only sort of. Jeff uses it to push patches up, but I don't have an
> account there so am simply sending them up the old fashioned way, via
> email, hence it is probably not getting updated while Jeff is out.
>
> As long as your patch can apply cleanly to Dave Miller's net-next tree I
> should be able to pull it into our internal ones.
^ permalink raw reply
* Re: [PATCH net-next 2/2] reciprocal_divide: correction/update of the algorithm
From: Eric Dumazet @ 2014-01-16 3:07 UTC (permalink / raw)
To: Daniel Borkmann
Cc: davem, netdev, linux-kernel, Hannes Frederic Sowa,
Austin S Hemmelgarn, Jesse Gross, Jamal Hadi Salim,
Stephen Hemminger, Matt Mackall, Pekka Enberg, Christoph Lameter,
Andy Gospodarek, Veaceslav Falico, Jay Vosburgh, Jakub Zawadzki
In-Reply-To: <1389828228-30312-3-git-send-email-dborkman@redhat.com>
On Thu, 2014-01-16 at 00:23 +0100, Daniel Borkmann wrote:
> Also, reciprocal_value() and reciprocal_divide() always return 0
> for divisions by 1. This is a bit worrisome as those functions
> also get used in mm/slab.c and lib/flex_array.c, apparently for
> index calculation to access array slots.
Hi Daniel
This off-by-one limitation is a known one,
and mm/slab.c does not have an issue with it because :
- Minimal object size is not 1 byte, but 8 (or maybe 4)
- We always divide a multiple of the divisor,
so there is no off-by-one effect.
Little attached prog does a brute force check if needed.
So far, the only relevant issue was about BPF, and a better
documentation of reciprocal_divide() use cases.
(I let Jesse comment on the flex_array case)
I am unsure we want to 'fix' things, we tried hard in the past to avoid
divides, so the ones we use are usually because the divisor is not
constant, so the reciprocal doesn't help.
(BPF is fixed in David tree)
Thanks !
#include <stdio.h>
typedef unsigned int u32;
typedef unsigned long long u64;
static u32 reciprocal_value(u32 k)
{
u64 val = (1LL << 32) + (k - 1);
val /= k;
return (u32)val;
}
static inline u32 reciprocal_divide(u32 A, u32 R)
{
return (u32)(((u64)A * R) >> 32);
}
#define LIMIT 1000*1000*1000
int main()
{
u32 divisor, dividend, reciprocal, next;
int res = 0;
for (divisor = 2; divisor < LIMIT; divisor++) {
reciprocal = reciprocal_value(divisor);
for (dividend = 0; ; dividend = next) {
if (reciprocal_divide(dividend, reciprocal) != (dividend / divisor)) {
printf("Arg: %u/%u was not properly computed (%u/%u)\n",
dividend, divisor,
reciprocal_divide(dividend, reciprocal),
dividend / divisor);
res = 1;
break;
}
next = dividend + divisor;
if (next < dividend)
break;
}
}
return res;
}
^ permalink raw reply
* Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
From: Brown, Aaron F @ 2014-01-16 2:51 UTC (permalink / raw)
To: ethan.kernel@gmail.com
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Allan, Bruce W, Brandeburg, Jesse, linux-kernel@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <CABawtvNSpDU+pjdJOpCB8kyQqA7B9N4g0S_yPgQaZnB3h0+nFg@mail.gmail.com>
On Thu, 2014-01-16 at 09:58 +0800, Ethan Zhao wrote:
> Aaron,
>
> Is this your net-next repo ? if so, I rebuild the patch with this repo
> right now .
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>
> Thanks,
> Ethan
>
Only sort of. Jeff uses it to push patches up, but I don't have an
account there so am simply sending them up the old fashioned way, via
email, hence it is probably not getting updated while Jeff is out.
As long as your patch can apply cleanly to Dave Miller's net-next tree I
should be able to pull it into our internal ones.
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
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
* Re: [RFC PATCH net-next 2/3] virtio_net: Introduce one dummy function virtnet_filter_rfs()
From: Zhi Yong Wu @ 2014-01-16 2:45 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List, Eric Dumazet, David Miller, Zhi Yong Wu
In-Reply-To: <CA+mtBx8Z80d5Y1ti0_68UA-x0hZPeqT4wa9knevWoPxX+eyaVA@mail.gmail.com>
On Thu, Jan 16, 2014 at 1:54 AM, Tom Herbert <therbert@google.com> wrote:
> Zhi, this is promising work! I can't wait to see how this impacts
"Zhi" is part of my first name, you call me "Zhi Yong".
> network virtualization performance :-)
heh, too much work is missing.
>
> On Wed, Jan 15, 2014 at 6:20 AM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>>
>> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>> ---
>> drivers/net/virtio_net.c | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 7b17240..046421c 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1295,6 +1295,14 @@ static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_RFS_ACCEL
>> +static int virtnet_filter_rfs(struct net_device *net_dev,
>> + const struct sk_buff *skb, u16 rxq_index, u32 flow_id)
>> +{
> Does this need to be filled out with more stuff?
Yes, the following stuff are missing:
1.) guest virtio_net driver should have one filter table and its
entries can be expired periodically;
2.) guest virtio_net driver should pass rx queue index and filter
info down to the emulated virtio_net NIC in QEMU.
3.) the emulated virtio_net NIC should have its indirect table to
store the flow to rx queue mapping.
4.) the emulated virtio_net NIC should classify the rx packet to
selected queue by applying the filter.
5.) update virtio spec.
Do i miss anything? If yes, please correct me.
For 3.) and 4.), do you have any doc about how they are implemented in
physical NICs? e.g. mlx4_en or sfc, etc.
>
>> + return 0;
>> +}
>> +#endif /* CONFIG_RFS_ACCEL */
>> +
>> static const struct net_device_ops virtnet_netdev = {
>> .ndo_open = virtnet_open,
>> .ndo_stop = virtnet_close,
>> @@ -1309,6 +1317,9 @@ static const struct net_device_ops virtnet_netdev = {
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> .ndo_poll_controller = virtnet_netpoll,
>> #endif
>> +#ifdef CONFIG_RFS_ACCEL
>> + .ndo_rx_flow_steer = virtnet_filter_rfs,
>> +#endif
>> };
>>
>> static void virtnet_config_changed_work(struct work_struct *work)
>> --
>> 1.7.6.5
>>
--
Regards,
Zhi Yong Wu
^ permalink raw reply
* [PATCH v6 4/4] ARM: shmobile: genmai: Enable r7s72100-ether
From: Simon Horman @ 2014-01-16 2:34 UTC (permalink / raw)
To: David S. Miller, netdev, linux-sh
Cc: linux-arm-kernel, Magnus Damm, Sergei Shtylyov, Joe Perches,
Simon Horman, Simon Horman
In-Reply-To: <1389839656-10932-1-git-send-email-horms+renesas@verge.net.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Dave, I intend to take this change through my tree
v3 - v6
* No change
v2
* As suggested by Magnus Damm and Sergei Shtylyov
- r7s72100 ethernet is not gigabit so do not refer to it as such
* As suggested by Sergei Shtylyov
- set no_ether_link as there is no LINK signal documented
in the manual
---
arch/arm/mach-shmobile/board-genmai.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c
index 3e92e3c..a1f6fe1 100644
--- a/arch/arm/mach-shmobile/board-genmai.c
+++ b/arch/arm/mach-shmobile/board-genmai.c
@@ -20,15 +20,36 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
+#include <linux/sh_eth.h>
#include <mach/common.h>
+#include <mach/irqs.h>
#include <mach/r7s72100.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+/* Ether */
+static const struct sh_eth_plat_data ether_pdata __initconst = {
+ .phy = 0x00, /* PD60610 */
+ .edmac_endian = EDMAC_LITTLE_ENDIAN,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+ .no_ether_link = 1
+};
+
+static const struct resource ether_resources[] __initconst = {
+ DEFINE_RES_MEM(0xe8203000, 0x800),
+ DEFINE_RES_MEM(0xe8204800, 0x200),
+ DEFINE_RES_IRQ(gic_iid(359)),
+};
+
static void __init genmai_add_standard_devices(void)
{
r7s72100_clock_init();
r7s72100_add_dt_devices();
+
+ platform_device_register_resndata(&platform_bus, "r7s72100-ether", -1,
+ ether_resources,
+ ARRAY_SIZE(ether_resources),
+ ðer_pdata, sizeof(ether_pdata));
}
static const char * const genmai_boards_compat_dt[] __initconst = {
--
1.8.4
^ permalink raw reply related
* [PATCH v6 0/4] Add ethernet support for r7s72100
From: Simon Horman @ 2014-01-16 2:34 UTC (permalink / raw)
To: David S. Miller, netdev, linux-sh
Cc: linux-arm-kernel, Magnus Damm, Sergei Shtylyov, Joe Perches,
Simon Horman
Hi,
this series adds ethernet support to sh-pfc for the r7s72100 SoC.
This series is based on a merge of:
* The topic/r7s72100-v3.13-rc8-20140115 tag in my renesas tree
* net-next
- Head revision: 08c93cd99b2f31ba9
("Merge branch 'for-davem' of git://gitorious.org/linux-can/linux-can-next")
The first two patches, targeted at net-next, also applies cleanly there.
Changes since v5
* Address feedback from Joe Perches and Sergei Shtylyov as detailed
in the changelogs of:
- sh_eth: Use bool as return type of sh_eth_is_gether()
- sh_eth: Add support for r7s72100
Changes since v4
* Addressed feedback from Sergei Shtylyov as detailed in the changelog
of "sh_eth: Add support for r7s72100"
* Rebase
Changes since v3
* Use bool as return type of sh_eth_is_gether()
and sh_eth_is_rz_fast_ether()
* Correct coding style in sh_eth_get_stats()
Changes since v2
* Trivial rebase
* Dropped "RFC" from subject
Changes since v1 are noted in the changelog of each patch.
Simon Horman (4):
sh_eth: Use bool as return type of sh_eth_is_gether()
sh_eth: Add support for r7s72100
ARM: shmobile: r7s72100: Add clock for r7s72100-ether
ARM: shmobile: genmai: Enable r7s72100-ether
arch/arm/mach-shmobile/board-genmai.c | 21 +++++
arch/arm/mach-shmobile/clock-r7s72100.c | 4 +
drivers/net/ethernet/renesas/sh_eth.c | 131 +++++++++++++++++++++++++++++---
drivers/net/ethernet/renesas/sh_eth.h | 3 +-
4 files changed, 146 insertions(+), 13 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH v6 net-next 1/4] sh_eth: Use bool as return type of sh_eth_is_gether()
From: Simon Horman @ 2014-01-16 2:34 UTC (permalink / raw)
To: David S. Miller, netdev, linux-sh
Cc: linux-arm-kernel, Magnus Damm, Sergei Shtylyov, Joe Perches,
Simon Horman
In-Reply-To: <1389839656-10932-1-git-send-email-horms+renesas@verge.net.au>
Return a boolean and use true and false.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Dave, please consider this for net-next.
v6
* Simplify logic as suggested by Joe Perches
v5
* No change
v4
* First post
---
drivers/net/ethernet/renesas/sh_eth.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index ba1f6c9..f12a929 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -310,12 +310,9 @@ static const u16 sh_eth_offset_fast_sh3_sh2[SH_ETH_MAX_REGISTER_OFFSET] = {
[TSU_ADRL31] = 0x01fc,
};
-static int sh_eth_is_gether(struct sh_eth_private *mdp)
+static bool sh_eth_is_gether(struct sh_eth_private *mdp)
{
- if (mdp->reg_offset == sh_eth_offset_gigabit)
- return 1;
- else
- return 0;
+ return mdp->reg_offset == sh_eth_offset_gigabit;
}
static void sh_eth_select_mii(struct net_device *ndev)
--
1.8.4
^ 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