* [net-next 01/12] ixgbe: remove ntuple filtering
From: Jeff Kirsher @ 2011-06-23 1:44 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, Jeff Kirsher
In-Reply-To: <1308793476-11596-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Due to numerous issues in ntuple filters it has been decided to move the
interface over to the network flow classification interface. As a first
step to achieving this I first need to remove the old ntuple interface.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 136 -------------------------------------
1 files changed, 0 insertions(+), 136 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 4950d03..e41dd24 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -2336,141 +2336,6 @@ static int ixgbe_set_flags(struct net_device *netdev, u32 data)
return 0;
}
-static int ixgbe_set_rx_ntuple(struct net_device *dev,
- struct ethtool_rx_ntuple *cmd)
-{
- struct ixgbe_adapter *adapter = netdev_priv(dev);
- struct ethtool_rx_ntuple_flow_spec *fs = &cmd->fs;
- union ixgbe_atr_input input_struct;
- struct ixgbe_atr_input_masks input_masks;
- int target_queue;
- int err;
-
- if (adapter->hw.mac.type == ixgbe_mac_82598EB)
- return -EOPNOTSUPP;
-
- /*
- * Don't allow programming if the action is a queue greater than
- * the number of online Tx queues.
- */
- if ((fs->action >= adapter->num_tx_queues) ||
- (fs->action < ETHTOOL_RXNTUPLE_ACTION_DROP))
- return -EINVAL;
-
- memset(&input_struct, 0, sizeof(union ixgbe_atr_input));
- memset(&input_masks, 0, sizeof(struct ixgbe_atr_input_masks));
-
- /* record flow type */
- switch (fs->flow_type) {
- case IPV4_FLOW:
- input_struct.formatted.flow_type = IXGBE_ATR_FLOW_TYPE_IPV4;
- break;
- case TCP_V4_FLOW:
- input_struct.formatted.flow_type = IXGBE_ATR_FLOW_TYPE_TCPV4;
- break;
- case UDP_V4_FLOW:
- input_struct.formatted.flow_type = IXGBE_ATR_FLOW_TYPE_UDPV4;
- break;
- case SCTP_V4_FLOW:
- input_struct.formatted.flow_type = IXGBE_ATR_FLOW_TYPE_SCTPV4;
- break;
- default:
- return -1;
- }
-
- /* copy vlan tag minus the CFI bit */
- if ((fs->vlan_tag & 0xEFFF) || (~fs->vlan_tag_mask & 0xEFFF)) {
- input_struct.formatted.vlan_id = htons(fs->vlan_tag & 0xEFFF);
- if (!fs->vlan_tag_mask) {
- input_masks.vlan_id_mask = htons(0xEFFF);
- } else {
- switch (~fs->vlan_tag_mask & 0xEFFF) {
- /* all of these are valid vlan-mask values */
- case 0xEFFF:
- case 0xE000:
- case 0x0FFF:
- case 0x0000:
- input_masks.vlan_id_mask =
- htons(~fs->vlan_tag_mask);
- break;
- /* exit with error if vlan-mask is invalid */
- default:
- e_err(drv, "Partial VLAN ID or "
- "priority mask in vlan-mask is not "
- "supported by hardware\n");
- return -1;
- }
- }
- }
-
- /* make sure we only use the first 2 bytes of user data */
- if ((fs->data & 0xFFFF) || (~fs->data_mask & 0xFFFF)) {
- input_struct.formatted.flex_bytes = htons(fs->data & 0xFFFF);
- if (!(fs->data_mask & 0xFFFF)) {
- input_masks.flex_mask = 0xFFFF;
- } else if (~fs->data_mask & 0xFFFF) {
- e_err(drv, "Partial user-def-mask is not "
- "supported by hardware\n");
- return -1;
- }
- }
-
- /*
- * Copy input into formatted structures
- *
- * These assignments are based on the following logic
- * If neither input or mask are set assume value is masked out.
- * If input is set, but mask is not mask should default to accept all.
- * If input is not set, but mask is set then mask likely results in 0.
- * If input is set and mask is set then assign both.
- */
- if (fs->h_u.tcp_ip4_spec.ip4src || ~fs->m_u.tcp_ip4_spec.ip4src) {
- input_struct.formatted.src_ip[0] = fs->h_u.tcp_ip4_spec.ip4src;
- if (!fs->m_u.tcp_ip4_spec.ip4src)
- input_masks.src_ip_mask[0] = 0xFFFFFFFF;
- else
- input_masks.src_ip_mask[0] =
- ~fs->m_u.tcp_ip4_spec.ip4src;
- }
- if (fs->h_u.tcp_ip4_spec.ip4dst || ~fs->m_u.tcp_ip4_spec.ip4dst) {
- input_struct.formatted.dst_ip[0] = fs->h_u.tcp_ip4_spec.ip4dst;
- if (!fs->m_u.tcp_ip4_spec.ip4dst)
- input_masks.dst_ip_mask[0] = 0xFFFFFFFF;
- else
- input_masks.dst_ip_mask[0] =
- ~fs->m_u.tcp_ip4_spec.ip4dst;
- }
- if (fs->h_u.tcp_ip4_spec.psrc || ~fs->m_u.tcp_ip4_spec.psrc) {
- input_struct.formatted.src_port = fs->h_u.tcp_ip4_spec.psrc;
- if (!fs->m_u.tcp_ip4_spec.psrc)
- input_masks.src_port_mask = 0xFFFF;
- else
- input_masks.src_port_mask = ~fs->m_u.tcp_ip4_spec.psrc;
- }
- if (fs->h_u.tcp_ip4_spec.pdst || ~fs->m_u.tcp_ip4_spec.pdst) {
- input_struct.formatted.dst_port = fs->h_u.tcp_ip4_spec.pdst;
- if (!fs->m_u.tcp_ip4_spec.pdst)
- input_masks.dst_port_mask = 0xFFFF;
- else
- input_masks.dst_port_mask = ~fs->m_u.tcp_ip4_spec.pdst;
- }
-
- /* determine if we need to drop or route the packet */
- if (fs->action == ETHTOOL_RXNTUPLE_ACTION_DROP)
- target_queue = MAX_RX_QUEUES - 1;
- else
- target_queue = fs->action;
-
- spin_lock(&adapter->fdir_perfect_lock);
- err = ixgbe_fdir_add_perfect_filter_82599(&adapter->hw,
- &input_struct,
- &input_masks, 0,
- target_queue);
- spin_unlock(&adapter->fdir_perfect_lock);
-
- return err ? -1 : 0;
-}
-
static const struct ethtool_ops ixgbe_ethtool_ops = {
.get_settings = ixgbe_get_settings,
.set_settings = ixgbe_set_settings,
@@ -2506,7 +2371,6 @@ static const struct ethtool_ops ixgbe_ethtool_ops = {
.set_coalesce = ixgbe_set_coalesce,
.get_flags = ethtool_op_get_flags,
.set_flags = ixgbe_set_flags,
- .set_rx_ntuple = ixgbe_set_rx_ntuple,
};
void ixgbe_set_ethtool_ops(struct net_device *netdev)
--
1.7.5.4
^ permalink raw reply related
* [net-next 00/12][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-06-23 1:44 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains updates to ixgbe. There are 2 fixes, along
with several cleanups from Alex and Emil. In addition, nfc support was added
as well as bumping the driver version.
The following are changes since commit 56f8a75c17abb854b5907f4a815dc4c3f186ba11:
ip: introduce ip_is_fragment helper inline function
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Alexander Duyck (8):
ixgbe: remove ntuple filtering
ixgbe: fix flags relating to perfect filters to support coexistence
ixgbe: update perfect filter framework to support retaining filters
ixgbe: add basic support for setting and getting nfc controls
ixgbe: add support for displaying ntuple filters via the nfc
interface
ixgbe: add support for nfc addition and removal of filters
ixgbe: add support for modifying UDP RSS flow hash options
ixgbe: fix ring assignment issues for SR-IOV and drop cases
Don Skidmore (1):
ixgbe: update driver version string
Emil Tantilov (3):
ixgbe: move setting RSC into a separate function
ixgbe: move reset code into a separate function
ixgbe: disable RSC when Rx checksum is off
drivers/net/ixgbe/ixgbe.h | 31 ++-
drivers/net/ixgbe/ixgbe_82599.c | 603 ++++++++++++++++++--------------
drivers/net/ixgbe/ixgbe_dcb_nl.c | 13 +-
drivers/net/ixgbe/ixgbe_ethtool.c | 696 +++++++++++++++++++++++++++++--------
drivers/net/ixgbe/ixgbe_main.c | 94 ++++--
drivers/net/ixgbe/ixgbe_type.h | 28 +-
6 files changed, 1009 insertions(+), 456 deletions(-)
--
1.7.5.4
^ permalink raw reply
* Re: unintended ipv4 broadcast policy change
From: David Miller @ 2011-06-23 0:42 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20110622.163935.2248705300315908767.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 22 Jun 2011 16:39:35 -0700 (PDT)
> Contrary to previous discussions I see no code in the ISC dhcp
> client that needs to get at the MAC address. It merely wants
> it there so that it's packet parsing engine can skip over it
> to get at the ipv4/UDP bits.
I take this back, it does want the "from" MAC address. When
using plain BSD sockets, it zeros out the address since as we
know the MAC info is not available with normal UDP sockets.
But the ISC DHCP code never actually uses this information at all,
it only stores it away in the "struct packet" structure, never to
be used again.
That's probably because the info it needs is present in the "chaddr"
field of the DHCP packet. And only the server side actually needs
this.
^ permalink raw reply
* Re: unintended ipv4 broadcast policy change
From: Herbert Xu @ 2011-06-23 0:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110622.163935.2248705300315908767.davem@davemloft.net>
On Wed, Jun 22, 2011 at 04:39:35PM -0700, David Miller wrote:
>
> The context is that I'm looking into cleaning up up the mess we have
> wrt. DHCP listening on packet sockets and (in some cases) seeing every
> packet that hits the system.
>
> Anyways, back in 2007 this commit was made:
>
> commit 8030f54499925d073a88c09f30d5d844fb1b3190
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu Feb 22 01:53:47 2007 +0900
>
> [IPV4] devinet: Register inetdev earlier.
It appears that the intention was to allow sysctl control prior
to device open.
> So now every net device registered has inetdev_init() called on it.
>
> This has a subtle policy side effect that has some interesting
> implications. The route input slow path has this check:
>
> /* IP on this device is disabled. */
>
> if (!in_dev)
> goto out;
>
> But now this will never, ever, be true.
If we ever wanted to disable IPv4 we could always add a sysctl
for that, just like IPv6.
> Which means that previously we would not accept even broadcast
> or multicast packets on an interface that hasn't had at least
> one IP address configured.
>
> Now we will.
This indeed is an unintended side-effect.
> I think we have a hard decision to make. One option is to
> fix the input routing check, by changing it to test if the
> ipv4 address list is empty.
>
> The second option is to remove the check entirely and keep the
> new behavior.
We could also add a disable_ipv4 sysctl and then replace this
check in the routing code with a disable_ipv4 check at the very
top of the IPv4 receive path, just like IPv6.
> This subtle new behavior is interesting because it means that
> a DHCP client could be implemented entirely with plain UDP
> sockets.
Yes this is indeed possible. However, for compatibility purposes
I'm not sure whether we can safely rely on this new behaviour.
Maybe if we add the disable_ipv4 sysctl we can use it to signal
the presence of this new behaviour.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Shawn Guo @ 2011-06-23 0:12 UTC (permalink / raw)
To: Grant Likely
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jeremy Kerr, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <BANLkTimsk2eWKPi2hnHbaAn-vSMKmdYsGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jun 22, 2011 at 09:52:11AM -0600, Grant Likely wrote:
[...]
>
> >> > - line = of_get_property(node, "id", NULL);
> >> > - if (!line)
> >> > + line = of_get_device_index(node, "serial");
> >> > + if (IS_ERR_VALUE(line))
> >> > return -ENODEV;
> >>
> >> Personally, it an alias isn't present, then I'd dynamically assign a port id.
> >>
> > We probably can not. The driver works with being told the correct
> > port id which is defined by soc. Instead of dynamically assigning
> > a port id, we have to tell the driver the exact hardware port id of
> > the device that is being probed.
>
> Are you sure? It doesn't look like the driver behaviour uses id for
> anything other than an index into the statically allocated serial port
> instance table. I don't see any change of behaviour based on the port
> number anywhere.
>
Sorry, I did not make this clear. In serial_imx_probe(), the port
gets created and then saved as below.
imx_ports[sport->port.line] = sport;
While in imx_console_setup(), it addresses the port as following.
sport = imx_ports[co->index];
When users specify their console as ttymxc0, they mean they are
using the first i.mx uart hardware port, in turn ttymxc1 for the
second port ...
That said, imx_port[0] has to be the first hardware port, imx_port[1]
has to be the second one ... That's why port id sport->port.line
can not be dynamically assigned, otherwise console may not work.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 07/11] fs_enet: enable transmit time stamping.
From: Matt Carlson @ 2011-06-22 23:56 UTC (permalink / raw)
To: Richard Cochran
Cc: Eric Dumazet, netdev@vger.kernel.org, David Miller,
Matthew Carlson, Michael Chan
In-Reply-To: <20110620065831.GA5771@riccoc20.at.omicron.at>
On Sun, Jun 19, 2011 at 11:58:31PM -0700, Richard Cochran wrote:
> On Sun, Jun 19, 2011 at 08:30:49PM +0200, Eric Dumazet wrote:
> > Le dimanche 19 juin 2011 ? 20:12 +0200, Richard Cochran a ?crit :
> >
> > > Thanks for your review. I have posted a fix for the first batch (since
> > > they are already in next) and reposted this series.
> > >
> > > But, considering your point, it looks like pxa168_eth and mv643xx_eth
> > > (see patches 9 and 10 of this series) already access skb->len unsafely.
> > >
> > > Would you care to comment on those spots, too?
> >
> > They certainly are buggy, at a first glance.
> >
> > Not only skb->len is unsafe, but netif_tx_stop_queue() calls are unsafe
> > too.
>
> Out of the MAC drivers in my two batches, only drivers/net/tg3.c calls
> netif_tx_stop_queue(txq);
>
> However, I don't know how to fix that. Anyone else care to take a look?
How is netif_tx_stop_queue() unsafe?
^ permalink raw reply
* Re: Weird locking in __release_sock()?
From: David Miller @ 2011-06-22 23:42 UTC (permalink / raw)
To: ddaney; +Cc: netdev
In-Reply-To: <4E027B41.3040009@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 22 Jun 2011 16:31:13 -0700
> In the case of an IPv4 TCP socket, sk_backlog_rcv() calls
> tcp_v4_do_rcv(), which is documented like this:
>
> /* The socket must have it's spinlock held when we get
> * here.
> .
> .
> .
> */
>
> Q: How can this be correct?
sk->lock.owned will be "1" while the backlog is processed.
Exclusive access to the socket is indicated by one of the
following two conditions being true:
1) sk->lock.slock being held
2) sk->lock.owned being non-zero
^ permalink raw reply
* unintended ipv4 broadcast policy change
From: David Miller @ 2011-06-22 23:39 UTC (permalink / raw)
To: herbert; +Cc: netdev
The context is that I'm looking into cleaning up up the mess we have
wrt. DHCP listening on packet sockets and (in some cases) seeing every
packet that hits the system.
Anyways, back in 2007 this commit was made:
commit 8030f54499925d073a88c09f30d5d844fb1b3190
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Feb 22 01:53:47 2007 +0900
[IPV4] devinet: Register inetdev earlier.
So now every net device registered has inetdev_init() called on it.
This has a subtle policy side effect that has some interesting
implications. The route input slow path has this check:
/* IP on this device is disabled. */
if (!in_dev)
goto out;
But now this will never, ever, be true.
Which means that previously we would not accept even broadcast
or multicast packets on an interface that hasn't had at least
one IP address configured.
Now we will.
I think we have a hard decision to make. One option is to
fix the input routing check, by changing it to test if the
ipv4 address list is empty.
The second option is to remove the check entirely and keep the
new behavior.
This subtle new behavior is interesting because it means that
a DHCP client could be implemented entirely with plain UDP
sockets.
Contrary to previous discussions I see no code in the ISC dhcp
client that needs to get at the MAC address. It merely wants
it there so that it's packet parsing engine can skip over it
to get at the ipv4/UDP bits.
In fact the stock ISC dhcp code has a bug in that it creates
it's AF_PACKET socket with SOCK_PACKET as the type, which causes
the BPF filter it registers to never be used. It should be
using SOCK_RAW as the type. It seems to use SOCK_PACKET in
order to use the name based socket address in it's bind()
call.
As a side effect of an unrelated change, this bug got fixed in
Fedora/RHEL (it wants access to the tpacket aux data in order to see
the checksum flags, this is not available with SOCK_PACKET type
AF_PACKET sockets).
But debian definitely still has this bug. On debian, as a result,
every packet received gets parsed.
Actually this bug is more serious, since the code in ISC dhcp
elides the UDP protocol and port validation if it is compiled
with the BPF code in place (which it is). This means it's
parsing garbage most of the time.
It also creates the packet socket with ETH_P_ALL, making this
an even more severe issue.
^ permalink raw reply
* Re: Remove IPv6 ND prefix on ethernet disconnect?
From: Hagen Paul Pfeifer @ 2011-06-22 23:33 UTC (permalink / raw)
To: Harald Welte; +Cc: netdev
In-Reply-To: <20110622214129.GA30521@prithivi.gnumonks.org>
* Harald Welte | 2011-06-22 23:41:29 [+0200]:
>My point is: If it's the kernel that automatically adds it, why is it
>not the kernel that automatically deletes it when it is no longer safe
>to assume it is valid (such as after loosing the link)?
Is loosing the link a sufficient criterion to restart ND? IMHO it is superior
to keep the same IP address (I assume privacy extension enabled) in the same
network if you lose the link artificial.
Environments where the link goes down and up again may suffer from such a
behavior. Maybe a script in Network Manager may be the better place. For me it
sounds like a policy thing which should not handled in the kernel.
But yes Harald, I understand your objection! ;-)
Hagen
^ permalink raw reply
* Weird locking in __release_sock()?
From: David Daney @ 2011-06-22 23:31 UTC (permalink / raw)
To: netdev
Hi,
In net/core/sock.c the function __release_sock() appears to drop the
socket lock, and then feed the backlogged skbs to sk_backlog_rcv().
In the case of an IPv4 TCP socket, sk_backlog_rcv() calls
tcp_v4_do_rcv(), which is documented like this:
/* The socket must have it's spinlock held when we get
* here.
.
.
.
*/
Q: How can this be correct?
Perhaps I am missing something. In any event, thanks in advance
shedding some light on the locking situation.
David Daney
^ permalink raw reply
* Re: [RFT PATCH v3 00/12] Cleanup and extension of netdev features
From: Ben Greear @ 2011-06-22 23:11 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, David S. Miller, Ben Hutchings
In-Reply-To: <cover.1308758435.git.mirq-linux@rere.qmqm.pl>
On 06/22/2011 09:04 AM, Michał Mirosław wrote:
> v3 of a feature handling cleanup and extension series. For testing, you
> might want user-space ethtool patched with:
>
> http://patchwork.ozlabs.org/patch/96374/
There is a typo in one of those patches:
CC fs/quota/netlink.o
/home/greearb/git/net-next-2.6/net/core/dev.c: In function ‘__netdev_update_features’:
/home/greearb/git/net-next-2.6/net/core/dev.c:5288: warning: too many arguments for format
CC net/core/ethtool.o
netdev_dbg(dev, "Features changed: %pNF -> pNF\n",
&dev->features, &features);
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: net/ipv4: commit d0733d2e29b breaks rtorrent
From: Fabienne Ducroquet @ 2011-06-22 23:02 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Reinhard Max, Marcus Meissner, sundell.software, David S. Miller,
netdev
In-Reply-To: <20110622085329.65c625de@nehalam.ftrdhcpuser.net>
On Wed, Jun 22, 2011 at 08:53:29AM -0700, Stephen Hemminger wrote:
> You can find code here http://libtorrent.rakshasa.no/
> but it is in C++ so there is an abnormally high indirection factor
> between reality of the bug and the code as written.
I had a look at the code, I found where bind is called, but it does not
help: it is in libtorrent/src/net/socket_fd.cc:
bool
SocketFd::bind(const rak::socket_address& sa) {
check_valid();
return !::bind(m_fd, sa.c_sockaddr(), sa.length());
}
check_valid() checks the validity of the socket FD.
It is called by the function:
bool
Listen::open(uint16_t first, uint16_t last, const rak::socket_address* bindAddress) {
close();
[ Checks that the range of the ports is OK, that the address
is an inet or inet6 address, that the socket can be
allocated.]
rak::socket_address sa;
sa.copy(*bindAddress, bindAddress->length());
for (uint16_t i = first; i <= last; ++i) {
sa.set_port(i);
if (get_fd().bind(sa) && get_fd().listen(50)) {
...
in libtorrent/src/net/listen.cc. That function was called by:
bool
ConnectionManager::listen_open(port_type begin, port_type end) {
if (!m_listen->open(begin, end, rak::socket_address::cast_from(m_bindAddress)))
return false;
m_listenPort = m_listen->port();
return true;
}
in libtorrent/src/torrent/connection_manager.cc, and it was itself
called by Manager::listen_open() in rtorrent/core/manager.cc, which
throws the error message I got because the call to
torrent::connection_manager()->listen_open(portFirst, portLast)
fails.
So the question now is to find how the m_bindAddress used in
ConnectionManager::listen_open is set, but I prefer not to do that right
now.
> Did you try contacting the developer?
I've put him in the Cc: since the first message.
Fabienne
^ permalink raw reply
* Re: [PATCH] net: wimax: Remove of unused 'rfkill_input' pointer
From: Perez-Gonzalez, Inaky @ 2011-06-22 21:47 UTC (permalink / raw)
To: vitalivanov@gmail.com
Cc: davem@davemloft.net, johannes@sipsolutions.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
alan-jenkins@tuffmail.co.uk, hmh@hmh.eng.br,
linville@tuxdriver.com
In-Reply-To: <1308766004.13761.32.camel@vivanov>
On Wed, 2011-06-22 at 21:06 +0300, Vitaliy Ivanov wrote:
> David,
>
> Please apply.
>
> I added here all the peoples who took part in
> 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5 commit for any comments.
>
> Also performed all yes/no/mod config builds w/ no issues.
> >From b93ca8947e85e4ff7e9f314675d4770b90b77548 Mon Sep 17 00:00:00 2001
> From: Vitaliy Ivanov <vitalivanov@gmail.com>
> Date: Wed, 22 Jun 2011 20:57:49 +0300
> Subject: [PATCH] net: wimax: Remove of unused 'rfkill_input' pointer
>
> Seems like this was not cleaned during the 'rfkill: rewrite' checkin
> 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5.
>
> Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Acked-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
^ permalink raw reply
* Remove IPv6 ND prefix on ethernet disconnect?
From: Harald Welte @ 2011-06-22 21:41 UTC (permalink / raw)
To: netdev
Hi all,
I know I've lost a bit touch with the Linux networking area in recent
years...
Nonetheless, there's one thing that's been bugging me for a long time
and I'm thinking of investing some time to resolve it. Before doing
that, I'm curious to see if there are existing solutions or existing
discussions that I've missed on the subject:
Imagine a setting where somebody is carrying a laptop around all day,
visiting several sites (office, customer, home,...) without rebooting
the machine (suspend to ram or disk).
You start at home in the morning, you get an IPv6 prefix via
auto-discovery, everything is fine. Now you move along to your office,
but despite the link down and link up events, the IPv6 prefix remains
configured.
You may or may not get a new prefix, but based on my experience, in both
cases you experience errors following up:
1) in the case of the new prefix, the old default route/prefix is still
used
2) in case there is no new prefix, the kernel happily sends ipv6 packets
to the non-existant router of a completely different network.
Now I presume that those things are supposedly resolved by
NetworkManager, but I don't really see why a complex and large userspace
program should be required for something as simple as removing prefixes
that have prevously been added automatically.
My point is: If it's the kernel that automatically adds it, why is it
not the kernel that automatically deletes it when it is no longer safe
to assume it is valid (such as after loosing the link)?
Any input is appreciated. Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Flavio Leitner @ 2011-06-22 21:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <20110622125439.44e47a2c@nehalam.ftrdhcpuser.net>
On 06/22/2011 04:54 PM, Stephen Hemminger wrote:
> This adds support for a configuring the minimum number of links that
> must be active before asserting carrier. It is similar to the Cisco
> EtherChannel min-links feature. This allows setting the minimum number
> of member ports that must be up (link-up state) before marking the
> bond device as up (carrier on). This is useful for situations where
> higher level services such as clustering want to ensure a minimum
> number of low bandwidth links are active before switchover.
>
> See:
> http://bugzilla.vyatta.com/show_bug.cgi?id=7196
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> v2 - need to transition to carrier_off if insufficient number of links
> and whitespace cleanup
>
> drivers/net/bonding/bond_3ad.c | 8 ++++++--
> drivers/net/bonding/bond_main.c | 5 +++++
> drivers/net/bonding/bond_procfs.c | 1 +
> drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> drivers/net/bonding/bonding.h | 1 +
> 5 files changed, 48 insertions(+), 2 deletions(-)
[...]
> --- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
> +++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 12:51:43.431614028 -0700
> @@ -2342,8 +2342,17 @@ void bond_3ad_handle_link_change(struct
> */
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> - if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
> - if (!netif_carrier_ok(bond->dev)) {
> + struct aggregator *active;
> +
> + active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
> + if (active) {
> + /* are enough slaves available to consider link up? */
> + if (active->num_of_ports < bond->params.min_links) {
> + if (netif_carrier_ok(bond->dev)) {
> + netif_carrier_off(bond->dev);
> + return 1;
> + }
> + } else if (!netif_carrier_ok(bond->dev)) {
> netif_carrier_on(bond->dev);
> return 1;
> }
Looks good and works here, thanks!
Signed-off-by: Flavio Leitner <fbl@redhat.com>
fbl
^ permalink raw reply
* iproute correlated loss generator parts are missing
From: Hagen Paul Pfeifer @ 2011-06-22 21:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, stefano.salsano, fabio.ludovici
Hey Stephen,
NetemCLG (Correlated Loss Generator) patches[1] for iproute are still missing.
The kernel patch are already mainline but it falls difficult to use it. :-)
Nice add-on: they even wrote a man page for netem.
Hagen
[1] http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG#NetemCLGPatch
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
From: Sven Eckelmann @ 2011-06-22 20:58 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20110622.011620.1019772975075064501.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]
On Wednesday 22 June 2011 01:16:20 David Miller wrote:
> From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> Date: Wed, 22 Jun 2011 09:41:45 +0200
>
> > On Tuesday 21 June 2011 14:35:15 David Miller wrote:
> >> All of this effort was placed to get this thing merged into the
> >> main tree, and then moved out of staging.
> >
> > "Shooting the messenger" - I think that is the matching phrase. Just try
> > to grep my name in the net/batman-adv/ and you will see it nowhere.
>
> It is everywhere as far as I am concerned, because you're the only person
> actually keeping upstream maintained and in sync.
That is more related to the fact that Mareks opinion on the topic is that only
one person should be in responsible for the linux merging and this position
should not be changed each time. And I understood the names in MAINTAINERS as
the persons which feel responsible and are the right ones to contact to get
something done (whether it is merging, submitting bug reports, asking for
information, ...).
> > The problem is that I am probably the most unimportant person in the
> > whole project.
>
> From my perspective, this is not true. You are the most important
> person. And this is because the people writing the code obviously
> don't care enough about upstream to do any merges themselves. Yet
> you do.
I think that I have to adjust your perspective slightly. I would never say
that Marek doesn't care about something. Yes, he never did a pull request, but
he always comes up and try to give further insight when it was needed. He is
currently the mastermind behind batman-adv and tries to keep everything
together.
He already wrote you that he is willing to take over and I will assist him as
good as I can (but not doing pull request anymore or giving statements whether
a patch is good or bad for batman-adv/linux)
Just to give you a small overview about the stuff where currently work is done
(as far as I know). More or less the complete protocol should be rewritten and
many features should be added. You already got the first step when you merged
the translation table and roaming changes [1]. Other topics seem to be:
* multicast[2]
* splitting OGMs[3] in ELP[4], OGM and something else
* Adding support for an ARP protocol over distributed hash tables[5]
* wireless network coding[7]
* ap isolation
* mesh wide minstrel
* transmission quality calculated using the data from the wifi drivers along
the path
* redundancy bonding
* ...
Every change needs some modifications to the packet format and may make it
incompatible to the previous versions (some only add flags and some need to
modify many things and even add new packet types). They already started to
discuss[8] how they want to send those changes to you.
thanks,
Sven
[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-June/005010.html
[2] http://www.open-mesh.org/wiki/batman-adv/Multicast-ideas
[3] http://www.open-mesh.org/wiki/batman-adv/OGM
[4] http://www.open-mesh.org/wiki/batman-adv/ELP
[5] http://www.open-mesh.org/wiki/batman-adv/DAT
[6] http://www.open-mesh.org/wiki/batman-adv/MGO
[7] http://downloads.open-mesh.org/batman/misc/wbmv4-network_coding.avi
(there is a document called "Inter-Flow Network Coding for Wireless Mesh
Networks" about it, but I don't think that I am allowed to redistribute
it)
[8] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-June/005025.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] net/usb: kalmia: Various fixes for better support of non-x86 architectures.
From: David Miller @ 2011-06-22 20:41 UTC (permalink / raw)
To: marius.kotsbak; +Cc: netdev, linux-usb, marius
In-Reply-To: <1308756376-9920-1-git-send-email-marius@kotsbak.com>
From: "Marius B. Kotsbak" <marius.kotsbak@gmail.com>
Date: Wed, 22 Jun 2011 17:26:16 +0200
> -Support for big endian.
> -Do not use USB buffers at the stack.
> -Safer/more efficient code for local constants.
>
> Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: David Miller @ 2011-06-22 20:29 UTC (permalink / raw)
To: jch; +Cc: prarit, fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <9A104657-E760-4489-A92E-7DF04CC0EE6C@oracle.com>
From: John Haxby <jch@thehaxbys.co.uk>
Date: Wed, 22 Jun 2011 19:46:20 +0100
> davem: I'm more than happy to push that patch through if it will
> make xt_SYSRQ more acceptable.
It's not me who reviews and approves netfilter patches, it's
the netfilter developers who do.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: David Miller @ 2011-06-22 20:27 UTC (permalink / raw)
To: prarit; +Cc: john.haxby, fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <4E0228C3.8090402@redhat.com>
From: Prarit Bhargava <prarit@redhat.com>
Date: Wed, 22 Jun 2011 13:39:15 -0400
> davem -- as I don't monitor this list, are you indicating that you are
> more amenable to this code being accepted upstream? Or is that part of
> the debate still ongoing?
I'd rather have something like xt_SYSRQ in the tree than the original
proposal in this thread.
Work it out with the netfilter developers if you want to see it
integrated.
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Stephen Hemminger @ 2011-06-22 19:54 UTC (permalink / raw)
To: Flavio Leitner; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <4E02452E.2030307@redhat.com>
This adds support for a configuring the minimum number of links that
must be active before asserting carrier. It is similar to the Cisco
EtherChannel min-links feature. This allows setting the minimum number
of member ports that must be up (link-up state) before marking the
bond device as up (carrier on). This is useful for situations where
higher level services such as clustering want to ensure a minimum
number of low bandwidth links are active before switchover.
See:
http://bugzilla.vyatta.com/show_bug.cgi?id=7196
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
v2 - need to transition to carrier_off if insufficient number of links
and whitespace cleanup
drivers/net/bonding/bond_3ad.c | 8 ++++++--
drivers/net/bonding/bond_main.c | 5 +++++
drivers/net/bonding/bond_procfs.c | 1 +
drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 1 +
5 files changed, 48 insertions(+), 2 deletions(-)
--- a/drivers/net/bonding/bond_main.c 2011-06-22 09:06:40.895998636 -0700
+++ b/drivers/net/bonding/bond_main.c 2011-06-22 10:11:52.855974841 -0700
@@ -98,6 +98,7 @@ static char *mode;
static char *primary;
static char *primary_reselect;
static char *lacp_rate;
+static int min_links;
static char *ad_select;
static char *xmit_hash_policy;
static int arp_interval = BOND_LINK_ARP_INTERV;
@@ -150,6 +151,9 @@ module_param(ad_select, charp, 0);
MODULE_PARM_DESC(ad_select, "803.ad aggregation selection logic; "
"0 for stable (default), 1 for bandwidth, "
"2 for count");
+module_param(min_links, int, 0);
+MODULE_PARM_DESC(min_links, "Minimum number of available links before turning on carrier");
+
module_param(xmit_hash_policy, charp, 0);
MODULE_PARM_DESC(xmit_hash_policy, "balance-xor and 802.3ad hashing method; "
"0 for layer 2 (default), 1 for layer 3+4, "
@@ -4798,6 +4802,7 @@ static int bond_check_params(struct bond
params->tx_queues = tx_queues;
params->all_slaves_active = all_slaves_active;
params->resend_igmp = resend_igmp;
+ params->min_links = min_links;
if (primary) {
strncpy(params->primary, primary, IFNAMSIZ);
--- a/drivers/net/bonding/bond_procfs.c 2011-06-22 09:17:04.391998454 -0700
+++ b/drivers/net/bonding/bond_procfs.c 2011-06-22 09:27:09.815997950 -0700
@@ -125,6 +125,7 @@ static void bond_info_show_master(struct
seq_puts(seq, "\n802.3ad info\n");
seq_printf(seq, "LACP rate: %s\n",
(bond->params.lacp_fast) ? "fast" : "slow");
+ seq_printf(seq, "Min links: %d\n", bond->params.min_links);
seq_printf(seq, "Aggregator selection policy (ad_select): %s\n",
ad_select_tbl[bond->params.ad_select].modename);
--- a/drivers/net/bonding/bond_sysfs.c 2011-06-22 09:04:50.295998865 -0700
+++ b/drivers/net/bonding/bond_sysfs.c 2011-06-22 12:46:57.123624800 -0700
@@ -819,6 +819,38 @@ out:
static DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR,
bonding_show_lacp, bonding_store_lacp);
+static ssize_t bonding_show_min_links(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bonding *bond = to_bond(d);
+
+ return sprintf(buf, "%d\n", bond->params.min_links);
+}
+
+static ssize_t bonding_store_min_links(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct bonding *bond = to_bond(d);
+ int ret;
+ unsigned int new_value;
+
+ ret = kstrtouint(buf, 0, &new_value);
+ if (ret < 0) {
+ pr_err("%s: Ignoring invalid min links value %s.\n",
+ bond->dev->name, buf);
+ return ret;
+ }
+
+ pr_info("%s: Setting min links value to %u\n",
+ bond->dev->name, new_value);
+ bond->params.min_links = new_value;
+ return count;
+}
+static DEVICE_ATTR(min_links, S_IRUGO | S_IWUSR,
+ bonding_show_min_links, bonding_store_min_links);
+
static ssize_t bonding_show_ad_select(struct device *d,
struct device_attribute *attr,
char *buf)
@@ -1601,6 +1633,7 @@ static struct attribute *per_bond_attrs[
&dev_attr_queue_id.attr,
&dev_attr_all_slaves_active.attr,
&dev_attr_resend_igmp.attr,
+ &dev_attr_min_links.attr,
NULL,
};
--- a/drivers/net/bonding/bonding.h 2011-06-22 09:05:32.351998841 -0700
+++ b/drivers/net/bonding/bonding.h 2011-06-22 09:27:23.959999290 -0700
@@ -147,6 +147,7 @@ struct bond_params {
int updelay;
int downdelay;
int lacp_fast;
+ unsigned int min_links;
int ad_select;
char primary[IFNAMSIZ];
int primary_reselect;
--- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
+++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 12:51:43.431614028 -0700
@@ -2342,8 +2342,17 @@ void bond_3ad_handle_link_change(struct
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
- if (!netif_carrier_ok(bond->dev)) {
+ struct aggregator *active;
+
+ active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
+ if (active) {
+ /* are enough slaves available to consider link up? */
+ if (active->num_of_ports < bond->params.min_links) {
+ if (netif_carrier_ok(bond->dev)) {
+ netif_carrier_off(bond->dev);
+ return 1;
+ }
+ } else if (!netif_carrier_ok(bond->dev)) {
netif_carrier_on(bond->dev);
return 1;
}
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Andy Gospodarek @ 2011-06-22 19:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <20110622105408.06fd4788@nehalam.ftrdhcpuser.net>
On Wed, Jun 22, 2011 at 10:54:08AM -0700, Stephen Hemminger wrote:
> This adds support for a configuring the minimum number of links that
> must be active before asserting carrier. It is similar to the Cisco
> EtherChannel min-links feature. This allows setting the minimum number
> of member ports that must be up (link-up state) before marking the
> bond device as up (carrier on). This is useful for situations where
> higher level services such as clustering want to ensure a minimum
> number of low bandwidth links are active before switchover.
>
> This is a prototype, did some basic testing but has not been
> tested with other switches.
>
> See:
> http://bugzilla.vyatta.com/show_bug.cgi?id=7196
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
[...]
> --- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
> +++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 09:44:11.815997557 -0700
> @@ -2342,8 +2342,12 @@ void bond_3ad_handle_link_change(struct
> */
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> - if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
> - if (!netif_carrier_ok(bond->dev)) {
> + struct aggregator *active;
> +
> + active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
> + if (active) {
> + if (active->num_of_ports >= bond->params.min_links &&
> + !netif_carrier_ok(bond->dev)) {
> netif_carrier_on(bond->dev);
> return 1;
> }
>
I agree with Flavio that it feels like there is a problem here. I was
just wrestling with my switch and trying to get LACP working there so I
could test this.
^ permalink raw reply
* Re: [PATCH 4/5] pm: move pm notifiers into suspend.h
From: Rafael J. Wysocki @ 2011-06-22 19:49 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, akpm, netdev, Chris Ball, Len Brown, Pavel Machek,
Ohad Ben-Cohen, Linus Walleij, Philip Rakity, David S. Miller,
Lucas De Marchi, Paul E. McKenney, Josh Triplett, linux-mmc,
linux-pm
In-Reply-To: <1308724522-32461-5-git-send-email-amwang@redhat.com>
On Wednesday, June 22, 2011, Amerigo Wang wrote:
> It is not necessary to share the same notifier.h.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
> ---
> drivers/mmc/core/core.c | 3 +++
> include/linux/notifier.h | 10 ++--------
> include/linux/suspend.h | 8 ++++++++
> 3 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 68091dd..2cd4ec5 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -23,6 +23,9 @@
> #include <linux/log2.h>
> #include <linux/regulator/consumer.h>
> #include <linux/pm_runtime.h>
> +#ifdef CONFIG_PM
> +#include <linux/suspend.h>
> +#endif
I don't think the #ifdef in necessary. Any dependencies on CONFIG_PM
(or CONFIG_SUSPEND etc.) should be taken care of inside of suspend.h.
This file should be fixed if they aren't.
> #include <linux/mmc/card.h>
> #include <linux/mmc/host.h>
> diff --git a/include/linux/notifier.h b/include/linux/notifier.h
> index 145c436..ae8f7d9 100644
> --- a/include/linux/notifier.h
> +++ b/include/linux/notifier.h
> @@ -191,15 +191,9 @@ static inline int notifier_to_errno(int ret)
>
> /* reboot notifiers are defined in include/linux/reboot.h. */
>
> -#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */
> +/* Hibernation and suspend events are defined in include/linux/suspend.h. */
>
> -/* Hibernation and suspend events */
> -#define PM_HIBERNATION_PREPARE 0x0001 /* Going to hibernate */
> -#define PM_POST_HIBERNATION 0x0002 /* Hibernation finished */
> -#define PM_SUSPEND_PREPARE 0x0003 /* Going to suspend the system */
> -#define PM_POST_SUSPEND 0x0004 /* Suspend finished */
> -#define PM_RESTORE_PREPARE 0x0005 /* Going to restore a saved image */
> -#define PM_POST_RESTORE 0x0006 /* Restore failed */
> +#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */
>
> /* Console keyboard events.
> * Note: KBD_KEYCODE is always sent before KBD_UNBOUND_KEYCODE, KBD_UNICODE and
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 083ffea..95bc81c 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -260,6 +260,14 @@ static inline int hibernate(void) { return -ENOSYS; }
> static inline bool system_entering_hibernation(void) { return false; }
> #endif /* CONFIG_HIBERNATION */
>
> +/* Hibernation and suspend events */
> +#define PM_HIBERNATION_PREPARE 0x0001 /* Going to hibernate */
> +#define PM_POST_HIBERNATION 0x0002 /* Hibernation finished */
> +#define PM_SUSPEND_PREPARE 0x0003 /* Going to suspend the system */
> +#define PM_POST_SUSPEND 0x0004 /* Suspend finished */
> +#define PM_RESTORE_PREPARE 0x0005 /* Going to restore a saved image */
> +#define PM_POST_RESTORE 0x0006 /* Restore failed */
> +
> #ifdef CONFIG_PM_SLEEP
> void save_processor_state(void);
> void restore_processor_state(void);
>
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Flavio Leitner @ 2011-06-22 19:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <20110622105408.06fd4788@nehalam.ftrdhcpuser.net>
On 06/22/2011 02:54 PM, Stephen Hemminger wrote:
> This adds support for a configuring the minimum number of links that
> must be active before asserting carrier. It is similar to the Cisco
> EtherChannel min-links feature. This allows setting the minimum number
> of member ports that must be up (link-up state) before marking the
> bond device as up (carrier on). This is useful for situations where
> higher level services such as clustering want to ensure a minimum
> number of low bandwidth links are active before switchover.
>
> This is a prototype, did some basic testing but has not been
> tested with other switches.
>
> See:
> http://bugzilla.vyatta.com/show_bug.cgi?id=7196
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> drivers/net/bonding/bond_3ad.c | 8 ++++++--
> drivers/net/bonding/bond_main.c | 5 +++++
> drivers/net/bonding/bond_procfs.c | 1 +
> drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> drivers/net/bonding/bonding.h | 1 +
> 5 files changed, 48 insertions(+), 2 deletions(-)
>
> --- a/drivers/net/bonding/bond_main.c 2011-06-22 09:06:40.895998636 -0700
> +++ b/drivers/net/bonding/bond_main.c 2011-06-22 10:11:52.855974841 -0700
> @@ -98,6 +98,7 @@ static char *mode;
> static char *primary;
> static char *primary_reselect;
> static char *lacp_rate;
> +static int min_links;
> static char *ad_select;
> static char *xmit_hash_policy;
> static int arp_interval = BOND_LINK_ARP_INTERV;
> @@ -150,6 +151,9 @@ module_param(ad_select, charp, 0);
> MODULE_PARM_DESC(ad_select, "803.ad aggregation selection logic; "
> "0 for stable (default), 1 for bandwidth, "
> "2 for count");
> +module_param(min_links, int, 0);
> +MODULE_PARM_DESC(min_links, "Minimum number of available links before turning on carrier");
> +
> module_param(xmit_hash_policy, charp, 0);
> MODULE_PARM_DESC(xmit_hash_policy, "balance-xor and 802.3ad hashing method; "
> "0 for layer 2 (default), 1 for layer 3+4, "
> @@ -4798,6 +4802,7 @@ static int bond_check_params(struct bond
> params->tx_queues = tx_queues;
> params->all_slaves_active = all_slaves_active;
> params->resend_igmp = resend_igmp;
> + params->min_links = min_links;
>
> if (primary) {
> strncpy(params->primary, primary, IFNAMSIZ);
> --- a/drivers/net/bonding/bond_procfs.c 2011-06-22 09:17:04.391998454 -0700
> +++ b/drivers/net/bonding/bond_procfs.c 2011-06-22 09:27:09.815997950 -0700
> @@ -125,6 +125,7 @@ static void bond_info_show_master(struct
> seq_puts(seq, "\n802.3ad info\n");
> seq_printf(seq, "LACP rate: %s\n",
> (bond->params.lacp_fast) ? "fast" : "slow");
> + seq_printf(seq, "Min links: %d\n", bond->params.min_links);
> seq_printf(seq, "Aggregator selection policy (ad_select): %s\n",
> ad_select_tbl[bond->params.ad_select].modename);
>
> --- a/drivers/net/bonding/bond_sysfs.c 2011-06-22 09:04:50.295998865 -0700
> +++ b/drivers/net/bonding/bond_sysfs.c 2011-06-22 10:24:11.287947057 -0700
> @@ -819,6 +819,39 @@ out:
> static DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR,
> bonding_show_lacp, bonding_store_lacp);
>
> +
Other similar parts uses just one blank line.
> +static ssize_t bonding_show_min_links(struct device *d,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct bonding *bond = to_bond(d);
> +
> + return sprintf(buf, "%d\n", bond->params.min_links);
> +}
> +
> +static ssize_t bonding_store_min_links(struct device *d,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct bonding *bond = to_bond(d);
> + int ret;
> + unsigned int new_value;
> +
> + ret = kstrtouint(buf, 0, &new_value);
> + if (ret < 0) {
> + pr_err("%s: Ignoring invalid min links value %s.\n",
> + bond->dev->name, buf);
> + return ret;
> + }
> +
> + pr_info("%s: Setting min links value to %u\n",
> + bond->dev->name, new_value);
> + bond->params.min_links = new_value;
> + return count;
> +}
> +static DEVICE_ATTR(min_links, S_IRUGO | S_IWUSR,
> + bonding_show_min_links, bonding_store_min_links);
> +
> static ssize_t bonding_show_ad_select(struct device *d,
> struct device_attribute *attr,
> char *buf)
> @@ -863,6 +896,7 @@ out:
> static DEVICE_ATTR(ad_select, S_IRUGO | S_IWUSR,
> bonding_show_ad_select, bonding_store_ad_select);
>
> +
Same here.
> /*
> * Show and set the number of peer notifications to send after a failover event.
> */
> @@ -1601,6 +1635,7 @@ static struct attribute *per_bond_attrs[
> &dev_attr_queue_id.attr,
> &dev_attr_all_slaves_active.attr,
> &dev_attr_resend_igmp.attr,
> + &dev_attr_min_links.attr,
> NULL,
> };
>
> --- a/drivers/net/bonding/bonding.h 2011-06-22 09:05:32.351998841 -0700
> +++ b/drivers/net/bonding/bonding.h 2011-06-22 09:27:23.959999290 -0700
> @@ -147,6 +147,7 @@ struct bond_params {
> int updelay;
> int downdelay;
> int lacp_fast;
> + unsigned int min_links;
> int ad_select;
> char primary[IFNAMSIZ];
> int primary_reselect;
> --- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
> +++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 09:44:11.815997557 -0700
> @@ -2342,8 +2342,12 @@ void bond_3ad_handle_link_change(struct
> */
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> - if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
> - if (!netif_carrier_ok(bond->dev)) {
> + struct aggregator *active;
> +
> + active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
> + if (active) {
> + if (active->num_of_ports >= bond->params.min_links &&
> + !netif_carrier_ok(bond->dev)) {
> netif_carrier_on(bond->dev);
> return 1;
I'm not seeing how this will handle when one interface goes down leaving
the aggregator without the minimum number of links because you still have
an aggregator and link, so the resulting link wouldn't change.
I thought in something like this:
@@ -2345,18 +2345,31 @@ void bond_3ad_handle_link_change(struct slave *slave, char link)
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
- if (!netif_carrier_ok(bond->dev)) {
- netif_carrier_on(bond->dev);
- return 1;
+ struct aggregator *active;
+
+ active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
+
+ if (active) {
+ if (active->num_of_ports >= bond->params.min_links) {
+ if (!netif_carrier_ok(bond->dev)) {
+ netif_carrier_on(bond->dev);
+ return 1;
+ }
+ }
+ else {
+ /* link is up without enough slaves, disable it */
+ if (netif_carrier_ok(bond->dev)) {
+ netif_carrier_off(bond->dev);
+ return 1;
+ }
}
- return 0;
}
- if (netif_carrier_ok(bond->dev)) {
+ if (!active && netif_carrier_ok(bond->dev)) {
netif_carrier_off(bond->dev);
return 1;
}
+
return 0;
}
what you think?
thanks,
fbl
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: John Haxby @ 2011-06-22 18:57 UTC (permalink / raw)
To: Prarit Bhargava
Cc: David Miller, Florian Westphal, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <4E0228C3.8090402@redhat.com>
On 22 Jun 2011, at 18:39, Prarit Bhargava wrote:
>
>> Although I wasn't sure that it could happen, it's also possible that the
>> cryptographic functions can get in your way. xt_SYSRQ does its best to
>> avoid problems by pre-allocating everything it can so there is as little
>> as possible to do when it is needed, but it is possible for it to fail.
>>
>>
>
> My running theory as to the failure is that the CPU that took the sysrq
> is also the CPU that was having problems that resulted in the "slow
> down" of the system.
>
> On a known-good system, xt_SYSRQ behaves properly AFAICT. It functions
> exactly the way we want it to.
>
> So ... I read the following discussion of xt_SYSRQ from last year:
>
> http://www.kerneltrap.com/mailarchive/linux-netdev/2010/4/21/6275199/thread
>
> And it seems there were no technical objections to the code, but there
> were other concerns.
>
> davem -- as I don't monitor this list, are you indicating that you are
> more amenable to this code being accepted upstream? Or is that part of
> the debate still ongoing?
>
>
I've just re-read the thread and I'm reminded that I never did submit the xt_SYSRQ hash update I mentioned at the end of the thread.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox