* [PATCH net-next 0/5] mlx4: link sensing changes and Fixes.
From: Yevgeny Petrilin @ 2011-12-19 14:00 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp
Hello David,
This series presents link sensing logic changes (mostly for ConnectX3 devices)
and some fixes to the driver in addition to the SRIOV code we submitted lately.
Thanks,
Yevgeny
drivers/net/ethernet/mellanox/mlx4/cmd.c | 88 +++++++++++-------
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2
drivers/net/ethernet/mellanox/mlx4/fw.c | 2
drivers/net/ethernet/mellanox/mlx4/fw.h | 2
drivers/net/ethernet/mellanox/mlx4/main.c | 60 ++++++++----
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 4
include/linux/mlx4/device.h | 5 -
7 files changed, 110 insertions(+), 53 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] ARM: net: JIT compiler for packet filters
From: Dave Martin @ 2011-12-19 15:52 UTC (permalink / raw)
To: Uwe Kleine-K?nig; +Cc: Mircea Gherzan, netdev, linux-arm-kernel
In-Reply-To: <20111219153338.GV24496@pengutronix.de>
On Mon, Dec 19, 2011 at 04:33:38PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Mon, Dec 19, 2011 at 03:24:18PM +0000, Dave Martin wrote:
> > On Mon, Dec 19, 2011 at 04:19:58PM +0100, Uwe Kleine-K?nig wrote:
> > > On Mon, Dec 19, 2011 at 12:50:21PM +0000, Dave Martin wrote:
> > > > On Mon, Dec 19, 2011 at 09:40:30AM +0100, Mircea Gherzan wrote:
> > > > > Based of Matt Evans's PPC64 implementation.
> > > > Note that it's fine to have the JIT generating ARM code, even if the rest
> > > > if the kernel is Thumb-2. This would only start to cause problems if we
> > > > want to do things like set kprobes in the JITted code, or unwind out of
> > > > the JITted code.
> > > or use a CPU that doesn't speak ARM (e.g. v7M)
> >
> > Indeed... I was assuming though that that would be out of scope for the
> > first iteration of this code.
> Right, depending on !THUMB2 is fine. Only generating ARM code with
> THUMB2=y is not.
The kernel doesn't support v7-M upstream though. CONFIG_THUMB2_KERNEL=y
doesn't mean that there is no ARM code present -- there _is_ ARM code in
the kernel image even with this option (though not very much).
IMHO, CONFIG_THUMB2_KERNEL should be viewed as similiar to an optimisation
option or other code gen options -- it's a hint to use the Thumb-2
instruction set in preference to ARM, but doesn't make a 100% guarantee.
Some parts of the kernel do contain ARM code even in this configuration.
The real problem we have here is that we do not distinguish between v7-A
and v7-M in Kconfig (this is not the same thing as CONFIG_MMU, since
there's no special reason why it should be impossible to build a ucLinux
kernel for v7-A -- in which case the ARM instruction is available)
In the meantime, we could temporarily make the JIT dependent on
MMU || !THUMB2_KERNEL, but that doesn't seem strictly correct.
If we had dedicated Kconfig variables describing the (non-) availability
of the two instruction sets, that might enable us to get this right.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH net] gianfar: Reject out-of-range RX NFC locations
From: Ben Hutchings @ 2011-12-19 15:51 UTC (permalink / raw)
To: Sebastian Pöhn; +Cc: David Miller, netdev
In-Reply-To: <1324111180.1813.8.camel@vostro>
On Sat, 2011-12-17 at 09:39 +0100, Sebastian Pöhn wrote:
> On Sat, 2011-12-17 at 01:05 +0000, Ben Hutchings wrote:
> > Currently the driver only uses location values to maintain an ordered
> > list of filters. There is nothing to stop the list becoming longer
> > than the filer hardware can support - the driver will report an error,
> > but will not roll back the change!
> Sure that it does not do the rollback?
> In case of to much filters it should work this way:
> # Convert all in temp table
> # Compress temp table
> # Write out temp table => not enough space => discard temp table &
> remove filter from list
You're right, I must have misread the code previously. Therefore, I
withdraw this patch for the time being.
> > Make it reject location values >= MAX_FILER_IDX, consistent with the
> > range that gfar_get_cls_all() reports.
I do however think that this should be consistent, and I would like to
reserve some 'special' location values. But, for compatibility, it may
be necessary to use some other method to distinguish them (e.g. another
flow_type flag.)
Ben.
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Reviewed-by: Sebastian Pöhn <sebastian.poehn@googlemail.com>
> > ---
> > [Re-sent to what I hope is a current address for Sebastian.]
> >
> > This has not been tested in any way, as I don't have a suitable compiler
> > installed. Sebastian, please could you review this?
> Unfortunately I haven't too ...
> >
> > Ben.
> >
> > drivers/net/ethernet/freescale/gianfar_ethtool.c | 5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
> > index 5890f4b..5a3b2e5 100644
> > --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
> > +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
> > @@ -1692,8 +1692,9 @@ static int gfar_set_nfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
> > ret = gfar_set_hash_opts(priv, cmd);
> > break;
> > case ETHTOOL_SRXCLSRLINS:
> > - if (cmd->fs.ring_cookie != RX_CLS_FLOW_DISC &&
> > - cmd->fs.ring_cookie >= priv->num_rx_queues) {
> > + if ((cmd->fs.ring_cookie != RX_CLS_FLOW_DISC &&
> > + cmd->fs.ring_cookie >= priv->num_rx_queues) ||
> > + cmd->fs.location >= MAX_FILER_IDX) {
> > ret = -EINVAL;
> > break;
> > }
> > --
> > 1.7.4.4
> >
> >
>
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 14/14] Documentation/networking/ieee802154: update MAC chapter
From: Alexander Smirnov @ 2011-12-19 16:33 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, linux-zigbee-devel, netdev, Alexander Smirnov
In-Reply-To: <20111219163117.GA13123@avtobot.cybertron>
Update the documentation according to latest changes.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
Documentation/networking/ieee802154.txt | 57 +++++++++++++++++++++++++++----
1 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1dc1c24..df41468 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -4,15 +4,22 @@
Introduction
============
+The IEEE 802.15.4 working group focuses on standartization of bottom
+two layers: Medium Accsess Control (MAC) and Physical (PHY). And there
+are mainly two options available for upper layers:
+ - ZigBee - proprietary protocol from ZigBee Alliance
+ - 6LowPAN - IPv6 networking over low rate personal area networks
The Linux-ZigBee project goal is to provide complete implementation
-of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
+of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
of protocols for organizing Low-Rate Wireless Personal Area Networks.
-Currently only IEEE 802.15.4 layer is implemented. We have chosen
-to use plain Berkeley socket API, the generic Linux networking stack
-to transfer IEEE 802.15.4 messages and a special protocol over genetlink
-for configuration/management
+The stack is composed of three main parts:
+ - IEEE 802.15.4 layer; We have chosen to use plain Berkeley socket API,
+ the generic Linux networking stack to transfer IEEE 802.15.4 messages
+ and a special protocol over genetlink for configuration/management
+ - MAC - provides access to shared channel and reliable data delivery
+ - PHY - represents device drivers
Socket API
@@ -73,11 +80,47 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
SoftMAC
=======
-We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
-in software. This is currently WIP.
+The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it
+provides interface for drivers registration and management of slave interfaces.
+
+NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4
+stack interface for network sniffers (e.g. WireShark).
+
+This layer is going to be extended soon.
See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
+
+Device drivers API
+==================
+
+The include/net/mac802154.h defines following functions:
+ - struct ieee802154_dev *ieee802154_alloc_device
+ (size_t priv_size, struct ieee802154_ops *ops):
+ allocation of IEEE 802.15.4 compatible device
+
+ - void ieee802154_free_device(struct ieee802154_dev *dev):
+ freeing allocated device
+
+ - int ieee802154_register_device(struct ieee802154_dev *dev):
+ register PHY in the system
+
+ - void ieee802154_unregister_device(struct ieee802154_dev *dev):
+ freeing registered PHY
+
+Moreover IEEE 802.15.4 device operations structure should be filled.
+
+Fake drivers
+============
+
+In addition there are two drivers available which simulate real devices with
+HardMAC (fakehard) and SoftMAC (fakelb - IEEE 802.15.4 loopback driver)
+interfaces. This option provides possibility to test and debug stack without
+usage of real hardware.
+
+See sources in drivers/ieee802154 folder for more details.
+
+
6LoWPAN Linux implementation
============================
--
1.7.2.3
^ permalink raw reply related
* [PATCH 04/14] mac802154: TX data path
From: Alexander Smirnov @ 2011-12-19 16:33 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, linux-zigbee-devel, netdev, Alexander Smirnov
In-Reply-To: <20111219163117.GA13123@avtobot.cybertron>
Main TX data path implementation between upper and physical layers.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/mac802154/Makefile | 2 +-
net/mac802154/mac802154.h | 5 ++
net/mac802154/tx.c | 113 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 119 insertions(+), 1 deletions(-)
create mode 100644 net/mac802154/tx.c
diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
index e00fe47..490beef 100644
--- a/net/mac802154/Makefile
+++ b/net/mac802154/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_MAC802154) += mac802154.o
-mac802154-objs := ieee802154_dev.o rx.o
+mac802154-objs := ieee802154_dev.o rx.o tx.o
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index 16f96f1..97f9155 100644
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@ -58,4 +58,9 @@ enum {
#define mac802154_to_priv(_hw) container_of(_hw, struct mac802154_priv, hw)
+#define MAC802154_MAX_XMIT_ATTEMPTS 3
+
+netdev_tx_t mac802154_tx(struct mac802154_priv *priv, struct sk_buff *skb,
+ u8 page, u8 chan);
+
#endif /* MAC802154_H */
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
new file mode 100644
index 0000000..ee0a9ed
--- /dev/null
+++ b/net/mac802154/tx.c
@@ -0,0 +1,113 @@
+/*
+ * Copyright 2007-2011 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
+ * Sergey Lapin <slapin@ossfans.org>
+ * Maxim Gorbachyov <maxim.gorbachev@siemens.com>
+ * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
+ */
+
+#include <linux/netdevice.h>
+#include <linux/if_arp.h>
+#include <linux/crc-ccitt.h>
+
+#include <net/mac802154.h>
+#include <net/wpan-phy.h>
+
+#include "mac802154.h"
+
+struct xmit_work {
+ struct sk_buff *skb;
+ struct work_struct work;
+ struct mac802154_priv *priv;
+ u8 page;
+ u8 chan;
+ u8 xmit_attempts;
+};
+
+static void mac802154_xmit_worker(struct work_struct *work)
+{
+ struct xmit_work *xw = container_of(work, struct xmit_work, work);
+ int res;
+
+ mutex_lock(&xw->priv->phy->pib_lock);
+ if (xw->priv->phy->current_channel != xw->chan ||
+ xw->priv->phy->current_page != xw->page) {
+ res = xw->priv->ops->set_channel(&xw->priv->hw,
+ xw->page,
+ xw->chan);
+ if (res) {
+ pr_debug("(%s): set_channel failed\n", __func__);
+ goto out;
+ }
+ }
+
+ res = xw->priv->ops->xmit(&xw->priv->hw, xw->skb);
+
+out:
+ mutex_unlock(&xw->priv->phy->pib_lock);
+
+ if (res) {
+ if (xw->xmit_attempts++ < MAC802154_MAX_XMIT_ATTEMPTS) {
+ queue_work(xw->priv->dev_workqueue, &xw->work);
+ return;
+ } else
+ pr_debug("(%s): transmission failed for %d times",
+ __func__, MAC802154_MAX_XMIT_ATTEMPTS);
+ }
+
+ dev_kfree_skb(xw->skb);
+
+ kfree(xw);
+}
+
+netdev_tx_t mac802154_tx(struct mac802154_priv *priv, struct sk_buff *skb,
+ u8 page, u8 chan)
+{
+ struct xmit_work *work;
+
+ if (WARN_ON(!(priv->phy->channels_supported[page] &
+ (1 << chan))))
+ return NETDEV_TX_OK;
+
+ if (!(priv->hw.flags & IEEE802154_HW_OMIT_CKSUM)) {
+ u16 crc = crc_ccitt(0, skb->data, skb->len);
+ u8 *data = skb_put(skb, 2);
+ data[0] = crc & 0xff;
+ data[1] = crc >> 8;
+ }
+
+ if (skb_cow_head(skb, priv->hw.extra_tx_headroom)) {
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
+ work = kzalloc(sizeof(struct xmit_work), GFP_ATOMIC);
+ if (!work)
+ return NETDEV_TX_BUSY;
+
+ INIT_WORK(&work->work, mac802154_xmit_worker);
+ work->skb = skb;
+ work->priv = priv;
+ work->page = page;
+ work->chan = chan;
+ work->xmit_attempts = 0;
+
+ queue_work(priv->dev_workqueue, &work->work);
+
+ return NETDEV_TX_OK;
+}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 03/14] mac802154: RX data path
From: Alexander Smirnov @ 2011-12-19 16:33 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, linux-zigbee-devel, netdev, Alexander Smirnov
In-Reply-To: <20111219163117.GA13123@avtobot.cybertron>
Main RX data path implementation between physical and mac layers.
Both contexts are supported: interrupt (data processed via worker)
and non-interrupt (data processed directly).
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
include/net/ieee802154_netdev.h | 2 +
include/net/mac802154.h | 4 ++
net/mac802154/Makefile | 2 +-
net/mac802154/rx.c | 106 +++++++++++++++++++++++++++++++++++++++
4 files changed, 113 insertions(+), 1 deletions(-)
create mode 100644 net/mac802154/rx.c
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index 5743055..12a7ee4 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -26,6 +26,8 @@
#ifndef IEEE802154_NETDEVICE_H
#define IEEE802154_NETDEVICE_H
+#include <net/af_ieee802154.h>
+
/*
* A control block of skb passed between the ARPHRD_IEEE802154 device
* and other stack parts.
diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index 2733dab..4e9f042 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -142,4 +142,8 @@ struct ieee802154_ops {
int ieee802154_register_device(struct ieee802154_dev *dev);
void ieee802154_unregister_device(struct ieee802154_dev *dev);
+void ieee802154_rx(struct ieee802154_dev *dev, struct sk_buff *skb, u8 lqi);
+void ieee802154_rx_irqsafe(struct ieee802154_dev *dev, struct sk_buff *skb,
+ u8 lqi);
+
#endif /* NET_MAC802154_H */
diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
index cda9393..e00fe47 100644
--- a/net/mac802154/Makefile
+++ b/net/mac802154/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_MAC802154) += mac802154.o
-mac802154-objs := ieee802154_dev.o
+mac802154-objs := ieee802154_dev.o rx.o
diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
new file mode 100644
index 0000000..d469bef
--- /dev/null
+++ b/net/mac802154/rx.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright (C) 2007-2011 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Pavel Smolenskiy <pavel.smolenskiy@gmail.com>
+ * Maxim Gorbachyov <maxim.gorbachev@siemens.com>
+ * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
+ * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/workqueue.h>
+#include <linux/netdevice.h>
+#include <linux/crc-ccitt.h>
+
+#include <net/mac802154.h>
+#include <net/ieee802154_netdev.h>
+
+#include "mac802154.h"
+
+static void
+mac802154_subif_rx(struct ieee802154_dev *hw, struct sk_buff *skb, u8 lqi)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(hw);
+
+ BUG_ON(!skb);
+
+ mac_cb(skb)->lqi = lqi;
+ skb->protocol = htons(ETH_P_IEEE802154);
+ skb_reset_mac_header(skb);
+
+ BUILD_BUG_ON(sizeof(struct ieee802154_mac_cb) > sizeof(skb->cb));
+
+ if (!(priv->hw.flags & IEEE802154_HW_OMIT_CKSUM)) {
+ u16 crc;
+
+ if (skb->len < 2) {
+ pr_debug("(%s): got invalid frame\n", __func__);
+ goto out;
+ }
+ crc = crc_ccitt(0, skb->data, skb->len);
+ if (crc) {
+ pr_debug("(%s): CRC mismatch\n", __func__);
+ goto out;
+ }
+ skb_trim(skb, skb->len - 2); /* CRC */
+ }
+
+out:
+ dev_kfree_skb(skb);
+ return;
+}
+
+struct rx_work {
+ struct sk_buff *skb;
+ struct work_struct work;
+ struct ieee802154_dev *dev;
+ u8 lqi;
+};
+
+static void mac802154_rx_worker(struct work_struct *work)
+{
+ struct rx_work *rw = container_of(work, struct rx_work, work);
+ struct sk_buff *skb = rw->skb;
+
+ mac802154_subif_rx(rw->dev, skb, rw->lqi);
+ kfree(rw);
+}
+
+void ieee802154_rx_irqsafe(struct ieee802154_dev *dev,
+ struct sk_buff *skb, u8 lqi)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(dev);
+ struct rx_work *work = kzalloc(sizeof(struct rx_work), GFP_ATOMIC);
+
+ if (!work)
+ return;
+
+ INIT_WORK(&work->work, mac802154_rx_worker);
+ work->skb = skb;
+ work->dev = dev;
+ work->lqi = lqi;
+
+ queue_work(priv->dev_workqueue, &work->work);
+}
+EXPORT_SYMBOL(ieee802154_rx_irqsafe);
+
+void mac802154_rx(struct ieee802154_dev *dev, struct sk_buff *skb, u8 lqi)
+{
+ mac802154_subif_rx(dev, skb, lqi);
+}
+EXPORT_SYMBOL(mac802154_rx);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 02/14] mac802154: allocation of ieee802154 device
From: Alexander Smirnov @ 2011-12-19 16:33 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, linux-zigbee-devel, netdev, Alexander Smirnov
In-Reply-To: <20111219163117.GA13123@avtobot.cybertron>
Interface for device drivers to allocate and register ieee802154
compatible devices.
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
net/Kconfig | 1 +
net/Makefile | 1 +
net/mac802154/Kconfig | 16 +++++
net/mac802154/Makefile | 2 +
net/mac802154/ieee802154_dev.c | 124 ++++++++++++++++++++++++++++++++++++++++
net/mac802154/mac802154.h | 61 ++++++++++++++++++++
6 files changed, 205 insertions(+), 0 deletions(-)
create mode 100644 net/mac802154/Kconfig
create mode 100644 net/mac802154/Makefile
create mode 100644 net/mac802154/ieee802154_dev.c
create mode 100644 net/mac802154/mac802154.h
diff --git a/net/Kconfig b/net/Kconfig
index 2d99873..b8d4590 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -211,6 +211,7 @@ source "net/econet/Kconfig"
source "net/wanrouter/Kconfig"
source "net/phonet/Kconfig"
source "net/ieee802154/Kconfig"
+source "net/mac802154/Kconfig"
source "net/sched/Kconfig"
source "net/dcb/Kconfig"
source "net/dns_resolver/Kconfig"
diff --git a/net/Makefile b/net/Makefile
index acdde49..1969e93 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -60,6 +60,7 @@ ifneq ($(CONFIG_DCB),)
obj-y += dcb/
endif
obj-$(CONFIG_IEEE802154) += ieee802154/
+obj-$(CONFIG_MAC802154) += mac802154/
ifeq ($(CONFIG_NET),y)
obj-$(CONFIG_SYSCTL) += sysctl_net.o
diff --git a/net/mac802154/Kconfig b/net/mac802154/Kconfig
new file mode 100644
index 0000000..a967dda
--- /dev/null
+++ b/net/mac802154/Kconfig
@@ -0,0 +1,16 @@
+config MAC802154
+ tristate "Generic IEEE 802.15.4 Soft Networking Stack (mac802154)"
+ depends on IEEE802154 && EXPERIMENTAL
+ select CRC_CCITT
+ ---help---
+ This option enables the hardware independent IEEE 802.15.4
+ networking stack for SoftMAC devices (the ones implementing
+ only PHY level of IEEE 802.15.4 standard).
+
+ Note: this implementation is neither certified, nor feature
+ complete! Compatibility with other implementations hasn't
+ been tested yet!
+
+ If you plan to use HardMAC IEEE 802.15.4 devices, you can
+ say N here. Alternatievly you can say M to compile it as
+ module.
diff --git a/net/mac802154/Makefile b/net/mac802154/Makefile
new file mode 100644
index 0000000..cda9393
--- /dev/null
+++ b/net/mac802154/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_MAC802154) += mac802154.o
+mac802154-objs := ieee802154_dev.o
diff --git a/net/mac802154/ieee802154_dev.c b/net/mac802154/ieee802154_dev.c
new file mode 100644
index 0000000..2bd1034
--- /dev/null
+++ b/net/mac802154/ieee802154_dev.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2007-2011 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <net/route.h>
+
+#include <net/mac802154.h>
+#include <net/wpan-phy.h>
+
+#include "mac802154.h"
+
+struct ieee802154_dev *ieee802154_alloc_device(size_t priv_size,
+ struct ieee802154_ops *ops)
+{
+ struct wpan_phy *phy;
+ struct mac802154_priv *priv;
+
+ if (!ops || !ops->xmit || !ops->ed || !ops->start ||
+ !ops->stop || !ops->set_channel) {
+ printk(KERN_ERR
+ "undefined IEEE802.15.4 device operations\n");
+ return NULL;
+ }
+
+ phy = wpan_phy_alloc(ALIGN(sizeof(*priv), NETDEV_ALIGN) + priv_size);
+ if (!phy) {
+ printk(KERN_ERR
+ "failure to allocate master IEEE802.15.4 device\n");
+ return NULL;
+ }
+
+ priv = wpan_phy_priv(phy);
+ priv->hw.phy = priv->phy = phy;
+ priv->hw.priv = (char *)priv + ALIGN(sizeof(*priv), NETDEV_ALIGN);
+ priv->ops = ops;
+
+ INIT_LIST_HEAD(&priv->slaves);
+ mutex_init(&priv->slaves_mtx);
+
+ return &priv->hw;
+}
+EXPORT_SYMBOL(ieee802154_alloc_device);
+
+void ieee802154_free_device(struct ieee802154_dev *hw)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(hw);
+
+ wpan_phy_free(priv->phy);
+
+ mutex_destroy(&priv->slaves_mtx);
+}
+EXPORT_SYMBOL(ieee802154_free_device);
+
+
+int ieee802154_register_device(struct ieee802154_dev *dev)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(dev);
+ int rc = -ENOMEM;
+
+ priv->dev_workqueue =
+ create_singlethread_workqueue(wpan_phy_name(priv->phy));
+ if (!priv->dev_workqueue)
+ goto out;
+
+ wpan_phy_set_dev(priv->phy, priv->hw.parent);
+
+ rc = wpan_phy_register(priv->phy);
+ if (rc < 0)
+ goto out_wq;
+
+ rtnl_lock();
+
+ mutex_lock(&priv->slaves_mtx);
+ priv->running = MAC802154_DEVICE_RUN;
+ mutex_unlock(&priv->slaves_mtx);
+
+ rtnl_unlock();
+
+ return 0;
+
+out_wq:
+ destroy_workqueue(priv->dev_workqueue);
+out:
+ return rc;
+}
+EXPORT_SYMBOL(ieee802154_register_device);
+
+void ieee802154_unregister_device(struct ieee802154_dev *dev)
+{
+ struct mac802154_priv *priv = mac802154_to_priv(dev);
+
+ flush_workqueue(priv->dev_workqueue);
+ destroy_workqueue(priv->dev_workqueue);
+
+ rtnl_lock();
+
+ mutex_lock(&priv->slaves_mtx);
+ priv->running = MAC802154_DEVICE_STOPPED;
+ mutex_unlock(&priv->slaves_mtx);
+
+ rtnl_unlock();
+
+ wpan_phy_unregister(priv->phy);
+}
+EXPORT_SYMBOL(ieee802154_unregister_device);
+
+MODULE_DESCRIPTION("IEEE 802.15.4 implementation");
+MODULE_LICENSE("GPL v2");
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
new file mode 100644
index 0000000..16f96f1
--- /dev/null
+++ b/net/mac802154/mac802154.h
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2007-2011 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Written by:
+ * Pavel Smolenskiy <pavel.smolenskiy@gmail.com>
+ * Maxim Gorbachyov <maxim.gorbachev@siemens.com>
+ * Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
+ * Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
+ */
+#ifndef MAC802154_H
+#define MAC802154_H
+
+struct mac802154_priv {
+ struct ieee802154_dev hw;
+ struct ieee802154_ops *ops;
+
+ struct wpan_phy *phy;
+
+ int open_count;
+ /* As in mac80211 slaves list is modified:
+ * 1) under the RTNL
+ * 2) protected by slaves_mtx;
+ * 3) in an RCU manner
+ *
+ * So atomic readers can use any of this protection methods
+ */
+ struct list_head slaves;
+ struct mutex slaves_mtx;
+ /* This one is used for scanning and other
+ * jobs not to be interfered with serial driver */
+ struct workqueue_struct *dev_workqueue;
+
+ /*
+ * These flags are also modified under slaves_mtx and RTNL,
+ * so you can read them using any of protection methods.
+ */
+ /* SoftMAC device is registered and running. One can add subinterfaces. */
+ unsigned running: 1;
+};
+
+enum {
+ MAC802154_DEVICE_STOPPED,
+ MAC802154_DEVICE_RUN,
+};
+
+#define mac802154_to_priv(_hw) container_of(_hw, struct mac802154_priv, hw)
+
+#endif /* MAC802154_H */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 01/14] mac802154: basic ieee802.15.4 device structures
From: Alexander Smirnov @ 2011-12-19 16:33 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, linux-zigbee-devel, netdev, Alexander Smirnov
In-Reply-To: <20111219163117.GA13123@avtobot.cybertron>
The IEEE 802.15.4 Working Group focuses on the standardization of the
bottom two layers of ISO/OSI protocol stack: Physical (PHY) and MAC.
The MAC layer provides access control to a shared channel and reliable
data delivery. The main functions performed by the MAC sublayer are:
association and disassociation, security control, optional star
network topology functions, such as beacon generation and Guaranteed
Time Slots (GTSs) management, generation of ACK frames (if used), and,
finally, application support for the two possible network topologies
described in the standard.
This is an initial commit which describes main data structures needed
for ieee802.15.4 compatible devices representation in MAC layer and
callbacks that the driver may, or in some cases, must handle, for
example to transmit a frame
Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
---
include/net/mac802154.h | 145 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 145 insertions(+), 0 deletions(-)
create mode 100644 include/net/mac802154.h
diff --git a/include/net/mac802154.h b/include/net/mac802154.h
new file mode 100644
index 0000000..2733dab
--- /dev/null
+++ b/include/net/mac802154.h
@@ -0,0 +1,145 @@
+/*
+ * IEEE802.15.4-2003 specification
+ *
+ * Copyright (C) 2007-2011 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef NET_MAC802154_H
+#define NET_MAC802154_H
+
+#include <net/af_ieee802154.h>
+
+/**
+ * enum ieee802154_hw_addr_filt_flags - hardware flags
+ *
+ * These flags are used to indicate changed address settings from
+ * the stack to the hardware.
+ *
+ * @IEEE802515_SADDR_CHANGED:
+ * Indicates that the Short Address changed
+ *
+ * @IEEE802515_IEEEADDR_CHANGED:
+ * Indicates that the IEEE Address changed
+ *
+ * @IEEE802515_PANID_CHANGED:
+ * Indicates that the PAN ID changed
+ *
+ * @IEEE802515_PANC_CHANGED:
+ * Indicates that PAN Coordinator status changed
+ */
+enum ieee802154_hw_addr_filt_flags {
+ IEEE802515_SADDR_CHANGED = 1 << 0,
+ IEEE802515_IEEEADDR_CHANGED = 1 << 1,
+ IEEE802515_PANID_CHANGED = 1 << 2,
+ IEEE802515_PANC_CHANGED = 1 << 3,
+};
+
+struct ieee802154_hw_addr_filt {
+ u16 pan_id;
+ u16 short_addr;
+ u8 ieee_addr[IEEE802154_ADDR_LEN];
+ u8 pan_coord;
+};
+
+struct ieee802154_dev {
+ /* filled by the driver */
+ int extra_tx_headroom; /* headroom to reserve for tx skb */
+ u32 flags; /* Flags for device to set */
+ struct device *parent;
+
+ /* filled by mac802154 core */
+ struct ieee802154_hw_addr_filt hw_filt;
+ void *priv; /* driver-specific data */
+ struct wpan_phy *phy;
+};
+
+/* Checksum is in hardware and is omitted from packet */
+/**
+ * enum ieee802154_hw_flags - hardware flags
+ *
+ * These flags are used to indicate hardware capabilities to
+ * the stack. Generally, flags here should have their meaning
+ * done in a way that the simplest hardware doesn't need setting
+ * any particular flags. There are some exceptions to this rule,
+ * however, so you are advised to review these flags carefully.
+ *
+ * @IEEE802154_HW_OMIT_CKSUM:
+ * Indicates that receiver omits FCS and transmitter will add
+ * FCS on it's own.
+ *
+ * @IEEE802154_HW_AACK:
+ * Indicates that receiver will autorespond with ACK frames.
+ */
+enum ieee802154_hw_flags {
+ IEEE802154_HW_OMIT_CKSUM = 1 << 0,
+ IEEE802154_HW_AACK = 1 << 1,
+};
+
+/**
+ * struct ieee802154_ops - callbacks from mac802154 to the driver
+ *
+ * This structure contains various callbacks that the driver may
+ * handle or, in some cases, must handle, for example to transmit
+ * a frame.
+ *
+ * @start: Handler that 802.15.4 module calls for device initialisation.
+ * This function is called before the first interface is attached.
+ *
+ * @stop: Handler that 802.15.4 module calls for device cleanup
+ * This function is called after the last interface is removed.
+ *
+ * @xmit: Handler that 802.15.4 module calls for each transmitted frame.
+ * skb cntains the buffer starting from the IEEE 802.15.4 header.
+ * The low-level driver should send the frame based on available
+ * configuration.
+ * This function should return zero or negative errno.
+ * Called with pib_lock held.
+ *
+ * @ed: Handler that 802.15.4 module calls for Energy Detection.
+ * This function should place the value for detected energy
+ * (usually device-dependant) in the level pointer and return
+ * either zero or negative errno.
+ * Called with pib_lock held.
+ *
+ * @set_channel: Set radio for listening on specific channel.
+ * Set the device for listening on specified channel.
+ * Returns either zero, or negative errno.
+ * Called with pib_lock held.
+ *
+ * @set_hw_addr_filt: Set radio for listening on specific address.
+ * Set the device for listening on specified address.
+ * Returns either zero, or negative errno.
+ */
+struct ieee802154_ops {
+ struct module *owner;
+ int (*start)(struct ieee802154_dev *dev);
+ void (*stop)(struct ieee802154_dev *dev);
+ int (*xmit)(struct ieee802154_dev *dev,
+ struct sk_buff *skb);
+ int (*ed)(struct ieee802154_dev *dev, u8 *level);
+ int (*set_channel)(struct ieee802154_dev *dev,
+ int page,
+ int channel);
+ int (*set_hw_addr_filt)(struct ieee802154_dev *dev,
+ struct ieee802154_hw_addr_filt *filt,
+ unsigned long changed);
+ int (*ieee_addr)(struct ieee802154_dev *dev,
+ u8 addr[IEEE802154_ADDR_LEN]);
+};
+
+int ieee802154_register_device(struct ieee802154_dev *dev);
+void ieee802154_unregister_device(struct ieee802154_dev *dev);
+
+#endif /* NET_MAC802154_H */
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2] ARM: net: JIT compiler for packet filters
From: Uwe Kleine-König @ 2011-12-19 15:33 UTC (permalink / raw)
To: Dave Martin; +Cc: Mircea Gherzan, netdev, linux-arm-kernel
In-Reply-To: <20111219152418.GF2031@linaro.org>
Hello,
On Mon, Dec 19, 2011 at 03:24:18PM +0000, Dave Martin wrote:
> On Mon, Dec 19, 2011 at 04:19:58PM +0100, Uwe Kleine-K?nig wrote:
> > On Mon, Dec 19, 2011 at 12:50:21PM +0000, Dave Martin wrote:
> > > On Mon, Dec 19, 2011 at 09:40:30AM +0100, Mircea Gherzan wrote:
> > > > Based of Matt Evans's PPC64 implementation.
> > > Note that it's fine to have the JIT generating ARM code, even if the rest
> > > if the kernel is Thumb-2. This would only start to cause problems if we
> > > want to do things like set kprobes in the JITted code, or unwind out of
> > > the JITted code.
> > or use a CPU that doesn't speak ARM (e.g. v7M)
>
> Indeed... I was assuming though that that would be out of scope for the
> first iteration of this code.
Right, depending on !THUMB2 is fine. Only generating ARM code with
THUMB2=y is not.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH series v1] IEEE 802.15.4 MAC layer basic implementation
From: Alexander Smirnov @ 2011-12-19 16:31 UTC (permalink / raw)
To: davem; +Cc: netdev, dbaryshkov, linux-zigbee-devel, alex.bluesman.smirnov
Hi all,
the following patch series add basic support for IEEE 802.15.4 Medium Access
Control layer.
The IEEE 802.15.4 Working Group focuses on the standardization of the
bottom two layers of ISO/OSI protocol stack: Physical (PHY) and MAC.
The MAC layer provides access control to a shared channel and reliable
data delivery.
This series provide only basic features:
- interface for drivers registration
- RX/TX datapaths
- reduced mlme operations
- monitor device type support (used by network sniffers, e.g. Wireshark)
- IEEE 802.15.4 loopback driver
- documentation update
--
Since last post, series has been reworked to provide support for monitor device
and loopback driver only.
--
The following changes since commit d1d182e00d72300e05b18e28372fab003d8d4a58:
wimax/i2400m: remove an unused variable (2011-12-16 15:57:03 -0500)
are available in the git repository at:
git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee/kernel to_upstream
Alexander Smirnov (14):
mac802154: basic ieee802.15.4 device structures
mac802154: allocation of ieee802154 device
mac802154: RX data path
mac802154: TX data path
mac802154: define reduced mlme operations
mac802154: slave interfaces definition
mac802154: reduced mlme operations
mac802154: basic mib support
ieee802154: remove ieee802154 policy from globals
ieee802154: interface type to be added
mac802154: slaves manipulation routine
mac802154: monitor device support
drivers/ieee802154: IEEE 802.15.4 loopback driver
Documentation/networking/ieee802154: update MAC chapter
Documentation/networking/ieee802154.txt | 57 ++++++-
drivers/ieee802154/Kconfig | 8 +
drivers/ieee802154/Makefile | 1 +
drivers/ieee802154/fakelb.c | 287 +++++++++++++++++++++++++++++++
include/linux/if_arp.h | 1 +
include/linux/nl802154.h | 8 +-
include/net/ieee802154_netdev.h | 22 ++-
include/net/mac802154.h | 153 ++++++++++++++++
include/net/wpan-phy.h | 4 +-
net/Kconfig | 1 +
net/Makefile | 1 +
net/ieee802154/ieee802154.h | 2 +
net/ieee802154/nl-phy.c | 10 +-
net/ieee802154/wpan-class.c | 1 +
net/mac802154/Kconfig | 16 ++
net/mac802154/Makefile | 2 +
net/mac802154/ieee802154_dev.c | 265 ++++++++++++++++++++++++++++
net/mac802154/mac802154.h | 102 +++++++++++
net/mac802154/mac_cmd.c | 43 +++++
net/mac802154/mib.c | 96 ++++++++++
net/mac802154/monitor.c | 115 ++++++++++++
net/mac802154/rx.c | 107 ++++++++++++
net/mac802154/tx.c | 113 ++++++++++++
23 files changed, 1402 insertions(+), 13 deletions(-)
create mode 100644 drivers/ieee802154/fakelb.c
create mode 100644 include/net/mac802154.h
create mode 100644 net/mac802154/Kconfig
create mode 100644 net/mac802154/Makefile
create mode 100644 net/mac802154/ieee802154_dev.c
create mode 100644 net/mac802154/mac802154.h
create mode 100644 net/mac802154/mac_cmd.c
create mode 100644 net/mac802154/mib.c
create mode 100644 net/mac802154/monitor.c
create mode 100644 net/mac802154/rx.c
create mode 100644 net/mac802154/tx.c
With best regards,
Alexander Smirnov
^ permalink raw reply
* Re: [PATCH v2] ARM: net: JIT compiler for packet filters
From: Dave Martin @ 2011-12-19 15:24 UTC (permalink / raw)
To: Uwe Kleine-K?nig; +Cc: Mircea Gherzan, netdev, linux-arm-kernel
In-Reply-To: <20111219151958.GU24496@pengutronix.de>
On Mon, Dec 19, 2011 at 04:19:58PM +0100, Uwe Kleine-K?nig wrote:
> On Mon, Dec 19, 2011 at 12:50:21PM +0000, Dave Martin wrote:
> > On Mon, Dec 19, 2011 at 09:40:30AM +0100, Mircea Gherzan wrote:
> > > Based of Matt Evans's PPC64 implementation.
> > >
> > > Supports only ARM mode with EABI.
> > >
> > > Supports both little and big endian. Depends on the support for
> > > unaligned loads on ARMv7. Does not support all the BPF opcodes
> > > that deal with ancillary data. The scratch memory of the filter
> > > lives on the stack.
> > >
> > > Enabled in the same way as for x86-64 and PPC64:
> > >
> > > echo 1 > /proc/sys/net/core/bpf_jit_enable
> > >
> > > A value greater than 1 enables opcode output.
> > >
> > > Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
> > > ---
> >
> > Interesting patch... I haven't reviewed in detail, but I have a few
> > quick comments.
> >
> > >
> > > Changes in v2:
> > > * enable the compiler ony for ARMv5+ because of the BLX instruction
> > > * use the same comparison for the ARM version checks
> > > * use misaligned accesses on ARMv6
> >
> > You probably want to change the commit message now to reflect this.
> >
> > > * fix the SEEN_MEM
> > > * fix the mem_words_used()
> > >
> > > arch/arm/Kconfig | 1 +
> > > arch/arm/Makefile | 1 +
> > > arch/arm/net/Makefile | 3 +
> > > arch/arm/net/bpf_jit_32.c | 838 +++++++++++++++++++++++++++++++++++++++++++++
> > > arch/arm/net/bpf_jit_32.h | 174 ++++++++++
> > > 5 files changed, 1017 insertions(+), 0 deletions(-)
> > > create mode 100644 arch/arm/net/Makefile
> > > create mode 100644 arch/arm/net/bpf_jit_32.c
> > > create mode 100644 arch/arm/net/bpf_jit_32.h
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index abba5b8..ea65c41 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -30,6 +30,7 @@ config ARM
> > > select HAVE_SPARSE_IRQ
> > > select GENERIC_IRQ_SHOW
> > > select CPU_PM if (SUSPEND || CPU_IDLE)
> > > + select HAVE_BPF_JIT if (!THUMB2_KERNEL && AEABI)
> >
> > Have to tried your code with a Thumb-2 kernel?
> >
> > Quickly skimming though your patch, I don't see an obvious reason why we
> > can't have that working, though I haven't tried it yet.
> >
> > Note that it's fine to have the JIT generating ARM code, even if the rest
> > if the kernel is Thumb-2. This would only start to cause problems if we
> > want to do things like set kprobes in the JITted code, or unwind out of
> > the JITted code.
> or use a CPU that doesn't speak ARM (e.g. v7M)
Indeed... I was assuming though that that would be out of scope for the
first iteration of this code.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v2] ARM: net: JIT compiler for packet filters
From: Uwe Kleine-König @ 2011-12-19 15:19 UTC (permalink / raw)
To: Dave Martin; +Cc: Mircea Gherzan, netdev, linux-arm-kernel
In-Reply-To: <20111219125021.GA2031@linaro.org>
On Mon, Dec 19, 2011 at 12:50:21PM +0000, Dave Martin wrote:
> On Mon, Dec 19, 2011 at 09:40:30AM +0100, Mircea Gherzan wrote:
> > Based of Matt Evans's PPC64 implementation.
> >
> > Supports only ARM mode with EABI.
> >
> > Supports both little and big endian. Depends on the support for
> > unaligned loads on ARMv7. Does not support all the BPF opcodes
> > that deal with ancillary data. The scratch memory of the filter
> > lives on the stack.
> >
> > Enabled in the same way as for x86-64 and PPC64:
> >
> > echo 1 > /proc/sys/net/core/bpf_jit_enable
> >
> > A value greater than 1 enables opcode output.
> >
> > Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
> > ---
>
> Interesting patch... I haven't reviewed in detail, but I have a few
> quick comments.
>
> >
> > Changes in v2:
> > * enable the compiler ony for ARMv5+ because of the BLX instruction
> > * use the same comparison for the ARM version checks
> > * use misaligned accesses on ARMv6
>
> You probably want to change the commit message now to reflect this.
>
> > * fix the SEEN_MEM
> > * fix the mem_words_used()
> >
> > arch/arm/Kconfig | 1 +
> > arch/arm/Makefile | 1 +
> > arch/arm/net/Makefile | 3 +
> > arch/arm/net/bpf_jit_32.c | 838 +++++++++++++++++++++++++++++++++++++++++++++
> > arch/arm/net/bpf_jit_32.h | 174 ++++++++++
> > 5 files changed, 1017 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/net/Makefile
> > create mode 100644 arch/arm/net/bpf_jit_32.c
> > create mode 100644 arch/arm/net/bpf_jit_32.h
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index abba5b8..ea65c41 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -30,6 +30,7 @@ config ARM
> > select HAVE_SPARSE_IRQ
> > select GENERIC_IRQ_SHOW
> > select CPU_PM if (SUSPEND || CPU_IDLE)
> > + select HAVE_BPF_JIT if (!THUMB2_KERNEL && AEABI)
>
> Have to tried your code with a Thumb-2 kernel?
>
> Quickly skimming though your patch, I don't see an obvious reason why we
> can't have that working, though I haven't tried it yet.
>
> Note that it's fine to have the JIT generating ARM code, even if the rest
> if the kernel is Thumb-2. This would only start to cause problems if we
> want to do things like set kprobes in the JITted code, or unwind out of
> the JITted code.
or use a CPU that doesn't speak ARM (e.g. v7M)
> It's just necessary to make sure that calls/returns into/out of the
> JITted code are handled correctly. You don't seem to do any scary
> arithmetic or mov to or from pc or lr, and it doesn't look like you ever
> call back into the kernel from JITted code, so the implementation is
> probably safe for ARM/Thumb interworking already (if I've understood
> correctly).
>
> It doesn't look hard to port the JIT to generate Thumb-2 code directly
> either -- but I suggest not to worry about that initially. So long as
> the ARM-based JIT works in a Thumb-2 kernel, it will be useful.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] sctp: Do not account for sizeof(struct sk_buff) in estimated rwnd
From: Thomas Graf @ 2011-12-19 14:11 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: linux-sctp, David S. Miller, netdev, Thomas Graf
When checking whether a DATA chunk fits into the estimated rwnd a
full sizeof(struct sk_buff) is added to the needed chunk size. This
quickly exhausts the available rwnd space and leads to packets being
sent which are much below the PMTU limit. This can lead to much worse
performance.
The reason for this behaviour was to avoid putting too much memory
pressure on the receiver. The concept is not completely irational
because a Linux receiver does in fact clone an skb for each DATA chunk
delivered. However, Linux also reserves half the available socket
buffer space for data structures therefore usage of it is already
accounted for.
When proposing to change this the last time it was noted that this
behaviour was introduced to solve a performance issue caused by rwnd
overusage in combination with small DATA chunks.
Trying to reproduce this I found that with the sk_buff overhead removed,
the performance would improve significantly unless socket buffer limits
are increased.
The following numbers have been gathered using a patched iperf
supporting SCTP over a live 1 Gbit ethernet network. The -l option
was used to limit DATA chunk sizes. The numbers listed are based on
the average of 3 test runs each. Default values have been used for
sk_(r|w)mem.
Chunk
Size Unpatched No Overhead
-------------------------------------
4 15.2 Kbit [!] 12.2 Mbit [!]
8 35.8 Kbit [!] 26.0 Mbit [!]
16 95.5 Kbit [!] 54.4 Mbit [!]
32 106.7 Mbit 102.3 Mbit
64 189.2 Mbit 188.3 Mbit
128 331.2 Mbit 334.8 Mbit
256 537.7 Mbit 536.0 Mbit
512 766.9 Mbit 766.6 Mbit
1024 810.1 Mbit 808.6 Mbit
Signed-off-by: Thomas Graf <tgraf@redhat.com>
---
net/sctp/output.c | 8 +-------
net/sctp/outqueue.c | 6 ++----
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 08b3cea..817174e 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -697,13 +697,7 @@ static void sctp_packet_append_data(struct sctp_packet *packet,
/* Keep track of how many bytes are in flight to the receiver. */
asoc->outqueue.outstanding_bytes += datasize;
- /* Update our view of the receiver's rwnd. Include sk_buff overhead
- * while updating peer.rwnd so that it reduces the chances of a
- * receiver running out of receive buffer space even when receive
- * window is still open. This can happen when a sender is sending
- * sending small messages.
- */
- datasize += sizeof(struct sk_buff);
+ /* Update our view of the receiver's rwnd. */
if (datasize < rwnd)
rwnd -= datasize;
else
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 14c2b06..cfeb1d4 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -411,8 +411,7 @@ void sctp_retransmit_mark(struct sctp_outq *q,
chunk->transport->flight_size -=
sctp_data_size(chunk);
q->outstanding_bytes -= sctp_data_size(chunk);
- q->asoc->peer.rwnd += (sctp_data_size(chunk) +
- sizeof(struct sk_buff));
+ q->asoc->peer.rwnd += sctp_data_size(chunk);
}
continue;
}
@@ -432,8 +431,7 @@ void sctp_retransmit_mark(struct sctp_outq *q,
* (Section 7.2.4)), add the data size of those
* chunks to the rwnd.
*/
- q->asoc->peer.rwnd += (sctp_data_size(chunk) +
- sizeof(struct sk_buff));
+ q->asoc->peer.rwnd += sctp_data_size(chunk);
q->outstanding_bytes -= sctp_data_size(chunk);
if (chunk->transport)
transport->flight_size -= sctp_data_size(chunk);
--
1.7.7.4
^ permalink raw reply related
* Re: linux-3.0.x regression with ipv4 routes having mtu
From: Steffen Klassert @ 2011-12-19 13:52 UTC (permalink / raw)
To: Timo Teräs; +Cc: David Miller, netdev
In-Reply-To: <4EEB5602.2060806@iki.fi>
On Fri, Dec 16, 2011 at 04:30:26PM +0200, Timo Teräs wrote:
> On 12/16/2011 02:21 PM, Steffen Klassert wrote:
> >
> > "ip route flush cache" does not even flush the routing cache,
> > it just markes the routing cache as invalid by changing the
> > rt_genid which make the old routes invisible. And since we don't
> > have rt_check_expire() anymore, we have to wait until we have
> > collected gc_thresh (1024) useless routes before rt_garbage_collect()
> > starts to remove some of them (btw. is this intentional).
> >
> > I think we need a trigger in rt_cache_invalidate() that expires
> > all cached pmtu values similar to the routing cache entries.
> > For a moment I thought we could just reset the __rt_peer_genid
> > value back to zero to mark all cached pmtu values as expired,
> > but that's apparently not save to do. So I came to no conclusion
> > how to fix this today. Any ideas?
>
> Oh, right. This problem is secondary. As long as the mtu value is
> reflected properly, I'll be happy :)
>
Well, "ip route flush cache" flushed the cached pmtu informations
in 2.6.38 and before, now it does not do it anymore. I guess
some users rely on the old behaviour, so it would be nice if we
could restore it. I think we can fix this by adding a pmtu_genid,
exactly in the same way as we have now the redirect_genid.
I'll give this a try.
^ permalink raw reply
* qeth_l3 build broken in net-next
From: Frank Blaschka @ 2011-12-19 13:20 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
qeth_l3 build is broken in net-next
drivers/s390/net/qeth_l3_main.c: In function 'qeth_l3_neigh_setup':
drivers/s390/net/qeth_l3_main.c:3277: error: 'struct neigh_parms' has no member named 'neigh_setup'
make[2]: *** [drivers/s390/net/qeth_l3_main.o] Error 1
make[1]: *** [drivers/s390/net] Error 2
make: *** [drivers/s390] Error 2
commit 5c3ddec73d01a1fae9409c197078cb02c42238c3
net: Remove unused neighbour layer ops.
cause the problem. Actually qeth_l3 uses neigh_setup.
Can you revert commit 5c3ddec73d01a1fae9409c197078cb02c42238c3 ?
Thx,
Frank
^ permalink raw reply
* tcp_close - why no WARN_ON ?
From: Christoph Paasch @ 2011-12-19 12:57 UTC (permalink / raw)
To: netdev
Hi all,
I am trying to understand the following code in tcp_close:
sock_orphan(sk);
/* It is the last release_sock in its life. It will remove backlog. */
release_sock(sk);
/* Now socket is owned by kernel and we acquire BH lock
to finish close. No need to check for user refs.
*/
local_bh_disable();
bh_lock_sock(sk);
WARN_ON(sock_owned_by_user(sk));
How is it possible that between release_sock(sk) and local_bh_disable(),
no other thread gets scheduled and calls lock_sock() and thus the
WARN_ON would be triggered ?
Can someone please point me to the lines of code that handle this ?
Thanks a lot,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--
^ permalink raw reply
* Re: [PATCH v2] ARM: net: JIT compiler for packet filters
From: Dave Martin @ 2011-12-19 12:50 UTC (permalink / raw)
To: Mircea Gherzan; +Cc: linux-arm-kernel, netdev
In-Reply-To: <1324284030-25540-1-git-send-email-mgherzan@gmail.com>
On Mon, Dec 19, 2011 at 09:40:30AM +0100, Mircea Gherzan wrote:
> Based of Matt Evans's PPC64 implementation.
>
> Supports only ARM mode with EABI.
>
> Supports both little and big endian. Depends on the support for
> unaligned loads on ARMv7. Does not support all the BPF opcodes
> that deal with ancillary data. The scratch memory of the filter
> lives on the stack.
>
> Enabled in the same way as for x86-64 and PPC64:
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
>
> A value greater than 1 enables opcode output.
>
> Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
> ---
Interesting patch... I haven't reviewed in detail, but I have a few
quick comments.
>
> Changes in v2:
> * enable the compiler ony for ARMv5+ because of the BLX instruction
> * use the same comparison for the ARM version checks
> * use misaligned accesses on ARMv6
You probably want to change the commit message now to reflect this.
> * fix the SEEN_MEM
> * fix the mem_words_used()
>
> arch/arm/Kconfig | 1 +
> arch/arm/Makefile | 1 +
> arch/arm/net/Makefile | 3 +
> arch/arm/net/bpf_jit_32.c | 838 +++++++++++++++++++++++++++++++++++++++++++++
> arch/arm/net/bpf_jit_32.h | 174 ++++++++++
> 5 files changed, 1017 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/net/Makefile
> create mode 100644 arch/arm/net/bpf_jit_32.c
> create mode 100644 arch/arm/net/bpf_jit_32.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index abba5b8..ea65c41 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -30,6 +30,7 @@ config ARM
> select HAVE_SPARSE_IRQ
> select GENERIC_IRQ_SHOW
> select CPU_PM if (SUSPEND || CPU_IDLE)
> + select HAVE_BPF_JIT if (!THUMB2_KERNEL && AEABI)
Have to tried your code with a Thumb-2 kernel?
Quickly skimming though your patch, I don't see an obvious reason why we
can't have that working, though I haven't tried it yet.
Note that it's fine to have the JIT generating ARM code, even if the rest
if the kernel is Thumb-2. This would only start to cause problems if we
want to do things like set kprobes in the JITted code, or unwind out of
the JITted code.
It's just necessary to make sure that calls/returns into/out of the
JITted code are handled correctly. You don't seem to do any scary
arithmetic or mov to or from pc or lr, and it doesn't look like you ever
call back into the kernel from JITted code, so the implementation is
probably safe for ARM/Thumb interworking already (if I've understood
correctly).
It doesn't look hard to port the JIT to generate Thumb-2 code directly
either -- but I suggest not to worry about that initially. So long as
the ARM-based JIT works in a Thumb-2 kernel, it will be useful.
[...]
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> new file mode 100644
> index 0000000..d2b86fa
> --- /dev/null
> +++ b/arch/arm/net/bpf_jit_32.c
[...]
> +static int build_body(struct jit_ctx *ctx)
> +{
[...]
> + case BPF_S_ALU_DIV_K:
> + /* K is not zero, it was previously checked */
> + emit_mov_i(ARM_R1, k, ctx);
> + goto div;
> + case BPF_S_ALU_DIV_X:
> + ctx->seen |= SEEN_X;
> + emit(ARM_CMP_I(r_X, 0), ctx);
> + emit_err_ret(ARM_COND_EQ, ctx);
> + emit(ARM_MOV_R(ARM_R1, r_X), ctx);
> +div:
> + ctx->seen |= SEEN_CALL;
> +
> + emit(ARM_MOV_R(ARM_R0, r_A), ctx);
> + emit_mov_i(r_scratch, (u32)__aeabi_uidiv, ctx);
> + emit(ARM_BLX_R(r_scratch), ctx);
> + emit(ARM_MOV_R(r_A, ARM_R0), ctx);
> + break;
I don't know how much division is used by the packet filter JIT. If
it gets used a significant amount, you might want to support hardware
divide for CPUs that have it:
Cortex-A15 and later processors may have hardware integer divide
support. You can check for its availability at runtime using by testing
the HWCAP_IDIVA (for ARM) or HWCAP_IDIVT (for Thumb) bits in elf_hwcap
(see arch/arm/include/asm/hwcap.h).
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH 01/11] SYSCTL: export root and set handling routines
From: Stanislav Kinsbursky @ 2011-12-19 12:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pavel Emelianov, neilb-l3A5Bk7waGM@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
James Bottomley, bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
In-Reply-To: <m18vm8g951.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
19.12.2011 14:15, Eric W. Biederman пишет:
> Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
>
>> 18.12.2011 02:25, Eric W. Biederman пишет:
>>> Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
>>>
>>>> These routines are required for making SUNRPC sysctl's per network namespace
>>>> context.
>>>
>>> Why does sunrpc require it's own sysctl root? You should be able to use
>>> the generic per network namespace root and call it good.
>>>
>>> What makes register_net_sysctl_table and register_net_sysctl_ro_table
>>> unsuitable for sunrpc. I skimmed through your patches and I haven't
>>> seen anything obvious.
>>>
>>> Eric
>>>
>>
>> Hello, Eric. Sorry for the lack of information.
>> I was considering two ways how to make these sysctl per net ns:
>>
>> 1) Use register_net_sysctl_table and register_net_sysctl_ro_table as you
>> mentioned. This was easy and cheap, but also means, than all user-space
>> programs, tuning SUNRPC will be broken (since all sysctl currently located
>> in"/proc/sys/sunprc/").
>
> Nope. That is a misunderstanding. register_net_sysctl_table works for
> anything under /proc/sys.
>
>> 2) Export sysctl root creation routines and make per-net SUNRPC sysctl
>> root. This approach allows to make any part of sysctl tree per namespace context
>> and thus leave user-space stuff unchanged.
>>
>> BTW, NFS and LockD also have it's sysctls ("/proc/sys/fs/nfs/").
>> And also because of them I've decided, that it would be better to export SYSCTL
>> root creation routines instead of breaking compatibility for all NFS layers by
>> moving all sysctl under /proc/sys/net/ directory.
>>
>> Do you feel that it was a bad decision?
>
> I think it was a misinformed decision.
>
> I fully support not breaking userspace by moving where the sysctls files
> are. If something sounds like I am suggesting moving sysctl files there
> is a miscommunication somewhere.
>
> The concept of a sysctl root as I had envisioned it and essentially as it
> is implemented was a per namespace sysctl tree. Those sysctl trees are
> then unioned together when presented to user space. There should only
> be one root per namespace.
>
> In practice what this means is that register_net_sysctl_table should
> work for any sysctl file anywhere under /proc/sys. I think
> register_net_sysctl_table is the right solution for your problem. The
> only possible caveat I can think of is you might hit Al's performance
> optimizations and need to create a common empty directory first with
> register_sysctl_paths.
>
>
Sorry, but I forgot to mention one more important goal I would like to achieve:
I want to manage sysctl's variables in context of mount owner, but not viewer one.
IOW imagine, that we have one two network namespaces: "A" and "B". Both of them
have it's own net sysctl's root. And we have per-net sysctl "/proc/sys/var".
And for ns "A" variable was set to 0, and for "B" - to 1.
And B's "/proc/sys/var" is accessible from "A" namespace
("/chroot_path/proc/sys/var" for example).
With this configuration I want to read "1" from both namespaces:
owner "B" (/proc/sys/var) and "A" ("/chroot_path/proc/sys/var").
Looks like simple using of register_net_sysctl_table doesn't allow me this,
because current net ns is used. And to achieve this goal I need my own sysctl
set for SUNRPC like it was done for network namespaces.
> ....
> That said since I am in the process of rewriting things some of this
> may change a little bit, but hopefully not in ways that immediately
> effect the users of register_sysctl_table.
>
> Don't use register_net_sysctl_ro_table. I think what the implementors
> actually wanted was register_net_sysctl_table(&init_net, ...) and didn't
> know it.
>
> Don't put subdirectories in your sysctl tables. Use a ctl_path to
> specify the entire directory where the files should show up. Generally
> the code is easier to read in that form, and the code is simpler to deal
> with if we don't have to worry about directories.
>
> Don't play with the sysctl roots. It is my intention to completely kill
> them off and replace them by moving the per net sysctl tree under
> /proc/<pid>/sys/. Leaving behind symlinks in /proc/sys/net and I guess
> ultimately in /proc/sys/sunrpc/ and /proc/sys/fs/nfs... Which actually
> seems to better describe your mental model.
>
I'm afraid, that this approach this not allow me to achieve the goal, mentioned
above, because current->nsproxy->net_ns will be used during lookup.
Or maybe I misunderstanding here?
> Thank you for mentioning /proc/sys/fs/nfs. That is a case I hadn't
> thought about. In thinking about it I see some deficiencies in my
> rewrite that I need to correct before I push that code.
>
Was glad to be usefull.
> Eric
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/2] tcp: refactor tcp_retransmit_skb() for a single return point
From: David Laight @ 2011-12-19 12:10 UTC (permalink / raw)
To: Satoru Moriya, netdev; +Cc: nhorman, davem, tgraf, Seiji Aguchi, dle-develop
In-Reply-To: <65795E11DBF1E645A09CEC7EAEE94B9CB5AFA650@USINDEVS02.corp.hds.com>
> This is just a cleanup patch for making easy to hook return value
> with a tracepoint.
Another way to temporarily add such a trace, is to temporarily
add a wrapper function.
David
^ permalink raw reply
* [PATCH net-next] be2net: Fix INTx processing for Lancer
From: Padmanabh Ratnakar @ 2011-12-19 11:53 UTC (permalink / raw)
To: netdev; +Cc: Padmanabh Ratnakar
Lancer does not have HW registers to indicate the EQ causing the INTx
interrupt. As a result EQE entries of one EQ may be consumed when interrupt
is caused by another EQ. Fix this by arming CQs at the end of NAPI poll
routine to regenerate the EQEs.
Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index b145a49..76f3a98 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1970,6 +1970,7 @@ static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
struct be_eq_obj *tx_eq = container_of(napi, struct be_eq_obj, napi);
struct be_adapter *adapter =
container_of(tx_eq, struct be_adapter, tx_eq);
+ struct be_mcc_obj *mcc_obj = &adapter->mcc_obj;
struct be_tx_obj *txo;
struct be_eth_tx_compl *txcp;
int tx_compl, mcc_compl, status = 0;
@@ -2006,12 +2007,19 @@ static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
mcc_compl = be_process_mcc(adapter, &status);
if (mcc_compl) {
- struct be_mcc_obj *mcc_obj = &adapter->mcc_obj;
be_cq_notify(adapter, mcc_obj->cq.id, true, mcc_compl);
}
napi_complete(napi);
+ /* Arm CQ again to regenerate EQEs for Lancer in INTx mode */
+ if (lancer_chip(adapter) && !msix_enabled(adapter)) {
+ for_all_tx_queues(adapter, txo, i)
+ be_cq_notify(adapter, txo->cq.id, true, 0);
+
+ be_cq_notify(adapter, mcc_obj->cq.id, true, 0);
+ }
+
be_eq_notify(adapter, tx_eq->q.id, true, false, 0);
adapter->drv_stats.tx_events++;
return 1;
--
1.6.0.2
^ permalink raw reply related
* [PATCH net-next] r8169: Support for byte queue limits
From: igorm @ 2011-12-19 10:28 UTC (permalink / raw)
To: netdev; +Cc: davem, nic_swsd, romieu, therbert, eric.dumazet, Igor Maravic
From: Igor Maravic <igorm@etf.rs>
Changes to r8169 to use byte queue limits.
Signed-off-by: Igor Maravic <igorm@etf.rs>
---
drivers/net/ethernet/realtek/r8169.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 36b2a4b..5fefcc3 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5326,6 +5326,7 @@ static void rtl8169_tx_clear(struct rtl8169_private *tp)
{
rtl8169_tx_clear_range(tp, tp->dirty_tx, NUM_TX_DESC);
tp->cur_tx = tp->dirty_tx = 0;
+ netdev_reset_queue(tp->dev);
}
static void rtl8169_schedule_work(struct net_device *dev, work_func_t task)
@@ -5535,6 +5536,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
opts[0] |= FirstFrag | LastFrag;
tp->tx_skb[entry].skb = skb;
}
+ netdev_sent_queue(dev, skb->len);
txd->opts2 = cpu_to_le32(opts[1]);
@@ -5624,6 +5626,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
void __iomem *ioaddr)
{
unsigned int dirty_tx, tx_left;
+ unsigned int bytes_compl = 0;
+ int tx_compl = 0;
dirty_tx = tp->dirty_tx;
smp_rmb();
@@ -5642,14 +5646,18 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb,
tp->TxDescArray + entry);
if (status & LastFrag) {
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += tx_skb->skb->len;
+ tx_compl++;
+ bytes_compl += tx_skb->skb->len;
dev_kfree_skb(tx_skb->skb);
tx_skb->skb = NULL;
}
dirty_tx++;
tx_left--;
}
+ dev->stats.tx_packets += tx_compl;
+ dev->stats.tx_bytes += bytes_compl;
+
+ netdev_completed_queue(dev, tx_compl, bytes_compl);
if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Eric Dumazet @ 2011-12-19 10:19 UTC (permalink / raw)
To: igorm; +Cc: netdev, davem, nic_swsd, romieu, therbert
In-Reply-To: <1324289373-4909-1-git-send-email-igorm@etf.rs>
Le lundi 19 décembre 2011 à 11:09 +0100, igorm@etf.rs a écrit :
> From: Igor Maravic <igorm@etf.rs>
>
> Changes to r8169 to use byte queue limits.
>
> Signed-off-by: Igor Maravic <igorm@etf.rs>
> ---
> drivers/net/ethernet/realtek/r8169.c | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 36b2a4b..1a6a12a 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -5326,6 +5326,7 @@ static void rtl8169_tx_clear(struct rtl8169_private *tp)
> {
> rtl8169_tx_clear_range(tp, tp->dirty_tx, NUM_TX_DESC);
> tp->cur_tx = tp->dirty_tx = 0;
> + netdev_reset_queue(tp->dev);
> }
>
> static void rtl8169_schedule_work(struct net_device *dev, work_func_t task)
> @@ -5546,6 +5547,8 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
>
> tp->cur_tx += frags + 1;
>
> + netdev_sent_queue(dev, skb->len);
> +
Hmm, thats a bit too late here. An interrupt could theorically free skb
right before your deref.
> wmb();
>
> RTL_W8(TxPoll, NPQ);
> @@ -5624,6 +5627,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
I believe its better to access skb _before_ the
txd->opts2 = cpu_to_le32(opts[1]);
wmb();
^ permalink raw reply
* Re: [PATCH 01/11] SYSCTL: export root and set handling routines
From: Eric W. Biederman @ 2011-12-19 10:15 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, James Bottomley,
bfields@fieldses.org, davem@davemloft.net, devel@openvz.org
In-Reply-To: <4EEEFC54.10700@parallels.com>
Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
> 18.12.2011 02:25, Eric W. Biederman пишет:
>> Stanislav Kinsbursky<skinsbursky@parallels.com> writes:
>>
>>> These routines are required for making SUNRPC sysctl's per network namespace
>>> context.
>>
>> Why does sunrpc require it's own sysctl root? You should be able to use
>> the generic per network namespace root and call it good.
>>
>> What makes register_net_sysctl_table and register_net_sysctl_ro_table
>> unsuitable for sunrpc. I skimmed through your patches and I haven't
>> seen anything obvious.
>>
>> Eric
>>
>
> Hello, Eric. Sorry for the lack of information.
> I was considering two ways how to make these sysctl per net ns:
>
> 1) Use register_net_sysctl_table and register_net_sysctl_ro_table as you
> mentioned. This was easy and cheap, but also means, than all user-space
> programs, tuning SUNRPC will be broken (since all sysctl currently located
> in"/proc/sys/sunprc/").
Nope. That is a misunderstanding. register_net_sysctl_table works for
anything under /proc/sys.
> 2) Export sysctl root creation routines and make per-net SUNRPC sysctl
> root. This approach allows to make any part of sysctl tree per namespace context
> and thus leave user-space stuff unchanged.
>
> BTW, NFS and LockD also have it's sysctls ("/proc/sys/fs/nfs/").
> And also because of them I've decided, that it would be better to export SYSCTL
> root creation routines instead of breaking compatibility for all NFS layers by
> moving all sysctl under /proc/sys/net/ directory.
>
> Do you feel that it was a bad decision?
I think it was a misinformed decision.
I fully support not breaking userspace by moving where the sysctls files
are. If something sounds like I am suggesting moving sysctl files there
is a miscommunication somewhere.
The concept of a sysctl root as I had envisioned it and essentially as it
is implemented was a per namespace sysctl tree. Those sysctl trees are
then unioned together when presented to user space. There should only
be one root per namespace.
In practice what this means is that register_net_sysctl_table should
work for any sysctl file anywhere under /proc/sys. I think
register_net_sysctl_table is the right solution for your problem. The
only possible caveat I can think of is you might hit Al's performance
optimizations and need to create a common empty directory first with
register_sysctl_paths.
....
That said since I am in the process of rewriting things some of this
may change a little bit, but hopefully not in ways that immediately
effect the users of register_sysctl_table.
Don't use register_net_sysctl_ro_table. I think what the implementors
actually wanted was register_net_sysctl_table(&init_net, ...) and didn't
know it.
Don't put subdirectories in your sysctl tables. Use a ctl_path to
specify the entire directory where the files should show up. Generally
the code is easier to read in that form, and the code is simpler to deal
with if we don't have to worry about directories.
Don't play with the sysctl roots. It is my intention to completely kill
them off and replace them by moving the per net sysctl tree under
/proc/<pid>/sys/. Leaving behind symlinks in /proc/sys/net and I guess
ultimately in /proc/sys/sunrpc/ and /proc/sys/fs/nfs... Which actually
seems to better describe your mental model.
Thank you for mentioning /proc/sys/fs/nfs. That is a case I hadn't
thought about. In thinking about it I see some deficiencies in my
rewrite that I need to correct before I push that code.
Eric
^ permalink raw reply
* [PATCH net-next] r8169: Support for byte queue limits
From: igorm @ 2011-12-19 10:09 UTC (permalink / raw)
To: netdev; +Cc: davem, nic_swsd, romieu, therbert, eric.dumazet, Igor Maravic
From: Igor Maravic <igorm@etf.rs>
Changes to r8169 to use byte queue limits.
Signed-off-by: Igor Maravic <igorm@etf.rs>
---
drivers/net/ethernet/realtek/r8169.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 36b2a4b..1a6a12a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5326,6 +5326,7 @@ static void rtl8169_tx_clear(struct rtl8169_private *tp)
{
rtl8169_tx_clear_range(tp, tp->dirty_tx, NUM_TX_DESC);
tp->cur_tx = tp->dirty_tx = 0;
+ netdev_reset_queue(tp->dev);
}
static void rtl8169_schedule_work(struct net_device *dev, work_func_t task)
@@ -5546,6 +5547,8 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
tp->cur_tx += frags + 1;
+ netdev_sent_queue(dev, skb->len);
+
wmb();
RTL_W8(TxPoll, NPQ);
@@ -5624,6 +5627,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
void __iomem *ioaddr)
{
unsigned int dirty_tx, tx_left;
+ unsigned int bytes_compl = 0;
+ int tx_compl = 0;
dirty_tx = tp->dirty_tx;
smp_rmb();
@@ -5642,14 +5647,18 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb,
tp->TxDescArray + entry);
if (status & LastFrag) {
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += tx_skb->skb->len;
+ tx_compl++;
+ bytes_compl += tx_skb->skb->len;
dev_kfree_skb(tx_skb->skb);
tx_skb->skb = NULL;
}
dirty_tx++;
tx_left--;
}
+ dev->stats.tx_packets += tx_compl;
+ dev->stats.tx_bytes += bytes_compl;
+
+ netdev_completed_queue(dev, tx_compl, bytes_compl);
if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Igor Maravić @ 2011-12-19 9:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, nic_swsd, romieu, therbert
In-Reply-To: <1324287964.3323.107.camel@edumazet-laptop>
>
> What are the changes in this version, versus prior submissions ?
>
You didn't answer to my comments, so I thought that my version was OK.
I'l change this in a sec.
^ 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