* Re: [PATCH net-next v5 0/4] netns: allow to identify peer netns
From: David Miller @ 2015-01-19 19:16 UTC (permalink / raw)
To: nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
luto-kltTT9wpgjJwATOyAt5JVQ, cwang-xCSkyg8dI+0RB7SZvlqPiA
In-Reply-To: <1421331078-21622-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
From: Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Date: Thu, 15 Jan 2015 15:11:14 +0100
> The goal of this serie is to be able to multicast netlink messages with an
> attribute that identify a peer netns.
> This is needed by the userland to interpret some information contained in
> netlink messages (like IFLA_LINK value, but also some other attributes in case
> of x-netns netdevice (see also
> http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
> http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).
>
> Ids of peer netns can be set by userland via a new rtnl cmd RTM_NEWNSID. When
> the kernel needs an id for a peer (for example when advertising a new x-netns
> interface via netlink), if the user didn't allocate an id, one will be
> automatically allocated.
> These ids are stored per netns and are local (ie only valid in the netns where
> they are set). To avoid allocating an int for each peer netns, I use
> idr_for_each() to retrieve the id of a peer netns. Note that it will be possible
> to add a table (struct net -> id) later to optimize this lookup if needed.
>
> Patch 1/4 introduces the rtnetlink API mechanism to set and get these ids.
> Patch 2/4 and 3/4 implements an example of how to use these ids when advertising
> information about a x-netns interface.
> And patch 4/4 shows that the netlink messages can be symetric between a GET and
> a SET.
...
Seires applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Hannes Frederic Sowa @ 2015-01-19 19:11 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: 'David Ahern', netdev
In-Reply-To: <00c901d03402$b5cb6890$216239b0$@codeaurora.org>
On Mo, 2015-01-19 at 09:12 -0700, Harout Hedeshian wrote:
> > I would still prefer that we flush automatically generated addresses and only
> > keep the static and permanent ones.
> >
> > What do you think?
> >
> > Bye,
> > Hannes
>
> If I may offer an opinion, I do feel that there are use cases where flushing the auto-generated addresses in ifdown would not be desirable.
>
> We have one such use case where information regarding the state of the network beyond the interface is managed through sideband signaling. We know that the auto-generated address would still be valid on ifup because the router information is unchanged. In this case, ifup/down is solely being used as a way for user space to enable/disable all traffic on a particular netdevice for temporary periods.
>
> That said, I'm not sure how useful this would be for the average user; I see no harm if it is configurable and the default behavior is unchanged.
Do you think it makes sense to combine the logic with the accept_ra
sysctl?
accept_ra && !flush_addr_on_down -> flush addresses generated by accept_ra logic
!accept_ra && !flush_addr_on_down -> don't flush any addresses
I am not sure about that, feels complicated. Would that suite your usecase?
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Hannes Frederic Sowa @ 2015-01-19 19:07 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <1421456558-27144-1-git-send-email-harouth@codeaurora.org>
On Fr, 2015-01-16 at 18:02 -0700, Harout Hedeshian wrote:
> The kernel forcefully applies MTU values received in router
> advertisements provided the new MTU is less than the current. This
> behavior is undesirable when the user space is managing the MTU. Instead
> a sysctl flag 'accept_ra_mtu' is introduced such that the user space
> can control whether or not RA provided MTU updates should be applied. The
> default behavior is unchanged; user space must explicitly set this flag
> to 0 for RA MTUs to be ignored.
>
> Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
Makes sense!
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Alexander Graf @ 2015-01-19 18:11 UTC (permalink / raw)
To: Ding Tianhong, arnd, robh+dt, davem, grant.likely
Cc: sergei.shtylyov, linux-arm-kernel, eric.dumazet, xuwei5,
zhangfei.gao, netdev, devicetree, linux
In-Reply-To: <1421217254-12008-4-git-send-email-dingtianhong@huawei.com>
On 01/14/15 07:34, Ding Tianhong wrote:
> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
>
> v13: Fix the problem of alignment parameters for function and checkpatch warming.
>
> v12: According Alex's suggestion, modify the changelog and add MODULE_DEVICE_TABLE
> for hip04 ethernet.
>
> v11: Add ethtool support for tx coalecse getting and setting, the xmit_more
> is not supported for this patch, but I think it could work for hip04,
> will support it later after some tests for performance better.
>
> Here are some performance test results by ping and iperf(add tx_coalesce_frames/users),
> it looks that the performance and latency is more better by tx_coalesce_frames/usecs.
>
> - Before:
> $ ping 192.168.1.1 ...
> === 192.168.1.1 ping statistics ===
> 24 packets transmitted, 24 received, 0% packet loss, time 22999ms
> rtt min/avg/max/mdev = 0.180/0.202/0.403/0.043 ms
>
> $ iperf -c 192.168.1.1 ...
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 115 MBytes 945 Mbits/sec
>
> - After:
> $ ping 192.168.1.1 ...
> === 192.168.1.1 ping statistics ===
> 24 packets transmitted, 24 received, 0% packet loss, time 22999ms
> rtt min/avg/max/mdev = 0.178/0.190/0.380/0.041 ms
>
> $ iperf -c 192.168.1.1 ...
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 115 MBytes 965 Mbits/sec
>
> v10: According David Miller and Arnd Bergmann's suggestion, add some modification
> for v9 version
> - drop the workqueue
> - batch cleanup based on tx_coalesce_frames/usecs for better throughput
> - use a reasonable default tx timeout (200us, could be shorted
> based on measurements) with a range timer
> - fix napi poll function return value
> - use a lockless queue for cleanup
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/Makefile | 2 +-
> drivers/net/ethernet/hisilicon/hip04_eth.c | 969 +++++++++++++++++++++++++++++
> 2 files changed, 970 insertions(+), 1 deletion(-)
> create mode 100644 drivers/net/ethernet/hisilicon/hip04_eth.c
>
> diff --git a/drivers/net/ethernet/hisilicon/Makefile b/drivers/net/ethernet/hisilicon/Makefile
> index 40115a7..6c14540 100644
> --- a/drivers/net/ethernet/hisilicon/Makefile
> +++ b/drivers/net/ethernet/hisilicon/Makefile
> @@ -3,4 +3,4 @@
> #
>
> obj-$(CONFIG_HIX5HD2_GMAC) += hix5hd2_gmac.o
> -obj-$(CONFIG_HIP04_ETH) += hip04_mdio.o
> +obj-$(CONFIG_HIP04_ETH) += hip04_mdio.o hip04_eth.o
[...]
> +static irqreturn_t hip04_mac_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *ndev = (struct net_device *)dev_id;
> + struct hip04_priv *priv = netdev_priv(ndev);
> + struct net_device_stats *stats = &ndev->stats;
> + u32 ists = readl_relaxed(priv->base + PPE_INTSTS);
> +
> + if (!ists)
> + return IRQ_NONE;
> +
> + writel_relaxed(DEF_INT_MASK, priv->base + PPE_RINT);
> +
> + if (unlikely(ists & DEF_INT_ERR)) {
> + if (ists & (RCV_NOBUF | RCV_DROP))
> + stats->rx_errors++;
> + stats->rx_dropped++;
> + netdev_err(ndev, "rx drop\n");
After hammering on the box a bit again, I'm in a situation where I get
lots of
[302398.232603] hip04-ether e28b0000.ethernet eth0: rx drop
[302398.377309] hip04-ether e28b0000.ethernet eth0: rx drop
[302398.395198] hip04-ether e28b0000.ethernet eth0: rx drop
[302398.466118] hip04-ether e28b0000.ethernet eth0: rx drop
[302398.659009] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.053389] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.122067] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.268192] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.286081] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.594201] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.683416] hip04-ether e28b0000.ethernet eth0: rx drop
[302399.701307] hip04-ether e28b0000.ethernet eth0: rx drop
and I really am getting a lot of drops - I can't even ping the machine
anymore.
However, as it is there's a good chance the machine is simply
unreachable because it's busy writing to the UART, and even if not all
useful messages indicating anything have scrolled out. I really don't
think you should emit any message over and over again to the user. Once
or twice is enough.
Please make sure to rate limit it.
Alex
^ permalink raw reply
* [PATCH v1 1/4] net: stmmac: dwmac-rk: Don't set the regulator voltage for phy from the driver
From: Romain Perier @ 2015-01-19 18:08 UTC (permalink / raw)
To: peppe.cavallaro
Cc: netdev, linux-kernel, heiko, linux-rockchip, linux-arm-kernel,
devicetree, roger.chen
In-Reply-To: <1421690889-11901-1-git-send-email-romain.perier@gmail.com>
As these settings can be directly expressed from devicetree for both fixed
regulators and pmic-integrated regulators, it is more standard to set them
from dts and let the regulator framework use the right voltage informations
when it is used in the driver.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 35f9b86..06e1637 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -303,7 +303,6 @@ static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
} else {
if (enable) {
if (!regulator_is_enabled(ldo)) {
- regulator_set_voltage(ldo, 3300000, 3300000);
ret = regulator_enable(ldo);
if (ret != 0)
dev_err(dev, "%s: fail to enable %s\n",
--
1.9.1
^ permalink raw reply related
* [PATCH v1 4/4] ARM: dts: Convert gmac to phy-supply in rk3288-evb-rk808.dts
From: Romain Perier @ 2015-01-19 18:08 UTC (permalink / raw)
To: peppe.cavallaro
Cc: netdev, linux-kernel, heiko, linux-rockchip, linux-arm-kernel,
devicetree, roger.chen
In-Reply-To: <1421690889-11901-1-git-send-email-romain.perier@gmail.com>
This replaces the property phy_regulator by the standard devicetree property
phy-supply and references the device_node vcc_phy from it.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/rk3288-evb-rk808.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index 831a7aa..e1d3eeb 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -161,7 +161,7 @@
};
&gmac {
- phy_regulator = "vcc_phy";
+ phy-supply = <&vcc_phy>;
phy-mode = "rgmii";
clock_in_out = "input";
snps,reset-gpio = <&gpio4 7 0>;
--
1.9.1
^ permalink raw reply related
* [PATCH v1 3/4] net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator
From: Romain Perier @ 2015-01-19 18:08 UTC (permalink / raw)
To: peppe.cavallaro
Cc: netdev, linux-kernel, heiko, linux-rockchip, linux-arm-kernel,
devicetree, roger.chen
In-Reply-To: <1421690889-11901-1-git-send-email-romain.perier@gmail.com>
Currently, dwmac-rk uses a custom propety "phy_regulator" to get the name of the
right regulator to use to power on or power off the phy. This commit converts the
driver to use phy-supply devicetree property and the corresponding API, it cleans
the code a bit and make it simpler to maintain.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 61 ++++++++------------------
1 file changed, 19 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 06e1637..8a8091c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -32,7 +32,7 @@
struct rk_priv_data {
struct platform_device *pdev;
int phy_iface;
- char regulator[32];
+ struct regulator *regulator;
bool clk_enabled;
bool clock_input;
@@ -287,46 +287,25 @@ static int gmac_clk_enable(struct rk_priv_data *bsp_priv, bool enable)
static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
{
- struct regulator *ldo;
- char *ldostr = bsp_priv->regulator;
+ struct regulator *ldo = bsp_priv->regulator;
int ret;
struct device *dev = &bsp_priv->pdev->dev;
- if (!ldostr) {
- dev_err(dev, "%s: no ldo found\n", __func__);
+ if (!ldo) {
+ dev_err(dev, "%s: no regulator found\n", __func__);
return -1;
}
- ldo = regulator_get(NULL, ldostr);
- if (!ldo) {
- dev_err(dev, "\n%s get ldo %s failed\n", __func__, ldostr);
+ if (enable) {
+ ret = regulator_enable(ldo);
+ if (ret)
+ dev_err(dev, "%s: fail to enable phy-supply\n",
+ __func__);
} else {
- if (enable) {
- if (!regulator_is_enabled(ldo)) {
- ret = regulator_enable(ldo);
- if (ret != 0)
- dev_err(dev, "%s: fail to enable %s\n",
- __func__, ldostr);
- else
- dev_info(dev, "turn on ldo done.\n");
- } else {
- dev_warn(dev, "%s is enabled before enable",
- ldostr);
- }
- } else {
- if (regulator_is_enabled(ldo)) {
- ret = regulator_disable(ldo);
- if (ret != 0)
- dev_err(dev, "%s: fail to disable %s\n",
- __func__, ldostr);
- else
- dev_info(dev, "turn off ldo done.\n");
- } else {
- dev_warn(dev, "%s is disabled before disable",
- ldostr);
- }
- }
- regulator_put(ldo);
+ ret = regulator_disable(ldo);
+ if (ret)
+ dev_err(dev, "%s: fail to disable phy-supply\n",
+ __func__);
}
return 0;
@@ -346,14 +325,12 @@ static void *rk_gmac_setup(struct platform_device *pdev)
bsp_priv->phy_iface = of_get_phy_mode(dev->of_node);
- ret = of_property_read_string(dev->of_node, "phy_regulator", &strings);
- if (ret) {
- dev_warn(dev, "%s: Can not read property: phy_regulator.\n",
- __func__);
- } else {
- dev_info(dev, "%s: PHY power controlled by regulator(%s).\n",
- __func__, strings);
- strcpy(bsp_priv->regulator, strings);
+ bsp_priv->regulator = devm_regulator_get_optional(dev, "phy");
+ if (IS_ERR(bsp_priv->regulator)) {
+ if (PTR_ERR(bsp_priv->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(dev, "no regulator found\n");
+ bsp_priv->regulator = NULL;
}
ret = of_property_read_string(dev->of_node, "clock_in_out", &strings);
--
1.9.1
^ permalink raw reply related
* [PATCH v1 2/4] ARM: dts: Add regulator voltage settings for vcc_phy in rk3288-evb.dtsi
From: Romain Perier @ 2015-01-19 18:08 UTC (permalink / raw)
To: peppe.cavallaro
Cc: devicetree, heiko, netdev, linux-kernel, linux-rockchip,
roger.chen, linux-arm-kernel
In-Reply-To: <1421690889-11901-1-git-send-email-romain.perier@gmail.com>
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi
index 489643c..1c08eb0 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -98,6 +98,8 @@
pinctrl-names = "default";
pinctrl-0 = <ð_phy_pwr>;
regulator-name = "vcc_phy";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-boot-on;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v1 0/4] net: stmmac: dwmac-rk: Fix phy regulator issues
From: Romain Perier @ 2015-01-19 18:08 UTC (permalink / raw)
To: peppe.cavallaro-qxv4g6HH51o
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, heiko-4mtYJXux2i+zQB+pC5nmwQ,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
roger.chen-TNX95d0MmH7DzftRWevZcw
This series fixes few issues in dwmac-rk:
1. Voltage settings was hardcoded into the driver for the phy regulator.
The driver now uses the default voltage settings found in the devicetree, which are
applied throught the regulator framework.
2. The regulator name used to power on or power off the phy was put in the devicetree
variable "phy_regulator", which is not standard and added a lot of code for nothing.
The driver now uses the devicetree property "phy-supply" and the corresponding functions
to manipulate this regulator.
The corresponding devicetree files are also updated. As, dwmac-rk was recently
pushed in the development tree, I don't care about devicetree backward compatibility
issues.
Romain Perier (4):
net: stmmac: dwmac-rk: Don't set the regulator voltage for phy from
the driver
ARM: dts: Add regulator voltage settings for vcc_phy in
rk3288-evb.dtsi
net: stmmac: dwmac-rk: Use standard devicetree property for phy
regulator
ARM: dts: Convert gmac to phy-supply in rk3288-evb-rk808.dts
arch/arm/boot/dts/rk3288-evb-rk808.dts | 2 +-
arch/arm/boot/dts/rk3288-evb.dtsi | 2 +
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 62 ++++++++------------------
3 files changed, 22 insertions(+), 44 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* pull-request: mac80211-next 2015-01-19
From: Johannes Berg @ 2015-01-19 18:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi,
Please excuse the quick succession of pull requests - two issues were
found in the code from the previous one that we'd like to fix quickly,
along with less than a handful of other changes described below.
Thanks,
johannes
The following changes since commit baf1b99ba169bdd3324ac9d99bc2a00c25534429:
cfg80211: docs: remove station_info_flags (2015-01-14 13:57:36 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2015-01-19
for you to fetch changes up to c1e140bf79d817d4a7aa9932eb98b0359c87af33:
mac80211: delete the assoc/auth timer upon suspend (2015-01-19 18:59:20 +0100)
----------------------------------------------------------------
Some further updates for net-next:
* fix network-manager which was broken by the previous changes
* fix delete-station events, which were broken by me making the
genlmsg_end() mistake
* fix a timer left running during suspend in some race conditions
that would cause an annoying (but harmless) warning
* (less important, but in the tree already) remove 80+80 MHz rate
reporting since the spec doesn't distinguish it from 160 MHz;
as the bitrate they're both 160 MHz bandwidth
----------------------------------------------------------------
Emmanuel Grumbach (1):
mac80211: delete the assoc/auth timer upon suspend
Johannes Berg (6):
mac80211: remove 80+80 MHz rate reporting
cfg80211: remove 80+80 MHz rate reporting
cfg80211: change bandwidth reporting to explicit field
mac80211: remove doubled semicolon
cfg80211: fix checking nl80211_send_station() return value
Revert "wireless: Support of IFLA_INFO_KIND rtnl attribute"
drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +-
drivers/net/wireless/mwifiex/cfg80211.c | 11 ++++----
include/net/cfg80211.h | 35 ++++++++++++++++-------
include/net/mac80211.h | 6 ++--
include/uapi/linux/nl80211.h | 11 +++++++-
net/mac80211/cfg.c | 33 +++++++++++++---------
net/mac80211/mlme.c | 12 ++++++++
net/mac80211/rx.c | 5 ----
net/mac80211/status.c | 2 +-
net/mac80211/util.c | 27 +++++++++++-------
net/wireless/core.c | 6 ----
net/wireless/nl80211.c | 45 +++++++++++++++++++-----------
net/wireless/util.c | 25 +++++++++++++----
13 files changed, 143 insertions(+), 78 deletions(-)
^ permalink raw reply
* [patch-net-next v3] net: ethernet: ti: cpsw: fix buld break when NET_POLL_CONTROLLER
From: Felipe Balbi @ 2015-01-19 17:52 UTC (permalink / raw)
To: davem
Cc: Tony Lindgren, Linux OMAP Mailing List, mugunthanvnm, netdev,
Felipe Balbi
Commit c03abd84634d (net: ethernet: cpsw: don't requests IRQs we don't
use) left one build breakage when NET_POLL_CONTROLLER is enabled.
Fix this build break by referring to the correct irqs_table array.
Fixes: c03abd84634d (net: ethernet: cpsw: don't requests IRQs we don't use)
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index ba09ff3c1695..a0e9a2b384f8 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1625,8 +1625,8 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
cpsw_intr_disable(priv);
cpdma_ctlr_int_ctrl(priv->dma, false);
- cpsw_rx_interrupt(priv->irq[0], priv);
- cpsw_tx_interrupt(priv->irq[1], priv);
+ cpsw_rx_interrupt(priv->irqs_table[0], priv);
+ cpsw_tx_interrupt(priv->irqs_table[1], priv);
cpdma_ctlr_int_ctrl(priv->dma, true);
cpsw_intr_enable(priv);
}
--
2.2.0
^ permalink raw reply related
* Re: [Xen-devel] [RFC PATCHv1 net-next] xen-netback: always fully coalesce guest Rx packets
From: David Vrabel @ 2015-01-19 17:36 UTC (permalink / raw)
To: Wei Liu, David Vrabel; +Cc: netdev, Ian Campbell, xen-devel, Jonathan Davies
In-Reply-To: <20150113143033.GN4226@zion.uk.xensource.com>
On 13/01/15 14:30, Wei Liu wrote:
> On Tue, Jan 13, 2015 at 02:05:17PM +0000, David Vrabel wrote:
>> Always fully coalesce guest Rx packets into the minimum number of ring
>> slots. Reducing the number of slots per packet has significant
>> performance benefits (e.g., 7.2 Gbit/s to 11 Gbit/s in an off-host
>> receive test).
>>
>
> Good number.
>
>> However, this does increase the number of grant ops per packet which
>> decreases performance with some workloads (intrahost VM to VM)
>
> Do you have figures before and after this change?
Some better (more rigorous) results done by Jonathan Davies shows no
regressions with full coalescing even without the grant copy
optimization, and a big improvement to single stream receive.
baseline Full coalesce
Interhost aggregate 24 Gb/s 24 Gb/s
Interhost VM receive 7.2 Gb/s 11 Gb/s
Intrahost single stream 14 Gb/s 14 Gb/s
Intrahost aggregate 34 Gb/s 34 Gb/s
We do not measure the performance of dom0 to guest traffic but my ad-hoc
measurements suggest this may be 5-10% slower. I don't think this is a
very important use case though.
So...
>> /unless/ grant copy has been optimized for adjacent ops with the same
>> source or destination (see "grant-table: defer releasing pages
>> acquired in a grant copy"[1]).
>>
>> Do we need to retain the existing path and make the always coalesce
>> path conditional on a suitable version of Xen?
...I think the answer to this is no.
>> ---
>> drivers/net/xen-netback/common.h | 1 -
>> drivers/net/xen-netback/netback.c | 106 ++-----------------------------------
>> 2 files changed, 3 insertions(+), 104 deletions(-)
>
> Love the diffstat!
Yes, it's always nice when you delete code and it goes faster... :)
David
^ permalink raw reply
* Re: [patch-net-next v3 2/2] net: ethernet: cpsw: don't requests IRQs we don't use
From: David Miller @ 2015-01-19 17:38 UTC (permalink / raw)
To: balbi; +Cc: tony, linux-omap, mugunthanvnm, netdev
In-Reply-To: <20150119144017.GB20386@saruman>
From: Felipe Balbi <balbi@ti.com>
Date: Mon, 19 Jan 2015 08:40:17 -0600
> On Sun, Jan 18, 2015 at 01:07:50AM -0500, David Miller wrote:
>> From: Felipe Balbi <balbi@ti.com>
>> Date: Fri, 16 Jan 2015 10:11:12 -0600
>>
>> > CPSW never uses RX_THRESHOLD or MISC interrupts. In
>> > fact, they are always kept masked in their appropriate
>> > IRQ Enable register.
>> >
>> > Instead of allocating an IRQ that never fires, it's best
>> > to remove that code altogether and let future patches
>> > implement it if anybody needs those.
>> >
>> > Signed-off-by: Felipe Balbi <balbi@ti.com>
>>
>> Applied.
>
> looks like randconfig caught a build break. Do you want an incremental
> patch or this patch again with the fix in it ?
Always incremental patches.
^ permalink raw reply
* Re: [PATCH net 2/2] sh_eth: Fix ethtool operation crash when net device is down
From: Florian Fainelli @ 2015-01-19 17:28 UTC (permalink / raw)
To: Ben Hutchings
Cc: David S. Miller, netdev, linux-kernel, Nobuhiro Iwamatsu,
Mitsuhiro Kimura, Hisashi Nakamura, Yoshihiro Kaneko
In-Reply-To: <1421664085.1222.200.camel@xylophone.i.decadent.org.uk>
On 19/01/15 02:41, Ben Hutchings wrote:
> On Fri, 2015-01-16 at 10:45 -0800, Florian Fainelli wrote:
>> 2015-01-16 9:51 GMT-08:00 Ben Hutchings <ben.hutchings@codethink.co.uk>:
> [...]
>>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>>> @@ -1827,6 +1827,9 @@ static int sh_eth_get_settings(struct net_device *ndev,
>>> unsigned long flags;
>>> int ret;
>>>
>>> + if (!mdp->phydev)
>>> + return -ENODEV;
>>
>> Since the PHY is disconnected, would not checking for netif_running()
>> make sense here, unless there is a good reason to still allow
>> phy_ethtool_gset() to be called?
> [...]
>
> I think those two conditions will be equivalent, won't they?
They are indeed.
> Writing the condition like this will also work if the driver later supports
> PHY-less configurations.
You could also represent a PHY-less configuration by using the emulated
fixed-PHY, such that the driver is effectively "driving" a PHY device,
even though this is not a real one, up to you.
--
Florian
^ permalink raw reply
* [discuss] [cdc_ncm] Refactoring cdc_ncm
From: Enrico Mioso @ 2015-01-19 16:51 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <8761dqjuuh.fsf@nemi.mork.no>
Hi guys.
I am noticing that in kernel 3.19rc4, the driver from huawei,
hw_cdc_driver
is not able to perform the call to
netif_msg_ifup anymore (receives error -13).
This to say that it would be very important to continue the work on refactoring
cdc_ncm.c driver to let it work with newer huawei devices such as the E3372
even at full rates.
I received some acks regarding the patches I sent last time - and I am grateful
to you all maintainers / reviewers. I have actually not received acks for all
the patches so I preferred waiting and not continously re-sending again.
This also happened due to me getting very busy lately with studying.
So the situation is getting complicated.
I sent this mail to everyone just to keep you up-to-date. Don't worry.
Any help from any developer interested would be very apreciated.
I would need some mentoring or help in general with coding.
Thank you all very much.
Sincerely.
Enrico
^ permalink raw reply
* Re: Re: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Thomas Jarosch @ 2015-01-19 16:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: 'Linux Netdev List', Eric Dumazet, Jeff Kirsher,
e1000-devel
In-Reply-To: <1421335532.11734.73.camel@edumazet-glaptop2.roam.corp.google.com>
On Thursday, 15. January 2015 07:25:32 Eric Dumazet wrote:
> On Thu, 2015-01-15 at 15:58 +0100, Thomas Jarosch wrote:
> > A colleague mentioned to me he saw the "Hardware Unit Hang" message
> > every
> > few days even running on kernel 3.4 (without your patch). Basically I'm
> > testing now if that's still the case with 3.19-rc4+ or not.
> >
> > I'm all for fixing the root cause. I'm just interested if the e1000e
> > hang can even be triggered when using a max frag page size of 4096.
> > So far it transferred 751.6 GiB without a hiccup.
>
> You told it was forwarding setup.
>
> 1) What is the NIC receiving traffic.
> 2) What happens if you disable GRO on it ?
one more interesting thing happened: On one production machine,
again an Intel DH61CR board, the issue was triggered even with TSO disabled.
My colleague tried to disable GRO + GSO on the e1000e adapter, too,
though not on the other interfaces.
It's strange the issue appears with TSO disabled,
that worked for three other production level machines.
We've emergency-installed the "4096" max frag page size workaround
for now as fifty people were a bit unhappy without network access... :D
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH 1/6] selftests: Introduce minimal shared logic for running tests
From: Shuah Khan @ 2015-01-19 16:39 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel, mmarek, gregkh, akpm, rostedt, mingo, davem,
keescook, tranmanphong, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i, linux-kbuild,
linux-api, netdev
In-Reply-To: <1421627742.3787.6.camel@ellerman.id.au>
On 01/18/2015 05:35 PM, Michael Ellerman wrote:
> On Fri, 2015-01-16 at 10:53 -0700, Shuah Khan wrote:
>> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
>>> This adds a Make include file which most selftests can then include to
>>> get the run_tests logic.
>>>
>>> On its own this has the advantage of some reduction in repetition, and
>>> also means the pass/fail message is defined in fewer places.
>>>
>>> However the key advantage is it will allow us to implement install very
>>> simply in a subsequent patch.
>>>
>>> The default implementation just executes each program in $(TEST_PROGS).
>>>
>>> We use a variable to hold the default implementation of $(RUN_TESTS)
>>> because that gives us a clean way to override it if necessary, ie. using
>>> override. The mount, memory-hotplug and mqueue tests use that to provide
>>> a different implementation.
>>>
>>> Tests are not run via /bin/bash, so if they are scripts they must be
>>> executable, we add u+x to several.
>>>
>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>
>> I like the shared logic approach in general provided it leaves the
>> flexibility to not use the shared logic if a test have the need to
>> do so.
>
> Yes of course it does, it's entirely optional to include lib.mk.
>
>> This series requires some patch planning. shared logic patch
>> followed by individual test patches as opposed a single patch.
>
> It could be a single patch too, but there's no reason to do it that way. The
> series works fine as I sent it.
>
>> I would like to see the shared logic work done on top of my patch v4
>> series.
>
> That's a waste of time. This series replaces your v4. Doing this "on top" of
> your v4 would just mean reverting your v4 series and then applying this.
>
No necessarily if the work is done as evolutionary step. In any case,
I want the first step install target support going into the upcoming
release and then make improvements to it. Please send separate patch
for the shared logic and individual test patches that use the shared
logic if you would like to make the improvements.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 2/6] selftests: Add install target
From: Shuah Khan @ 2015-01-19 16:35 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mmarek-AlSwsSmVLrQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, keescook-F7+t8E8rja9g9hUCZPvPmw,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, cov-sgV2jX0FEOL9JmXXK+q4OQ,
dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w, hughd-hpIqsD4AKlfQT0dZR+AlfA,
bobby.prani-Re5JQEeQqe8AvxtiuMwx3w,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, tim.bird-/MT0OVThwyLZJqsBc5GL+g,
josh-iaAMLnmF4UmaiuxdJuQwMA, koct9i-Re5JQEeQqe8AvxtiuMwx3w,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1421627752.3787.8.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
On 01/18/2015 05:35 PM, Michael Ellerman wrote:
> On Fri, 2015-01-16 at 10:46 -0700, Shuah Khan wrote:
>> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
>>> This adds make install support to selftests. The basic usage is:
>>>
>>> $ cd tools/testing/selftests
>>> $ make install
>>>
>>> That installs into tools/testing/selftests/install, which can then be
>>> copied where ever necessary.
>>>
>>> The install destination is also configurable using eg:
>>>
>>> $ INSTALL_PATH=/mnt/selftests make install
>>
>> Please see my response to [PATCH 4/6] kbuild: add a new
>> kselftest_install make target to install selftests
>>
>> These are addressed by the current approach to use existing
>> INSTALL_MOD_PATH.
>
> No that's a separate issue.
>
> This patch adds install support for tools/testing/selftests, *completely
> separate* from the kbuild infrastructure.
>
What's the use-case for this feature? I don't see why we need multiple
ways to do the install?
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 4/6] kbuild: add a new kselftest_install make target to install selftests
From: Shuah Khan @ 2015-01-19 16:34 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel, mmarek, gregkh, akpm, rostedt, mingo, davem,
keescook, tranmanphong, cov, dh.herrmann, hughd, bobby.prani,
serge.hallyn, ebiederm, tim.bird, josh, koct9i, linux-kbuild,
linux-api, netdev
In-Reply-To: <1421627747.3787.7.camel@ellerman.id.au>
On 01/18/2015 05:35 PM, Michael Ellerman wrote:
> On Fri, 2015-01-16 at 09:34 -0700, Shuah Khan wrote:
>> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
>>> Add a new make target to install kernel selftests. This new target will
>>> build and install selftests.
>>>
>>> The default is just $(objtree)/selftests. This is preferable to
>>> something based on $(INSTALL_MOD_PATH) (which defaults to /), as it
>>> allows a normal user to install the tests. This is similar to the
>>> default behaviour of make headers_install.
>>
>> A normal user can install tests at any location they choose by
>> overriding the default path. For example:
>>
>> INSTALL_MOD_PATH=/tmp make kselftest_install
>>
>> will install under tmp.
>
> Why default to a directory that most users can't write to? That's not helpful.
>
> Users who are root can override the path, for example:
>
> INSTALL_MOD_PATH=/ make kselftest_install
>
>> The approach I used also ties test installs to kernel release.
>> This addresses an important use-case for kernel developers
>> that want to compare results from release to release.
>
> Sure, I'm happy to add the kernel release, so the default would be
> $(objtree)/selftests/$(kernel-release)/.
>
>> The use-case for any user to be able to install tests at
>> any location is addressed by the above example.
>
> The default should work for most users most of the time, / does not achieve
> that.
>
>> I would like these two above use-cases continued to be supported,
>> especially the one that tries the test installs to kernel release.
>
> That's fine, I'm happy to update this to use kernel release. But defaulting to
> / doesn't make sense.
>
I want to keep the kselftest installs to default to the location
other kernel installs such as firmware and modules default to.
This keep the use-case the same as other kernel installs. As user
can override the location, I don't any problems with this.
For most kernel developers, INSTALL_MOD_PATH is the familiar place
to cleanup kernels and I don't see any reason to change that.
You are welcome to send patches to simply the install process for
the individual tests for the next release. I want individual patches
for each test and a separate patch for the shared logic patch.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* RE: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: Harout Hedeshian @ 2015-01-19 16:12 UTC (permalink / raw)
To: 'Hannes Frederic Sowa', 'David Ahern'; +Cc: netdev
In-Reply-To: <1421679769.32277.15.camel@redhat.com>
> I would still prefer that we flush automatically generated addresses and only
> keep the static and permanent ones.
>
> What do you think?
>
> Bye,
> Hannes
If I may offer an opinion, I do feel that there are use cases where flushing the auto-generated addresses in ifdown would not be desirable.
We have one such use case where information regarding the state of the network beyond the interface is managed through sideband signaling. We know that the auto-generated address would still be valid on ifup because the router information is unchanged. In this case, ifup/down is solely being used as a way for user space to enable/disable all traffic on a particular netdevice for temporary periods.
That said, I'm not sure how useful this would be for the average user; I see no harm if it is configurable and the default behavior is unchanged.
Thanks,
Harout
^ permalink raw reply
* Re: [net-next PATCH v2 01/12] net: flow_table: create interface for hw match/action tables
From: John Fastabend @ 2015-01-19 16:11 UTC (permalink / raw)
To: Simon Horman; +Cc: tgraf, sfeldma, netdev, gerlitz.or, jhs, andy, davem
In-Reply-To: <20150119050937.GD5612@vergenet.net>
On 01/18/2015 09:09 PM, Simon Horman wrote:
> [snip]
>
>> --- /dev/null
>> +++ b/net/core/flow_table.c
>> @@ -0,0 +1,942 @@
>> +/*
>> + * include/uapi/linux/if_flow.h - Flow table interface for Switch devices
>
> Hi John,
>
> its seems that the path in the above comment should be
> net/core/flow_table.c.
>
> [snip]
>
Thanks Simon, I've merged all three comments.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] tipc: ratelimit network event traces
From: Jon Maloy @ 2015-01-19 16:07 UTC (permalink / raw)
To: Erik Hugne, Richard Alpe, ying.xue@windriver.com,
netdev@vger.kernel.org
Cc: tipc-discussion@lists.sourceforge.net
In-Reply-To: <1421658164-26185-1-git-send-email-erik.hugne@ericsson.com>
> -----Original Message-----
> From: Erik Hugne
> Sent: January-19-15 4:03 AM
> To: Richard Alpe; ying.xue@windriver.com; Jon Maloy;
> netdev@vger.kernel.org
> Cc: tipc-discussion@lists.sourceforge.net; Erik Hugne
> Subject: [PATCH net-next] tipc: ratelimit network event traces
>
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> If a large number of namespaces is spawned on a node and TIPC is enabled in
> each of these, the excessive printk tracing of network events will cause the
> system to grind down to a near halt.
The patch is ok, but I don't quite understand how this can happen. Are you connecting
dozens of nodes in dozens of namespaces? How many "Established link'' printouts
are there? Even if there are hundreds of them in a burst, I don't quite understand how
this can kill the whole system. Just curious.
///jon
> We fix this by adding ratelimiting to the info/warning logs regarding link state
> and node availability.
>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Reviewed-by: Ying Xue <ying.xue@windriver.com>
> ---
> net/tipc/link.c | 21 +++++++++++---------- net/tipc/node.c | 24
> +++++++++++++-----------
> 2 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/net/tipc/link.c b/net/tipc/link.c index 193bc15..bedb590 100644
> --- a/net/tipc/link.c
> +++ b/net/tipc/link.c
> @@ -538,8 +538,8 @@ static void link_state_event(struct tipc_link *l_ptr,
> unsigned int event)
> link_set_timer(l_ptr, cont_intv / 4);
> break;
> case RESET_MSG:
> - pr_info("%s<%s>, requested by peer\n",
> link_rst_msg,
> - l_ptr->name);
> + pr_info_ratelimited("%s<%s>, requested by peer\n",
> + link_rst_msg, l_ptr->name);
> tipc_link_reset(l_ptr);
> l_ptr->state = RESET_RESET;
> l_ptr->fsm_msg_cnt = 0;
> @@ -549,7 +549,8 @@ static void link_state_event(struct tipc_link *l_ptr,
> unsigned int event)
> link_set_timer(l_ptr, cont_intv);
> break;
> default:
> - pr_err("%s%u in WW state\n", link_unk_evt, event);
> + pr_err_ratelimited("%s%u in WW state\n",
> link_unk_evt,
> + event);
> }
> break;
> case WORKING_UNKNOWN:
> @@ -561,8 +562,8 @@ static void link_state_event(struct tipc_link *l_ptr,
> unsigned int event)
> link_set_timer(l_ptr, cont_intv);
> break;
> case RESET_MSG:
> - pr_info("%s<%s>, requested by peer while
> probing\n",
> - link_rst_msg, l_ptr->name);
> + pr_info_ratelimited("%s<%s>, requested by peer
> while probing\n",
> + link_rst_msg, l_ptr->name);
> tipc_link_reset(l_ptr);
> l_ptr->state = RESET_RESET;
> l_ptr->fsm_msg_cnt = 0;
> @@ -588,8 +589,8 @@ static void link_state_event(struct tipc_link *l_ptr,
> unsigned int event)
> l_ptr->fsm_msg_cnt++;
> link_set_timer(l_ptr, cont_intv / 4);
> } else { /* Link has failed */
> - pr_warn("%s<%s>, peer not responding\n",
> - link_rst_msg, l_ptr->name);
> + pr_warn_ratelimited("%s<%s>, peer not
> responding\n",
> + link_rst_msg, l_ptr-
> >name);
> tipc_link_reset(l_ptr);
> l_ptr->state = RESET_UNKNOWN;
> l_ptr->fsm_msg_cnt = 0;
> @@ -1568,9 +1569,9 @@ static void tipc_link_proto_rcv(struct net *net,
> struct tipc_link *l_ptr,
>
> if (msg_linkprio(msg) &&
> (msg_linkprio(msg) != l_ptr->priority)) {
> - pr_warn("%s<%s>, priority change %u->%u\n",
> - link_rst_msg, l_ptr->name, l_ptr->priority,
> - msg_linkprio(msg));
> + pr_warn_ratelimited("%s<%s>, priority change %u-
> >%u\n",
> + link_rst_msg, l_ptr->name,
> + l_ptr->priority, msg_linkprio(msg));
> l_ptr->priority = msg_linkprio(msg);
> tipc_link_reset(l_ptr); /* Enforce change to take
> effect */
> break;
> diff --git a/net/tipc/node.c b/net/tipc/node.c index b1eb092..01a03a7 100644
> --- a/net/tipc/node.c
> +++ b/net/tipc/node.c
> @@ -230,8 +230,8 @@ void tipc_node_link_up(struct tipc_node *n_ptr,
> struct tipc_link *l_ptr)
> n_ptr->action_flags |= TIPC_NOTIFY_LINK_UP;
> n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
>
> - pr_info("Established link <%s> on network plane %c\n",
> - l_ptr->name, l_ptr->net_plane);
> + pr_info_ratelimited("Established link <%s> on network plane %c\n",
> + l_ptr->name, l_ptr->net_plane);
>
> if (!active[0]) {
> active[0] = active[1] = l_ptr;
> @@ -239,7 +239,8 @@ void tipc_node_link_up(struct tipc_node *n_ptr,
> struct tipc_link *l_ptr)
> goto exit;
> }
> if (l_ptr->priority < active[0]->priority) {
> - pr_info("New link <%s> becomes standby\n", l_ptr->name);
> + pr_info_ratelimited("New link <%s> becomes standby\n",
> + l_ptr->name);
> goto exit;
> }
> tipc_link_dup_queue_xmit(active[0], l_ptr); @@ -247,9 +248,10 @@
> void tipc_node_link_up(struct tipc_node *n_ptr, struct tipc_link *l_ptr)
> active[0] = l_ptr;
> goto exit;
> }
> - pr_info("Old link <%s> becomes standby\n", active[0]->name);
> + pr_info_ratelimited("Old link <%s> becomes standby\n",
> +active[0]->name);
> if (active[1] != active[0])
> - pr_info("Old link <%s> becomes standby\n", active[1]-
> >name);
> + pr_info_ratelimited("Old link <%s> becomes standby\n",
> + active[1]->name);
> active[0] = active[1] = l_ptr;
> exit:
> /* Leave room for changeover header when returning 'mtu' to users:
> */ @@ -297,12 +299,12 @@ void tipc_node_link_down(struct tipc_node
> *n_ptr, struct tipc_link *l_ptr)
> n_ptr->link_id = l_ptr->peer_bearer_id << 16 | l_ptr->bearer_id;
>
> if (!tipc_link_is_active(l_ptr)) {
> - pr_info("Lost standby link <%s> on network plane %c\n",
> - l_ptr->name, l_ptr->net_plane);
> + pr_info_ratelimited("Lost standby link <%s> on network
> plane %c\n",
> + l_ptr->name, l_ptr->net_plane);
> return;
> }
> - pr_info("Lost link <%s> on network plane %c\n",
> - l_ptr->name, l_ptr->net_plane);
> + pr_info_ratelimited("Lost link <%s> on network plane %c\n",
> + l_ptr->name, l_ptr->net_plane);
>
> active = &n_ptr->active_links[0];
> if (active[0] == l_ptr)
> @@ -380,8 +382,8 @@ static void node_lost_contact(struct tipc_node
> *n_ptr)
> char addr_string[16];
> u32 i;
>
> - pr_info("Lost contact with %s\n",
> - tipc_addr_string_fill(addr_string, n_ptr->addr));
> + pr_info_ratelimited("Lost contact with %s\n",
> + tipc_addr_string_fill(addr_string, n_ptr->addr));
>
> /* Flush broadcast link info associated with lost node */
> if (n_ptr->bclink.recv_permitted) {
> --
> 2.1.3
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
^ permalink raw reply
* [patch iproute2 repost 1/2] tc: push bpf common code into separate file
From: Jiri Pirko @ 2015-01-19 15:56 UTC (permalink / raw)
To: netdev; +Cc: jhs, stephen
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
tc/Makefile | 2 +-
tc/f_bpf.c | 136 +++++--------------------------------------------------
tc/tc_bpf.c | 146 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
tc/tc_bpf.h | 28 ++++++++++++
4 files changed, 186 insertions(+), 126 deletions(-)
create mode 100644 tc/tc_bpf.c
create mode 100644 tc/tc_bpf.h
diff --git a/tc/Makefile b/tc/Makefile
index 9412094..15f68ce 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -1,5 +1,5 @@
TCOBJ= tc.o tc_qdisc.o tc_class.o tc_filter.o tc_util.o \
- tc_monitor.o m_police.o m_estimator.o m_action.o \
+ tc_monitor.o tc_bpf.o m_police.o m_estimator.o m_action.o \
m_ematch.o emp_ematch.yacc.o emp_ematch.lex.o
include ../Config
diff --git a/tc/f_bpf.c b/tc/f_bpf.c
index 48635a7..e2af94e 100644
--- a/tc/f_bpf.c
+++ b/tc/f_bpf.c
@@ -26,6 +26,7 @@
#include "utils.h"
#include "tc_util.h"
+#include "tc_bpf.h"
static void explain(void)
{
@@ -44,130 +45,6 @@ static void explain(void)
fprintf(stderr, "NOTE: CLASSID is parsed as hexadecimal input.\n");
}
-static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
- char **bpf_string, bool *need_release,
- const char separator)
-{
- char sp;
-
- if (from_file) {
- size_t tmp_len, op_len = sizeof("65535 255 255 4294967295,");
- char *tmp_string;
- FILE *fp;
-
- tmp_len = sizeof("4096,") + BPF_MAXINSNS * op_len;
- tmp_string = malloc(tmp_len);
- if (tmp_string == NULL)
- return -ENOMEM;
-
- memset(tmp_string, 0, tmp_len);
-
- fp = fopen(arg, "r");
- if (fp == NULL) {
- perror("Cannot fopen");
- free(tmp_string);
- return -ENOENT;
- }
-
- if (!fgets(tmp_string, tmp_len, fp)) {
- free(tmp_string);
- fclose(fp);
- return -EIO;
- }
-
- fclose(fp);
-
- *need_release = true;
- *bpf_string = tmp_string;
- } else {
- *need_release = false;
- *bpf_string = arg;
- }
-
- if (sscanf(*bpf_string, "%hu%c", bpf_len, &sp) != 2 ||
- sp != separator) {
- if (*need_release)
- free(*bpf_string);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int bpf_parse_ops(int argc, char **argv, struct nlmsghdr *n,
- bool from_file)
-{
- char *bpf_string, *token, separator = ',';
- struct sock_filter bpf_ops[BPF_MAXINSNS];
- int ret = 0, i = 0;
- bool need_release;
- __u16 bpf_len = 0;
-
- if (argc < 1)
- return -EINVAL;
- if (bpf_parse_string(argv[0], from_file, &bpf_len, &bpf_string,
- &need_release, separator))
- return -EINVAL;
- if (bpf_len == 0 || bpf_len > BPF_MAXINSNS) {
- ret = -EINVAL;
- goto out;
- }
-
- token = bpf_string;
- while ((token = strchr(token, separator)) && (++token)[0]) {
- if (i >= bpf_len) {
- fprintf(stderr, "Real program length exceeds encoded "
- "length parameter!\n");
- ret = -EINVAL;
- goto out;
- }
-
- if (sscanf(token, "%hu %hhu %hhu %u,",
- &bpf_ops[i].code, &bpf_ops[i].jt,
- &bpf_ops[i].jf, &bpf_ops[i].k) != 4) {
- fprintf(stderr, "Error at instruction %d!\n", i);
- ret = -EINVAL;
- goto out;
- }
-
- i++;
- }
-
- if (i != bpf_len) {
- fprintf(stderr, "Parsed program length is less than encoded"
- "length parameter!\n");
- ret = -EINVAL;
- goto out;
- }
-
- addattr_l(n, MAX_MSG, TCA_BPF_OPS_LEN, &bpf_len, sizeof(bpf_len));
- addattr_l(n, MAX_MSG, TCA_BPF_OPS, &bpf_ops,
- bpf_len * sizeof(struct sock_filter));
-out:
- if (need_release)
- free(bpf_string);
-
- return ret;
-}
-
-static void bpf_print_ops(FILE *f, struct rtattr *bpf_ops, __u16 len)
-{
- struct sock_filter *ops = (struct sock_filter *) RTA_DATA(bpf_ops);
- int i;
-
- if (len == 0)
- return;
-
- fprintf(f, "bytecode \'%u,", len);
-
- for (i = 0; i < len - 1; i++)
- fprintf(f, "%hu %hhu %hhu %u,", ops[i].code, ops[i].jt,
- ops[i].jf, ops[i].k);
-
- fprintf(f, "%hu %hhu %hhu %u\'\n", ops[i].code, ops[i].jt,
- ops[i].jf, ops[i].k);
-}
-
static int bpf_parse_opt(struct filter_util *qu, char *handle,
int argc, char **argv, struct nlmsghdr *n)
{
@@ -195,6 +72,10 @@ static int bpf_parse_opt(struct filter_util *qu, char *handle,
while (argc > 0) {
if (matches(*argv, "run") == 0) {
bool from_file;
+ struct sock_filter bpf_ops[BPF_MAXINSNS];
+ __u16 bpf_len;
+ int ret;
+
NEXT_ARG();
if (strcmp(*argv, "bytecode-file") == 0) {
from_file = true;
@@ -206,10 +87,15 @@ static int bpf_parse_opt(struct filter_util *qu, char *handle,
return -1;
}
NEXT_ARG();
- if (bpf_parse_ops(argc, argv, n, from_file)) {
+ ret = bpf_parse_ops(argc, argv, bpf_ops, from_file);
+ if (ret < 0) {
fprintf(stderr, "Illegal \"bytecode\"\n");
return -1;
}
+ bpf_len = ret;
+ addattr16(n, MAX_MSG, TCA_BPF_OPS_LEN, bpf_len);
+ addattr_l(n, MAX_MSG, TCA_BPF_OPS, &bpf_ops,
+ bpf_len * sizeof(struct sock_filter));
} else if (matches(*argv, "classid") == 0 ||
strcmp(*argv, "flowid") == 0) {
unsigned handle;
diff --git a/tc/tc_bpf.c b/tc/tc_bpf.c
new file mode 100644
index 0000000..c6901d6
--- /dev/null
+++ b/tc/tc_bpf.c
@@ -0,0 +1,146 @@
+/*
+ * tc_bpf.c BPF common code
+ *
+ * This program is free software; you can distribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Daniel Borkmann <dborkman@redhat.com>
+ * Jiri Pirko <jiri@resnulli.us>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <string.h>
+#include <stdbool.h>
+#include <errno.h>
+#include <linux/filter.h>
+#include <linux/netlink.h>
+#include <linux/rtnetlink.h>
+
+#include "utils.h"
+#include "tc_util.h"
+#include "tc_bpf.h"
+
+int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
+ char **bpf_string, bool *need_release,
+ const char separator)
+{
+ char sp;
+
+ if (from_file) {
+ size_t tmp_len, op_len = sizeof("65535 255 255 4294967295,");
+ char *tmp_string;
+ FILE *fp;
+
+ tmp_len = sizeof("4096,") + BPF_MAXINSNS * op_len;
+ tmp_string = malloc(tmp_len);
+ if (tmp_string == NULL)
+ return -ENOMEM;
+
+ memset(tmp_string, 0, tmp_len);
+
+ fp = fopen(arg, "r");
+ if (fp == NULL) {
+ perror("Cannot fopen");
+ free(tmp_string);
+ return -ENOENT;
+ }
+
+ if (!fgets(tmp_string, tmp_len, fp)) {
+ free(tmp_string);
+ fclose(fp);
+ return -EIO;
+ }
+
+ fclose(fp);
+
+ *need_release = true;
+ *bpf_string = tmp_string;
+ } else {
+ *need_release = false;
+ *bpf_string = arg;
+ }
+
+ if (sscanf(*bpf_string, "%hu%c", bpf_len, &sp) != 2 ||
+ sp != separator) {
+ if (*need_release)
+ free(*bpf_string);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int bpf_parse_ops(int argc, char **argv, struct sock_filter *bpf_ops,
+ bool from_file)
+{
+ char *bpf_string, *token, separator = ',';
+ int ret = 0, i = 0;
+ bool need_release;
+ __u16 bpf_len = 0;
+
+ if (argc < 1)
+ return -EINVAL;
+ if (bpf_parse_string(argv[0], from_file, &bpf_len, &bpf_string,
+ &need_release, separator))
+ return -EINVAL;
+ if (bpf_len == 0 || bpf_len > BPF_MAXINSNS) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ token = bpf_string;
+ while ((token = strchr(token, separator)) && (++token)[0]) {
+ if (i >= bpf_len) {
+ fprintf(stderr, "Real program length exceeds encoded "
+ "length parameter!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (sscanf(token, "%hu %hhu %hhu %u,",
+ &bpf_ops[i].code, &bpf_ops[i].jt,
+ &bpf_ops[i].jf, &bpf_ops[i].k) != 4) {
+ fprintf(stderr, "Error at instruction %d!\n", i);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ i++;
+ }
+
+ if (i != bpf_len) {
+ fprintf(stderr, "Parsed program length is less than encoded"
+ "length parameter!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+ ret = bpf_len;
+
+out:
+ if (need_release)
+ free(bpf_string);
+
+ return ret;
+}
+
+void bpf_print_ops(FILE *f, struct rtattr *bpf_ops, __u16 len)
+{
+ struct sock_filter *ops = (struct sock_filter *) RTA_DATA(bpf_ops);
+ int i;
+
+ if (len == 0)
+ return;
+
+ fprintf(f, "bytecode \'%u,", len);
+
+ for (i = 0; i < len - 1; i++)
+ fprintf(f, "%hu %hhu %hhu %u,", ops[i].code, ops[i].jt,
+ ops[i].jf, ops[i].k);
+
+ fprintf(f, "%hu %hhu %hhu %u\'\n", ops[i].code, ops[i].jt,
+ ops[i].jf, ops[i].k);
+}
diff --git a/tc/tc_bpf.h b/tc/tc_bpf.h
new file mode 100644
index 0000000..08cca92
--- /dev/null
+++ b/tc/tc_bpf.h
@@ -0,0 +1,28 @@
+/*
+ * tc_bpf.h BPF common code
+ *
+ * This program is free software; you can distribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Daniel Borkmann <dborkman@redhat.com>
+ * Jiri Pirko <jiri@resnulli.us>
+ */
+
+#ifndef _TC_BPF_H_
+#define _TC_BPF_H_ 1
+
+#include <stdio.h>
+#include <linux/filter.h>
+#include <linux/netlink.h>
+#include <linux/rtnetlink.h>
+
+int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
+ char **bpf_string, bool *need_release,
+ const char separator);
+int bpf_parse_ops(int argc, char **argv, struct sock_filter *bpf_ops,
+ bool from_file);
+void bpf_print_ops(FILE *f, struct rtattr *bpf_ops, __u16 len);
+
+#endif
--
1.9.3
^ permalink raw reply related
* [patch iproute2 repost 2/2] tc: add support for BPF based actions
From: Jiri Pirko @ 2015-01-19 15:56 UTC (permalink / raw)
To: netdev; +Cc: jhs, stephen
In-Reply-To: <1421682990-11072-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/tc_act/tc_bpf.h | 31 +++++++
tc/Makefile | 1 +
tc/m_bpf.c | 183 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 215 insertions(+)
create mode 100644 include/linux/tc_act/tc_bpf.h
create mode 100644 tc/m_bpf.c
diff --git a/include/linux/tc_act/tc_bpf.h b/include/linux/tc_act/tc_bpf.h
new file mode 100644
index 0000000..5288bd7
--- /dev/null
+++ b/include/linux/tc_act/tc_bpf.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2015 Jiri Pirko <jiri@resnulli.us>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_TC_BPF_H
+#define __LINUX_TC_BPF_H
+
+#include <linux/pkt_cls.h>
+
+#define TCA_ACT_BPF 13
+
+struct tc_act_bpf {
+ tc_gen;
+};
+
+enum {
+ TCA_ACT_BPF_UNSPEC,
+ TCA_ACT_BPF_TM,
+ TCA_ACT_BPF_PARMS,
+ TCA_ACT_BPF_OPS_LEN,
+ TCA_ACT_BPF_OPS,
+ __TCA_ACT_BPF_MAX,
+};
+#define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
+
+#endif
diff --git a/tc/Makefile b/tc/Makefile
index 15f68ce..d831a15 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -46,6 +46,7 @@ TCMODULES += m_skbedit.o
TCMODULES += m_csum.o
TCMODULES += m_simple.o
TCMODULES += m_vlan.o
+TCMODULES += m_bpf.o
TCMODULES += p_ip.o
TCMODULES += p_icmp.o
TCMODULES += p_tcp.o
diff --git a/tc/m_bpf.c b/tc/m_bpf.c
new file mode 100644
index 0000000..611135e
--- /dev/null
+++ b/tc/m_bpf.c
@@ -0,0 +1,183 @@
+/*
+ * m_bpf.c BFP based action module
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Jiri Pirko <jiri@resnulli.us>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <string.h>
+#include <stdbool.h>
+#include <linux/tc_act/tc_bpf.h>
+
+#include "utils.h"
+#include "rt_names.h"
+#include "tc_util.h"
+#include "tc_bpf.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... bpf ...\n");
+ fprintf(stderr, "\n");
+ fprintf(stderr, " [inline]: run bytecode BPF_BYTECODE\n");
+ fprintf(stderr, " [from file]: run bytecode-file FILE\n");
+ fprintf(stderr, "\n");
+ fprintf(stderr, "Where BPF_BYTECODE := \'s,c t f k,c t f k,c t f k,...\'\n");
+ fprintf(stderr, " c,t,f,k and s are decimals; s denotes number of 4-tuples\n");
+ fprintf(stderr, "Where FILE points to a file containing the BPF_BYTECODE string\n");
+ fprintf(stderr, "\nACTION_SPEC := ... look at individual actions\n");
+ fprintf(stderr, "NOTE: CLASSID is parsed as hexadecimal input.\n");
+}
+
+static void usage(void)
+{
+ explain();
+ exit(-1);
+}
+
+static int parse_bpf(struct action_util *a, int *argc_p, char ***argv_p,
+ int tca_id, struct nlmsghdr *n)
+{
+ int argc = *argc_p;
+ char **argv = *argv_p;
+ struct rtattr *tail;
+ struct tc_act_bpf parm = { 0 };
+ struct sock_filter bpf_ops[BPF_MAXINSNS];
+ __u16 bpf_len = 0;
+
+ if (matches(*argv, "bpf") != 0)
+ return -1;
+
+ NEXT_ARG();
+
+ while (argc > 0) {
+ if (matches(*argv, "run") == 0) {
+ bool from_file;
+ int ret;
+
+ NEXT_ARG();
+ if (strcmp(*argv, "bytecode-file") == 0) {
+ from_file = true;
+ } else if (strcmp(*argv, "bytecode") == 0) {
+ from_file = false;
+ } else {
+ fprintf(stderr, "unexpected \"%s\"\n", *argv);
+ explain();
+ return -1;
+ }
+ NEXT_ARG();
+ ret = bpf_parse_ops(argc, argv, bpf_ops, from_file);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"bytecode\"\n");
+ return -1;
+ }
+ bpf_len = ret;
+ } else if (matches(*argv, "help") == 0) {
+ usage();
+ } else {
+ break;
+ }
+ argc--;
+ argv++;
+ }
+
+ parm.action = TC_ACT_PIPE;
+ if (argc) {
+ if (matches(*argv, "reclassify") == 0) {
+ parm.action = TC_ACT_RECLASSIFY;
+ NEXT_ARG();
+ } else if (matches(*argv, "pipe") == 0) {
+ parm.action = TC_ACT_PIPE;
+ NEXT_ARG();
+ } else if (matches(*argv, "drop") == 0 ||
+ matches(*argv, "shot") == 0) {
+ parm.action = TC_ACT_SHOT;
+ NEXT_ARG();
+ } else if (matches(*argv, "continue") == 0) {
+ parm.action = TC_ACT_UNSPEC;
+ NEXT_ARG();
+ } else if (matches(*argv, "pass") == 0) {
+ parm.action = TC_ACT_OK;
+ NEXT_ARG();
+ }
+ }
+
+ if (argc) {
+ if (matches(*argv, "index") == 0) {
+ NEXT_ARG();
+ if (get_u32(&parm.index, *argv, 10)) {
+ fprintf(stderr, "bpf: Illegal \"index\"\n");
+ return -1;
+ }
+ argc--;
+ argv++;
+ }
+ }
+
+ if (!bpf_len) {
+ fprintf(stderr, "bpf: Bytecode needs to be passed\n");
+ explain();
+ return -1;
+ }
+
+ tail = NLMSG_TAIL(n);
+ addattr_l(n, MAX_MSG, tca_id, NULL, 0);
+ addattr_l(n, MAX_MSG, TCA_ACT_BPF_PARMS, &parm, sizeof(parm));
+ addattr16(n, MAX_MSG, TCA_ACT_BPF_OPS_LEN, bpf_len);
+ addattr_l(n, MAX_MSG, TCA_ACT_BPF_OPS, &bpf_ops,
+ bpf_len * sizeof(struct sock_filter));
+ tail->rta_len = (char *)NLMSG_TAIL(n) - (char *)tail;
+
+ *argc_p = argc;
+ *argv_p = argv;
+ return 0;
+}
+
+static int print_bpf(struct action_util *au, FILE *f, struct rtattr *arg)
+{
+ struct rtattr *tb[TCA_ACT_BPF_MAX + 1];
+ struct tc_act_bpf *parm;
+
+ if (arg == NULL)
+ return -1;
+
+ parse_rtattr_nested(tb, TCA_ACT_BPF_MAX, arg);
+
+ if (!tb[TCA_ACT_BPF_PARMS]) {
+ fprintf(f, "[NULL bpf parameters]");
+ return -1;
+ }
+ parm = RTA_DATA(tb[TCA_ACT_BPF_PARMS]);
+
+ fprintf(f, " bpf ");
+
+ if (tb[TCA_ACT_BPF_OPS] && tb[TCA_ACT_BPF_OPS_LEN])
+ bpf_print_ops(f, tb[TCA_ACT_BPF_OPS],
+ rta_getattr_u16(tb[TCA_ACT_BPF_OPS_LEN]));
+
+ fprintf(f, "\n\tindex %d ref %d bind %d", parm->index, parm->refcnt,
+ parm->bindcnt);
+
+ if (show_stats) {
+ if (tb[TCA_ACT_BPF_TM]) {
+ struct tcf_t *tm = RTA_DATA(tb[TCA_ACT_BPF_TM]);
+ print_tm(f, tm);
+ }
+ }
+
+ fprintf(f, "\n ");
+
+ return 0;
+}
+
+struct action_util bpf_action_util = {
+ .id = "bpf",
+ .parse_aopt = parse_bpf,
+ .print_aopt = print_bpf,
+};
--
1.9.3
^ permalink raw reply related
* NetDev 0.1 conference new proposals accepted + misc updates
From: Jamal Hadi Salim @ 2015-01-19 15:28 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, lwn-T1hC0tSOHrs,
netdev01-wool9L35kiczKOhml7GhPkB+6BGkLq7r,
lartc-u79uwXL29TY76Z2rM5mHXA, netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
Cc: Richard Guy Briggs, info-4R/QDJtgm2dg9hUCZPvPmw
Fellow netheads:
On behalf of rgb, yours truly is sending out the weekly announcement.
This conference is turning out to be _the best ever_ Linux networking
content put together under one roof. You will be committing a netdev
crime if you dont show up!
Please spread the news. Forward this email appropriately.
First things first.
A reminder that the Westin Hotel is still holding a block of rooms for
Netdev01 at a guaranteed rate of $159.00 or $179.00 (depending on the
type of room required) and there are still rooms available.
That guarantee expires on January 23, so please dont procastinate
and book now. The rates *WILL* go up.
Reservations:
https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802&key=1AC9C1F8
Please register soon to help us plan this event better.
Registration https://onlineregistrations.ca/netdev01/
$100/day, or $350 for 4 days (Cdn dollars, reel cheep).
(online reg closes Feb 12th). Again:
Registering helps us plan properly for numbers of attendees,
ensuring venue sizes and supplies are appropriate without
wasting resources.
NetDev 0.1 would like to gratefully acknowledge our sponsors:
https://netdev01.org/sponsors
Google https://www.google.ca
Qualcomm https://www.qualcomm.com/
Verizon http://www.verizon.com/
Cumulus Networks http://cumulusnetworks.com/
Mojatatu Networks http://mojatatu.com/
There are a few more talks and tutorials and BOFs/workshops
in the pipeline (we will close acceptance at the end of the week,
so if you want to submit, please do it NOW).
Here is an update on new proposals accepted this past week for NetDev
0.1 that you may have missed if you aren't following the RSS feed or
twitter:
New Sponsors (All listed at: https://www.netdev01.org/sponsors)
=============
Qualcomm - Without sponsors like Qualcomm netdev 0.1 couldnt have
have happened. Thanks Qualcomm for your support of the open source
community.
Google - Google is a giant in the open source world. We thank them
for their sponsorship.
Accepted talks: (All listed: https://www.netdev01.org/sessions )
===============
1) Breaking Open Linux Switching Drivers by Andy Gospodarek
Andy will talk about taking an evolutionary path of a compromise
to integrate between vendor SDKs and the Linux kernel for hardware
offload. Graphics cards all over again? Come and find out.
https://www.netdev01.org/sessions/19
2) Weighing Three Methods of Scaling UDP Applications by Alan Dekok
Alan, the maintainer of FreeRadius, has had to battle UDP for years.
In this talk he will describe his experiences on 3 different approaches
he has recently taken to try and scale UDP applications on Linux
https://www.netdev01.org/sessions/20
3) TC Classifier Action Subsystem by Jamal Hadi Salim
Jamal will describe the tc classifier-action subsystem in details (A
decade too late?). He claims to be inspired by two talks at netdev01
which refer to this subsystem. He also claims it is a better
architecture than OF and P4. Come beat up on him.
https://www.netdev01.org/sessions/21
4) MLAG (or Multi-Chassis Link aggregation Group) integration with
Linux by Matty Kadosh
Mellanox MLAG implementation at https://github.com/open-ethernet/MLAG
will be discussed in this talk. Matty will talk about experiences and
will try to convince us that it is time to mainstream MLAG.
https://www.netdev01.org/sessions/22
5) MLAG on Linux - Lessons Learned by Scott Emery
Cumulus Networks has extensive MLAG deployment on Linux using hardware
offloads on high speed hardware.
They have had to battle dragons in many dungeons and slay
many monsters along the way. Come hear all that experience in one talk.
https://www.netdev01.org/sessions/23
Accepted Tutorials (All listed: https://www.netdev01.org/sessions )
===================
1)Hardware Accelerating Linux Network Functions by
Roopa Prabhu and Toshiaki Makita
Everything you ever wanted to know about using Linux bridging
variations for virtualization, data centre & enterprise, L3, ACLs and
more. How well do you know how to use bridge/brctl/ip/ethtool and
their friends to setup a desired network(bridge, SRIOV, Macvlan etc)?
Roopa and Toshiaki will try to guide you through this vast ocean of
knowledge. You will get to learn about how to learn the theory
and practise and beauty of using these toolsets consistently
whether on a NIC, offloaded-NIC or multi-terabit capacity switch
hardware.
https://www.netdev01.org/sessions/24
More coming in future updates.
If youve got this far reading - please go and register.
cheers,
jamal (on behalf of Richard Guy Briggs)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
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