* Re: [PATCH/RFC flow-net-next 04/10] net: flow: Add counters to flows
From: Simon Horman @ 2015-01-05 2:10 UTC (permalink / raw)
To: Arad, Ronen; +Cc: Fastabend, John R, netdev@vger.kernel.org
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505DD0E24@ORSMSX101.amr.corp.intel.com>
On Mon, Dec 29, 2014 at 07:31:41AM +0000, Arad, Ronen wrote:
>
>
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >Behalf Of Simon Horman
> >Sent: Monday, December 29, 2014 4:16 AM
> >To: Fastabend, John R; netdev@vger.kernel.org
> >Cc: Simon Horman
> >Subject: [PATCH/RFC flow-net-next 04/10] net: flow: Add counters to flows
> >
> >It may be useful for hardware flow table support for counters to be exposed
> >via the flow API. One possible use case of this is for Open vSwitch to use
> >the flow API in conjunction with its existing datapath flow management
> >scheme which in a nutshell treats the datapath as a cache that times out
> >idle entries.
> >
> >This patch exposes optionally exposes three counters:
> >- Number of packets that have matched a flow
> >- Number of bytes of packets that have matched a flow
> >- The time in ms when the flow was last hit
> >
> >Inspired by the flow counters present in Open Flow.
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >
> >---
> >
> >Compile tested only
> >---
> > include/uapi/linux/if_flow.h | 24 ++++++++++++++++++++++++
> > net/core/flow_table.c | 27 +++++++++++++++++++++++++++
> > 2 files changed, 51 insertions(+)
> >
> >diff --git a/include/uapi/linux/if_flow.h b/include/uapi/linux/if_flow.h
> >index 28da45b..18214ea 100644
> >--- a/include/uapi/linux/if_flow.h
> >+++ b/include/uapi/linux/if_flow.h
> >@@ -127,6 +127,9 @@
> > * [NET_FLOW_ATTR_PRIORITY]
> > * [NET_FLOW_ATTR_IDLE_TIMEOUT]
> > * [NET_FLOW_ATTR_HARD_TIMEOUT]
> >+ * [NET_FLOW_ATTR_BYTE_COUNT]
> >+ * [NET_FLOW_ATTR_PACKET_COUNT]
> >+ * [NET_FLOW_ATTR_LAST_USED]
> > * [NET_FLOW_ATTR_MATCHES]
> > * [NET_FLOW_FIELD_REF]
> > * [NET_FLOW_FIELD_REF]
> >@@ -153,6 +156,9 @@
> > * [NET_FLOW_ATTR_PRIORITY]
> > * [NET_FLOW_ATTR_IDLE_TIMEOUT]
> > * [NET_FLOW_ATTR_HARD_TIMEOUT]
> >+ * [NET_FLOW_ATTR_BYTE_COUNT]
> >+ * [NET_FLOW_ATTR_PACKET_COUNT]
> >+ * [NET_FLOW_ATTR_LAST_USED]
> > * [NET_FLOW_MATCHES]
> > * [NET_FLOW_FIELD_REF]
> > * [NET_FLOW_FIELD_REF]
> >@@ -365,6 +371,9 @@ enum {
> > * @idle_timeout idle timeout of flow in seconds. Zero for no timeout.
> > * @hard_timeout timeout of flow regardless of use in seconds.
> > * Zero for no timeout.
> >+ * @byte_count bytes recieved
> >+ * @byte_count packets recieved
> >+ * @last_used time of most recent use (msec since system initialisation)
> > *
> > * Flows must match all entries in match set.
> > */
> >@@ -374,6 +383,9 @@ struct net_flow_flow {
> > int priority;
> > __u32 idle_timeout;
> > __u32 hard_timeout;
> >+ __u64 byte_count;
> >+ __u64 packet_count;
> >+ __u64 last_used;
> > struct net_flow_field_ref *matches;
> > struct net_flow_action *actions;
> > };
> >@@ -414,6 +426,9 @@ enum {
> > NET_FLOW_ATTR_ACTIONS,
> > NET_FLOW_ATTR_IDLE_TIMEOUT,
> > NET_FLOW_ATTR_HARD_TIMEOUT,
> >+ NET_FLOW_ATTR_BYTE_COUNT,
> >+ NET_FLOW_ATTR_PACKET_COUNT,
> >+ NET_FLOW_ATTR_LAST_USED,
> > __NET_FLOW_ATTR_MAX,
> > };
> > #define NET_FLOW_ATTR_MAX (__NET_FLOW_ATTR_MAX - 1)
> >@@ -465,6 +480,15 @@ enum {
> >
> > /* Table supports idle timeout of flows */
> > NET_FLOW_TABLE_F_HARD_TIMEOUT = (1 << 1),
> >+
> >+ /* Table supports byte counter for flows */
> >+ NET_FLOW_TABLE_F_BYTE_COUNT = (1 << 2),
> >+
> >+ /* Table supports packet counter for flows */
> >+ NET_FLOW_TABLE_F_PACKET_COUNT = (1 << 3),
> >+
> >+ /* Table supports last used counter for flows */
> >+ NET_FLOW_TABLE_F_PACKET_LAST_USED = (1 << 4),
> > };
> >
> > #if 0
> >diff --git a/net/core/flow_table.c b/net/core/flow_table.c
> >index 89ba9bc..070e646 100644
> >--- a/net/core/flow_table.c
> >+++ b/net/core/flow_table.c
> >@@ -54,6 +54,9 @@ struct nla_policy net_flow_flow_policy[NET_FLOW_ATTR_MAX +
> >1] = {
> > [NET_FLOW_ATTR_PRIORITY] = { .type = NLA_U32 },
> > [NET_FLOW_ATTR_IDLE_TIMEOUT] = { .type = NLA_U32 },
> > [NET_FLOW_ATTR_HARD_TIMEOUT] = { .type = NLA_U32 },
> >+ [NET_FLOW_ATTR_BYTE_COUNT] = { .type = NLA_U64 },
> >+ [NET_FLOW_ATTR_PACKET_COUNT] = { .type = NLA_U64 },
> >+ [NET_FLOW_ATTR_LAST_USED] = { .type = NLA_U64 },
> > [NET_FLOW_ATTR_MATCHES] = { .type = NLA_NESTED },
> > [NET_FLOW_ATTR_ACTIONS] = { .type = NLA_NESTED },
> > };
> >@@ -206,6 +209,16 @@ int net_flow_put_flow(struct sk_buff *skb, struct
> >net_flow_flow *flow)
> > nla_put_u32(skb, NET_FLOW_ATTR_HARD_TIMEOUT, flow->hard_timeout))
> > goto flows_put_failure;
> >
> >+ if (flow->byte_count &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_BYTE_COUNT, flow->byte_count))
> >+ goto flows_put_failure;
> >+ if (flow->packet_count &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_PACKET_COUNT, flow->packet_count))
> >+ goto flows_put_failure;
> >+ if (flow->last_used &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_LAST_USED, flow->last_used))
> >+ goto flows_put_failure;
> >+
> The flow byte_count, packet_count, and last_used fields are defined as __u64 and related netlink attributes are of type NLA_U64 but nla_put_u32() is used to add them to the netlink msg.
Thanks, I will fix that up by using nla_put_u64().
> > matches = nla_nest_start(skb, NET_FLOW_ATTR_MATCHES);
> > if (!matches)
> > goto flows_put_failure;
> >@@ -536,6 +549,13 @@ static int net_flow_get_flow(struct net_flow_flow *flow,
> >struct nlattr *attr)
> > if (f[NET_FLOW_ATTR_HARD_TIMEOUT])
> > flow->hard_timeout = nla_get_u32(f[NET_FLOW_ATTR_HARD_TIMEOUT]);
> >
> >+ if (f[NET_FLOW_ATTR_BYTE_COUNT])
> >+ flow->byte_count = nla_get_u64(f[NET_FLOW_ATTR_BYTE_COUNT]);
> >+ if (f[NET_FLOW_ATTR_PACKET_COUNT])
> >+ flow->packet_count = nla_get_u64(f[NET_FLOW_ATTR_PACKET_COUNT]);
> >+ if (f[NET_FLOW_ATTR_LAST_USED])
> >+ flow->last_used = nla_get_u64(f[NET_FLOW_ATTR_LAST_USED]);
> >+
> > flow->matches = NULL;
> > flow->actions = NULL;
> >
> >@@ -1386,6 +1406,13 @@ static int net_flow_table_cmd_flows(struct sk_buff
> >*recv_skb,
> > if (this.hard_timeout)
> > used_features |= NET_FLOW_TABLE_F_HARD_TIMEOUT;
> >
> >+ if (this.byte_count)
> >+ used_features |= NET_FLOW_TABLE_F_BYTE_COUNT;
> >+ if (this.packet_count)
> >+ used_features |= NET_FLOW_TABLE_F_PACKET_COUNT;
> >+ if (this.last_used)
> >+ used_features |= NET_FLOW_TABLE_F_PACKET_LAST_USED;
> >+
> > err = net_flow_table_check_features(dev, this.table_id,
> > used_features);
> > if (err)
> >--
> >2.1.3
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH/RFC flow-net-next 02/10] net: flow: Add features to tables
From: Simon Horman @ 2015-01-05 2:18 UTC (permalink / raw)
To: Cong Wang; +Cc: John Fastabend, netdev
In-Reply-To: <CAHA+R7NmfUpYcKfW_Gck2HaANH3OQk-9BAYZCXnBtGO1eV13xg@mail.gmail.com>
On Mon, Dec 29, 2014 at 03:03:39PM -0800, Cong Wang wrote:
> On Sun, Dec 28, 2014 at 6:15 PM, Simon Horman
> <simon.horman@netronome.com> wrote:
> > +static struct net_flow_table *net_flow_table_get_table(struct net_device *dev,
> > + int table_uid)
> > +{
> > + struct net_flow_table **tables;
> > + int i;
> > +
> > + tables = net_flow_get_tables(dev);
> > + if (IS_ERR(tables))
> > + return ERR_PTR(PTR_ERR(tables));
>
> Seriously? :)
I was looking for a way to handle the type of tables being different
to the return type of net_flow_table_get_table().
Would you recommend a cast?
return (struct net_flow_table *)tables;
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: Ben Hutchings @ 2015-01-05 2:30 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: David Decotigny, Amir Vadai, Florian Fainelli, Linux NetDev,
Linux Kernel Mailing List, linux-api, David Decotigny,
David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru, Govindaraj
In-Reply-To: <CAHo-Ooxi8V_58b456vePY9_7ChuBe0jxEVHvGkGvRBpAR744yA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
On Mon, 2015-01-05 at 01:34 +0100, Maciej Żenczykowski wrote:
> >> I can send updates to other drivers, even though it's rather pointless
> >> to update 1G drivers at this point for example. Please let me know,
> >> but I'd prefer to do this in follow-up patches outside this first
> >> patch series.
> > [...]
> >
> > They should be changed to ensure they reject setting any of the high
> > advertising flags, but it's not urgent.
>
> if old drivers advertised a get/set_bits function while new drivers
> advertised a get/set_new_bits function,
> you could not updated any old drivers, and simply take care of
> rejecting invalid bits in core, by calling set_new_bits if provided,
> if not, rejecting bad bits and calling set_bits if no bad bits were
> set.
We've never checked that the reserved fields are zero before, and I
think there are still drivers that don't fully validate the existing 32
bits. So while I think drivers should fully validate the advertising
flags, userland generally can't assume they do. And therefore I don't
think it's worth adding complexity to the ethtool core that only partly
fixes this.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-05 2:34 UTC (permalink / raw)
To: Arend van Spriel
Cc: brudley, Franky Lin, meuleman, kvalo, linville, pieterpg,
hdegoede, wens, linux-wireless, brcm80211-dev-list, netdev,
linux-kernel
In-Reply-To: <54A3C837.6040400@broadcom.com>
Hi Arend,
Where to find your patch for this?
Thanks,
Zhonghui
On 2014/12/31 17:56, Arend van Spriel wrote:
> On 12/31/14 09:20, Fu, Zhonghui wrote:
>> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>> Date: Mon, 29 Dec 2014 21:25:31 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>
> We have a patch queued up for this as well, but this one looks good enough although I personally prefer container_of() instead of dev_to_sdio_func().
>
> Acked-by: Arend van Spriel <arend@broadcom.com>
>> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>> ---
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
>> 1 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 3c06e93..eee7818 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
>> static int brcmf_ops_sdio_suspend(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2) {
>> + return 0;
>> + }
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> atomic_set(&sdiodev->suspend, true);
>>
>> if (sdiodev->wowl_enabled) {
>> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2) {
>> + return 0;
>> + }
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> if (sdiodev->pdata->oob_irq_supported)
>> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
>> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
>> -- 1.7.1
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-05 2:37 UTC (permalink / raw)
To: Sergei Shtylyov, brudley, Arend van Spriel, Franky Lin, meuleman,
kvalo, linville, pieterpg, hdegoede, wens, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <54A3DC80.1080505@cogentembedded.com>
Hi Sergei,
You are right, I will apply your advice in next version of this patch.
Thanks,
Zhonghui
On 2014/12/31 19:22, Sergei Shtylyov wrote:
> Hello.
>
> On 12/31/2014 11:20 AM, Fu, Zhonghui wrote:
>
>> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu <zhonghui.fu@linux.intel.com>
>> Date: Mon, 29 Dec 2014 21:25:31 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>
>> Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
>> ---
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
>> 1 files changed, 17 insertions(+), 2 deletions(-)
>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 3c06e93..eee7818 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
>> static int brcmf_ops_sdio_suspend(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2) {
>> + return 0;
>> + }
>
> {} not needed.
>
> [...]
>> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2) {
>> + return 0;
>> + }
>
> Same here.
>
> [...]
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/3] swdev: add IPv4 routing offload
From: David Miller @ 2015-01-05 3:17 UTC (permalink / raw)
To: sfeldma; +Cc: netdev, jiri, john.fastabend, tgraf, jhs, andy, roopa
In-Reply-To: <1420169361-31767-1-git-send-email-sfeldma@gmail.com>
From: sfeldma@gmail.com
Date: Thu, 1 Jan 2015 19:29:18 -0800
> This patch set adds L3 routing offload support for IPv4 routes. The idea is to
> mirror routes installed in the kernel's FIB down to a hardware switch device to
> offload the data forwarding path for L3. Only the data forwarding path is
> intercepted. Control and management of the kernel's FIB remains with the
> kernel.
It looks like the design for this is still under discussion and that
new patches of whatever is decided upon will be forthcoming
eventually.
Can I ask you guys a huge favor? DO NOT quote the entire patch when
discussing these changes.
The thread for patch #1 was so time consuming to scan and read in
patchwork because you guys did this.
I know it takes a little bit more work to select and delete the patch
content in the quoted area, but you really have to do this because
otherwise it is a huge burden for reviewers trying to follow the
conversation.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: cpsw: fix hangs with interrupts
From: David Miller @ 2015-01-05 3:19 UTC (permalink / raw)
To: balbi; +Cc: mugunthanvnm, yegorslists, linux-omap, netdev, stable
In-Reply-To: <1420236959-32444-1-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Fri, 2 Jan 2015 16:15:59 -0600
> The CPSW IP implements pulse-signaled interrupts. Due to
> that we must write a correct, pre-defined value to the
> CPDMA_MACEOIVECTOR register so the controller generates
> a pulse on the correct IRQ line to signal the End Of
> Interrupt.
>
> The way the driver is written today, all four IRQ lines
> are requested using the same IRQ handler and, because of
> that, we could fall into situations where a TX IRQ fires
> but we tell the controller that we ended an RX IRQ (or
> vice-versa). This situation triggers an IRQ storm on the
> reserved IRQ 127 of INTC which will in turn call ack_bad_irq()
> which will, then, print a ton of:
...
> Reported-by: Yegor Yefremov <yegorslists@googlemail.com>
> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly)
> Cc: <stable@vger.kernel.org> # v3.9+
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] GMAC: fix simple_return.cocci warnings
From: David Miller @ 2015-01-05 3:20 UTC (permalink / raw)
To: joe
Cc: fengguang.wu, roger.chen, kbuild-all, peppe.cavallaro, netdev,
linux-kernel
In-Reply-To: <1420246005.23591.7.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 02 Jan 2015 16:46:45 -0800
> On Sat, 2015-01-03 at 08:25 +0800, kbuild test robot wrote:
>> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c:425:1-4: WARNING: end returns can be simpified
>>
>> Simplify a trivial if-return sequence. Possibly combine with a
>> preceding function call.
>> Generated by: scripts/coccinelle/misc/simple_return.cocci
>>
>> CC: Roger Chen <roger.chen@rock-chips.com>
>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>> ---
>>
>> dwmac-rk.c | 6 +-----
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> @@ -422,11 +422,7 @@ static int rk_gmac_init(struct platform_
>> if (ret)
>> return ret;
>>
>> - ret = gmac_clk_enable(bsp_priv, true);
>> - if (ret)
>> - return ret;
>> -
>> - return 0;
>> + return gmac_clk_enable(bsp_priv, true);
>
> I think this change is not particularly better.
>
> When the pattern is multiply repeated like:
...
> I think it's better to not change the last
> test in the sequence just to minimize overall
> line count.
I think it's a wash and that both ways are about the same to me.
I won't apply this, sorry.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Geneve Cleanups
From: David Miller @ 2015-01-05 3:22 UTC (permalink / raw)
To: jesse; +Cc: netdev
In-Reply-To: <1420251965-44794-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 2 Jan 2015 18:26:01 -0800
> Much of the basis for the Geneve code comes from VXLAN. However,
> Geneve is quite a bit simpler than VXLAN and so this cleans up a
> lot of the infrastruction - particularly around locking - where the
> extra complexity is not necessary.
I like it, series applied, thanks Jesse.
^ permalink raw reply
* Re: [PATCH 1/1 linux-next] hp100: simplify hp100_module_init
From: David Miller @ 2015-01-05 3:23 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, perex, netdev
In-Reply-To: <1420292656-14429-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Sat, 3 Jan 2015 14:44:16 +0100
> -Avoid double goto and directly return err where possible.
> -Remove unused labels which fixes:
>
> drivers/net/ethernet/hp/hp100.c:3047:2: warning: label
> 'out3' defined but not used [-Wunused-label]
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> This is untested.
Having a sole lone return statement that all flows of control
branch to makes the code easier to audit, than to have a huge
block where each return statement has to be audited independently
for potential cleanups.
Added to the fact that this patch is completely untested, I'm
not applying this, sorry.
^ permalink raw reply
* Re: [PATCH net-next] enic: reconfigure resources for kdump crash kernel
From: David Miller @ 2015-01-05 3:24 UTC (permalink / raw)
To: _govind; +Cc: netdev, ssujith, benve
In-Reply-To: <1420293944-7614-1-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Sat, 3 Jan 2015 19:35:44 +0530
> When running in kdump kernel, reduce number of resources used by the driver.
> This will enable NIC to operate in low memory kdump kernel environment.
>
> Also change the driver version to .83
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] qlcnic: Fix dump_skb output
From: David Miller @ 2015-01-05 3:24 UTC (permalink / raw)
To: joe; +Cc: shahed.shaikh, netdev, linux-kernel
In-Reply-To: <1420336216.2619.9.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sat, 03 Jan 2015 17:50:16 -0800
> Use normal facilities to avoid printing each byte
> on a separate line.
>
> Now emits at KERN_DEBUG instead of KERN_INFO.
>
> Signed-off-by: Joe Perches <joe@perches.com>
This looks fine, applied, thanks Joe.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2015-01-05 3:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, richardcochran,
jeffrey.t.kirsher
In-Reply-To: <20150103.144530.1032237292364564169.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
Hi David,
On Sat, 03 Jan 2015 14:45:30 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sat, 3 Jan 2015 09:11:01 +1100
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp':
> > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration]
> > mdev->cycles.mask = CLOCKSOURCE_MASK(48);
>
> Stephen please let me know if this failure is persisting.
All the ones I reported are fixed, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] net: wireless: rtlwifi: btcoexist: halbtc8821a2ant: Remove some unused functions
From: Julian Calaby @ 2015-01-05 4:05 UTC (permalink / raw)
To: Larry Finger
Cc: Rickard Strandqvist, Chaoming Li, Kalle Valo, Greg Kroah-Hartman,
Fengguang Wu,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development, Linux Kernel Mailing List
In-Reply-To: <54A9ECC7.6040900-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Hi Larry,
On Mon, Jan 5, 2015 at 12:45 PM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
> On 01/03/2015 06:03 AM, Rickard Strandqvist wrote:
>>
>> 2015-01-03 7:05 GMT+01:00 Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>:
>>
>>> On 01/02/2015 02:26 PM, Rickard Strandqvist wrote:
>>>
>>>> Removes some functions that are not used anywhere:
>>>> ex_halbtc8821a2ant_periodical() ex_halbtc8821a2ant_halt_notify()
>>>> ex_halbtc8821a2ant_bt_info_notify()
>>>> ex_halbtc8821a2ant_special_packet_notify()
>>>> ex_halbtc8821a2ant_connect_notify() ex_halbtc8821a2ant_scan_notify()
>>>> ex_halbtc8821a2ant_lps_notify() ex_halbtc8821a2ant_ips_notify()
>>>> ex_halbtc8821a2ant_display_coex_info() ex_halbtc8821a2ant_init_coex_dm()
>>>> ex_halbtc8821a2ant_init_hwconfig()
>>>>
>>>> This was partially found by using a static code analysis program called
>>>> cppcheck.
>>>>
>>>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@
>>>> spectrumdigital.se>
>>>>
>>>
>>> I know that you have been told that including "net: wireless:" in the
>>> subject line is discouraged. Please do not do this again. The staging
>>> directory is different as GregKH uses "staging:" in the subject to route
>>> patches, but wireless does not.
>>>
>>> As to the patch, NACK for the simple reason that I am currently working
>>> on
>>> a number of changes to btcoexist. Some of these routines may end up being
>>> removed, but others will not. Having your patch remove them, and one of
>>> mine adding them back just constitutes a lot of churning of the source.
>>> In
>>> addition, it greatly increases the probability of the source trees
>>> becoming
>>> unsynchronized and getting merge conflicts.
>>>
>>> Larry
>>>
>>>
>>
>> Hi Larry
>>
>> I do not recognize that there has been no diskution on the subject of
>> "net:
>> wireless:"
>> I use some sed call for this, so it's easy to fix. You want the "net:
>> wireless:" part completely erased then?
>> I check in Documentation/ but find any clear info for this.
>>
>> Sorry for the patch, is there any way for me to see that this is something
>> that is being worked on?
>
>
> These patches are the result of private communications between the Realtek
> engineers and me. The only publication is in the "rock" branch of the git
> repo at http://github.com/lwfinger/rtlwifi_new.git.
>
> I do not understand the "use of some 'sed' call". If you edit the source and
> add it to the git repo with the add and commit operations, then format-patch
> gives you exactly what you need, and send-email does that operation.
I suspect he means how he makes the subject lines. I'm guessing something like:
echo $PATH | sed 's/^.*\/drivers\///;s/\//: /;s/\.c$/: Remove some
unused functions/;'
Thanks,
--
Julian Calaby
Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Profile: http://www.google.com/profiles/julian.calaby/
--
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
* Re: [PATCH net-next] rhashtable: fix missing header
From: David Miller @ 2015-01-05 4:12 UTC (permalink / raw)
To: tgraf; +Cc: ying.xue, netdev
In-Reply-To: <20150104091908.GA15305@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Sun, 4 Jan 2015 09:19:08 +0000
> On 01/04/15 at 03:25pm, Ying Xue wrote:
>> Fixup below build error:
>>
>> include/linux/rhashtable.h: At top level:
>> include/linux/rhashtable.h:118:34: error: field ???mutex??? has incomplete type
>
> Just wondering, is this your new code that didn't compile? The code
> compiled fine for me for the existing users.
>
>> Signed-off-by: Ying Xue <ying.xue@windriver.com>
>
> Fixes: 97defe1e ("rhashtable: Per bucket locks & deferred expansion/shrinking")
> Acked-by: Thomas Graf <tgraf@suug.ch>
I'm applying this now as rhashtable.h really needs to include mutex.h
as it does use it's interfaces, regardless of whether it does actually
introduce a build error currently or not.
^ permalink raw reply
* Re: [PATCH net-next] list_nulls: fix missing header
From: David Miller @ 2015-01-05 4:12 UTC (permalink / raw)
To: ying.xue; +Cc: netdev
In-Reply-To: <1420356275-7340-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Sun, 4 Jan 2015 15:24:35 +0800
> Fixup below build error:
>
> include/linux/list_nulls.h: In function ‘hlist_nulls_del’:
> include/linux/list_nulls.h:84:13: error: ‘LIST_POISON2’ undeclared (first use in this function)
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tipc: convert tipc reference table to use generic rhashtable
From: David Miller @ 2015-01-05 4:43 UTC (permalink / raw)
To: tgraf
Cc: ying.xue, netdev, jon.maloy, Paul.Gortmaker, erik.hugne,
tipc-discussion
In-Reply-To: <20150104095320.GB15305@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Sun, 4 Jan 2015 09:53:20 +0000
> As a further optimization, you could add a new atomic function
> rhashtable_lookup_and_insert() which holds the per bucket lock during
> lookup and use that instead. This would allow you to get rid of the
> mutex alltogether.
This would definitely be a better implementation in my opinion.
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] net: bcmgenet: bcmgenet_init_tx_ring() cleanup
From: David Miller @ 2015-01-05 4:46 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli
In-Reply-To: <20150104074523.5CA9C22034C@puck.mtv.corp.google.com>
From: Petri Gynther <pgynther@google.com>
Date: Sat, 3 Jan 2015 23:45:23 -0800 (PST)
> Signed-off-by: Petri Gynther <pgynther@google.com>
I'm not applying patches like this with not even a minor
explanation of what kind of cleanups are happening.
> - /* Disable rate control for now */
> bcmgenet_tdma_ring_writel(priv, index, flow_period_val,
> TDMA_FLOW_PERIOD);
And I think this comment, and the others you are removing are
absolutely appropriate and should not be removed.
Also, what value is there in renaming the function argument
'write_ptr' to 'start_ptr'? I think both names are equally
clear.
You have to provide explanations and justifications in the commit log
message of your changes.
I'm not applying this series, sorry.
^ permalink raw reply
* Re: [PATCH] Fix an infinite retry-loop
From: David Miller @ 2015-01-05 4:48 UTC (permalink / raw)
To: me; +Cc: linux-kernel, jitendra.kalsaria, ron.mercer, linux-driver, netdev
In-Reply-To: <1420394696-20099-1-git-send-email-me@mortis.eu>
From: Giel van Schijndel <me@mortis.eu>
Date: Sun, 4 Jan 2015 19:04:55 +0100
> This was clearly intended as a retry-10-times loop, but due to the
> absence of code incrementing the loop-counter it was practically a
> retry-forever loop.
>
> Rewritten it as a for-loop as well to make the loop-counter increment
> (as well as its potential absence) easier to spot.
Besides missing the Signoff, you also did not write your
Subject line properly.
You should format it as:
Subject: [PATCH] ${SUBSYSTEM_PREFIX}: Description.
Where ${SUBSYSTEM_PREFIX} should be "qlogic: " in this
case.
Do not fix this by replying to this email, instead make a new
fresh patch posting to the lists.
This also applied to all of your other submissions, they all
need to be fixed up in this manner at the very least.
^ permalink raw reply
* Re: [net-next PATCH v1 00/11] A flow API
From: John Fastabend @ 2015-01-05 5:17 UTC (permalink / raw)
To: Or Gerlitz
Cc: Thomas Graf, sfeldma, Jiří Pírko, Jamal Hadi Salim,
simon.horman, Linux Netdev List, David Miller, Andy Gospodarek
In-Reply-To: <CAJ3xEMikET4Yh88CYb1q5wsFQzakZsyqpPYxropQf2TwYdJg3w@mail.gmail.com>
On 01/04/2015 12:30 AM, Or Gerlitz wrote:
> On Wed, Dec 31, 2014 at 9:45 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> So... I could continue to mull over this and tweak bits and pieces
>> here and there but I decided its best to get a wider group of folks
>> looking at it and hopefulyl with any luck using it so here it is.
> [...]
>> I could use some help reviewing
> [...]
>
> Hi John,
>
> It would be very helpful to get access to the actual patches, I don't
> see them on the netdev patchwork queue, and assume
> it's b/c this is still in RFC stage. Cloning your github tree and
> looking there, I see some earlier/WIP versions of the code, but it's
> not
> the submitted patches.
>
The netdev mailed patches should be there (didn't check) I'm guessing
you just need to set the filters correctly. There is an "Action
Required" filter that you most likely need to remove I think it is on
by default. Seeing I already commented on the series indicating I would
need a v2 to address some fixes I'm guessing its already been cleared
from the queue.
> Or.
>
> [1] https://github.com/jrfastab/flow-net-next.git
>
That link is a bit out of date here I pushed the exact series I sent
to a git repo here,
https://github.com/jrfastab/rocker-net-next
All update it tomorrow with some feedback though.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v1 04/11] rocker: add pipeline model for rocker switch
From: John Fastabend @ 2015-01-05 5:18 UTC (permalink / raw)
To: Or Gerlitz
Cc: Thomas Graf, sfeldma, Jiří Pírko, Jamal Hadi Salim,
simon.horman, Linux Netdev List, David Miller, Andy Gospodarek
In-Reply-To: <CAJ3xEMitO-e4gRXAzp7F5F+1+Sq9+K8qQgTjEywA-FbX34bZ+g@mail.gmail.com>
On 01/04/2015 12:43 AM, Or Gerlitz wrote:
> On Wed, Dec 31, 2014 at 9:47 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> This adds rocker support for the net_flow_get_* operations. With this
>> we can interrogate rocker.
>>
>> Here we see that for static configurations enabling the get operations
>> is simply a matter of defining a pipeline model and returning the
>> structures for the core infrastructure to encapsulate into netlink
>> messages.
>
> [..]
>
[...]
>> +
>
> John,
>
> Repeating the feedback I provided you f2f in Dusseldorf when the WIP
> code was within ixgbe, some/many code pieces in this patch (e.g the
> above) are generic and hence should reside not within a low level
> driver such as rocker, and also on a separate patch.
>
> Or.
>
yep... will address in v2 thanks for the reminder, I expect I'll have
a v2 ready some time soon.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Fan Du @ 2015-01-05 6:02 UTC (permalink / raw)
To: Du, Fan, Thomas Graf, davem@davemloft.net, jesse@nicira.com
Cc: Michael S. Tsirkin, 'Jason Wang', netdev@vger.kernel.org,
fw@strlen.de, dev@openvswitch.org, pshelar@nicira.com
In-Reply-To: <5A90DA2E42F8AE43BC4A093BF0678848DEDFDB@SHSMSX104.ccr.corp.intel.com>
于 2014年12月03日 10:31, Du, Fan 写道:
>
>
>> -----Original Message-----
>> From: Thomas Graf [mailto:tgr@infradead.org] On Behalf Of Thomas Graf
>> Sent: Wednesday, December 3, 2014 1:42 AM
>> To: Michael S. Tsirkin
>> Cc: Du, Fan; 'Jason Wang'; netdev@vger.kernel.org; davem@davemloft.net;
>> fw@strlen.de; dev@openvswitch.org; jesse@nicira.com; pshelar@nicira.com
>> Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
>>
>> On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>>> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote:
>>>> On 12/02/14 at 01:48pm, Flavio Leitner wrote:
>>>>> What about containers or any other virtualization environment that
>>>>> doesn't use Virtio?
>>>>
>>>> The host can dictate the MTU in that case for both veth or OVS
>>>> internal which would be primary container plumbing techniques.
>>>
>>> It typically can't do this easily for VMs with emulated devices:
>>> real ethernet uses a fixed MTU.
>>>
>>> IMHO it's confusing to suggest MTU as a fix for this bug, it's an
>>> unrelated optimization.
>>> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here.
>>
>> PMTU discovery only resolves the issue if an actual IP stack is running inside the
>> VM. This may not be the case at all.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Some thoughts here:
>
> Think otherwise, this is indeed what host stack should forge a ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED
> message with _inner_ skb network and transport header, do whatever type of encapsulation,
> and thereafter push such packet upward to Guest/Container, which make them feel, the intermediate node
> or the peer send such message. PMTU should be expected to work correct.
> And such behavior should be shared by all other encapsulation tech if they are also suffered.
Hi David, Jesse and Thomas
As discussed in here: https://www.marc.info/?l=linux-netdev&m=141764712631150&w=4 and
quotes from Jesse:
My proposal would be something like this:
* For L2, reduce the VM MTU to the lowest common denominator on the segment.
* For L3, use path MTU discovery or fragment inner packet (i.e.
normal routing behavior).
* As a last resort (such as if using an old version of virtio in the
guest), fragment the tunnel packet.
For L2, it's a administrative action
For L3, PMTU approach looks better, because once the sender is alerted the reduced MTU,
packet size after encapsulation will not exceed physical MTU, so no additional fragments
efforts needed.
For "As a last resort... fragment the tunnel packet", the original patch:
https://www.marc.info/?l=linux-netdev&m=141715655024090&w=4 did the job, but seems it's
not welcomed.
Below raw patch adopts PMTU approach, please review! Any kind of comments/suggestions
is welcomed.
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e9f81d4..4d1b221 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1771,6 +1771,130 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
ttl = ttl ? : ip4_dst_hoplimit(&rt->dst);
+ if (skb_is_gso(skb)) {
+ unsigned int inner_l234_hdrlen;
+ unsigned int outer_l34_hdrlen;
+ unsigned int gso_seglen;
+ struct net_device *phy_dev = rt->dst.dev;
+
+ inner_l234_hdrlen = skb_transport_header(skb) - skb_mac_header(skb);
+ if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
+ inner_l234_hdrlen += tcp_hdrlen(skb);
+ if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ inner_l234_hdrlen += sizeof(struct udphdr);
+
+ outer_l34_hdrlen = sizeof(struct iphdr) + sizeof(struct udphdr) + sizeof(struct vxlanhdr);
+ /* gso_seglen is the GSO-ed skb packet len, adjust gso_size
+ * to fit into physical netdev MTU
+ */
+ gso_seglen = outer_l34_hdrlen + inner_l234_hdrlen + skb_shinfo(skb)->gso_size;
+ if (gso_seglen > phy_dev->mtu) {
+ struct sk_buff *reply;
+ struct ethhdr *orig_eth;
+ struct ethhdr *new_eth;
+ struct ethhdr *tnl_eth;
+ struct iphdr *orig_ip;
+ struct iphdr *new_ip;
+ struct iphdr *tnl_ip;
+ struct icmphdr *new_icmp;
+ unsigned int room;
+ unsigned int data_len;
+ unsigned int reply_l234_hdrlen;
+ unsigned int vxlan_tnl_hdrlen;
+ struct vxlanhdr *vxh;
+ struct udphdr *uh;
+ __wsum csum;
+
+ /* How much room to store orignal message */
+ room = (skb->len > 576) ? 576 : skb->len;
+ room -= sizeof(struct iphdr) + sizeof(struct icmphdr);
+
+ /* Ethernet payload len */
+ data_len = skb->len - skb_network_offset(skb);
+ if (data_len > room)
+ data_len = room;
+
+ reply_l234_hdrlen = LL_RESERVED_SPACE(phy_dev) + phy_dev->needed_tailroom +
+ sizeof(struct iphdr) + sizeof(struct icmphdr);
+ vxlan_tnl_hdrlen = LL_RESERVED_SPACE(phy_dev) + phy_dev->needed_tailroom +
+ sizeof(struct iphdr) + sizeof(struct udphdr) + sizeof(struct vxlanhdr);
+
+ reply = alloc_skb(vxlan_tnl_hdrlen + reply_l234_hdrlen + data_len, GFP_ATOMIC);
+ reply->dev = phy_dev;
+ skb_reserve(reply, vxlan_tnl_hdrlen + reply_l234_hdrlen);
+
+ new_icmp = (struct icmphdr *)__skb_push(reply, sizeof(struct icmphdr));
+ new_icmp->type = ICMP_DEST_UNREACH;
+ new_icmp->code = ICMP_FRAG_NEEDED;
+ new_icmp->un.frag.mtu = htons(phy_dev->mtu - outer_l34_hdrlen);
+ new_icmp->checksum = 0;
+
+ new_ip = (struct iphdr *)__skb_push(reply, sizeof(struct iphdr));
+ orig_ip = ip_hdr(skb);
+ new_ip->ihl = 5;
+ new_ip->version = 4;
+ new_ip->ttl = 32;
+ new_ip->tos = 1;
+ new_ip->protocol = IPPROTO_ICMP;
+ new_ip->saddr = orig_ip->daddr;
+ new_ip->daddr = orig_ip->saddr;
+ new_ip->frag_off = 0;
+ new_ip->tot_len = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + data_len);
+ ip_send_check(new_ip);
+
+ new_eth = (struct ethhdr *)__skb_push(reply, sizeof(struct ethhdr));
+ orig_eth = eth_hdr(skb);
+ ether_addr_copy(new_eth->h_dest, orig_eth->h_source);
+ ether_addr_copy(new_eth->h_source, orig_eth->h_dest);
+ new_eth->h_proto = htons(ETH_P_IP);
+ reply->ip_summed = CHECKSUM_UNNECESSARY;
+ reply->pkt_type = PACKET_HOST;
+ reply->protocol = htons(ETH_P_IP);
+ memcpy(skb_put(reply, data_len), skb_network_header(skb), data_len);
+ new_icmp->checksum = csum_fold(csum_partial(new_icmp, sizeof(struct icmphdr) + data_len, 0));
+
+ /* vxlan encapuslation */
+ vxh = (struct vxlanhdr *)__skb_push(reply, sizeof(*vxh));
+ vxh->vx_flags = htonl(VXLAN_FLAGS);
+ vxh->vx_vni = htonl(vni << 8);
+
+ __skb_push(reply, sizeof(*uh));
+ skb_reset_transport_header(reply);
+ uh = udp_hdr(reply);
+ uh->dest = dst_port;
+ uh->source = src_port;
+ uh->len = htons(reply->len);
+ uh->check = 0;
+ csum = skb_checksum(reply, 0, reply->len, 0);
+ uh->check = udp_v4_check(reply->len, fl4.saddr, dst->sin.sin_addr.s_addr, csum);
+
+ tnl_ip = (struct iphdr *)__skb_push(reply, sizeof(struct iphdr));
+ skb_reset_network_header(reply);
+ tnl_ip->ihl = 5;
+ tnl_ip->version = 4;
+ tnl_ip->ttl = 32;
+ tnl_ip->tos = 1;
+ tnl_ip->protocol = IPPROTO_UDP;
+ tnl_ip->saddr = dst->sin.sin_addr.s_addr;
+ tnl_ip->daddr = fl4.saddr;
+ tnl_ip->frag_off = 0;
+ tnl_ip->tot_len = htons(reply->len);
+ ip_send_check(tnl_ip);
+
+ /* fill with nosense mac header */
+ tnl_eth = (struct ethhdr *)__skb_push(reply, sizeof(struct ethhdr));
+ skb_reset_mac_header(reply);
+ orig_eth = eth_hdr(skb);
+ ether_addr_copy(tnl_eth->h_dest, orig_eth->h_source);
+ ether_addr_copy(tnl_eth->h_source, orig_eth->h_dest);
+ tnl_eth->h_proto = htons(ETH_P_IP);
+ __skb_pull(reply, skb_network_offset(reply));
+
+ /* push encapuslated ICMP message back to sender */
+ netif_rx_ni(reply);
+ }
+ }
err = vxlan_xmit_skb(vxlan->vn_sock, rt, skb,
fl4.saddr, dst->sin.sin_addr.s_addr,
tos, ttl, df, src_port, dst_port,
--
No zuo no die but I have to try.
^ permalink raw reply related
* Re: [PATCH] net: wireless: b43legacy: radio.c: Remove unused function
From: Rafał Miłecki @ 2015-01-05 6:34 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Sedat Dilek, Larry Finger, Stefano Brivio, Network Development,
linux-wireless@vger.kernel.org, Linux Kernel Mailing List,
b43-dev
In-Reply-To: <CAKXHbyMqTk=k7eieBNtAD+n6+4w3weL82twHBo-o8ebm_3+wvg@mail.gmail.com>
On 3 January 2015 at 13:28, Rickard Strandqvist
<rickard_strandqvist@spectrumdigital.se> wrote:
> 2015-01-02 22:34 GMT+01:00 Rafał Miłecki <zajec5@gmail.com>:
>>
>> 1) I gave you Ack for the changes
>> 2) You could drop "net: wireless: " or better use something Sedat proposed
>
> Nice, yes I miss the Ack :)
>
> I just got one more complaining about my subject-line in "net: wireless: "
> I use some sed call for this, so it's easy to fix. I will now remove that
> part hereinafter.
Will you re-send this patch with a proper subject then, please?
--
Rafał
^ permalink raw reply
* [PATCH/RFC rocker-net-next 0/6] net: flow: Minor fixes and cleanups
From: Simon Horman @ 2015-01-05 6:50 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, Simon Horman
Hi John,
This series contains several minor fixes and cleanups for your
consideration.
They apply on to of https://github.com/jrfastab/rocker-net-next
head commit 1b2a1e4 ("net: rocker: implement delete flow routine")
I have previously lightly exercised them on top of
https://github.com/jrfastab/flow-net-next
head commit 9f75688 ("net: flow: add new DYNAMIC flag")
Simon Horman (6):
net: flow: Cancel innermost nested attribute first
net: flow: Handle error when putting a field while putting a flow
net: flow: Remove unnecessary zero-header check when putting a flow
net: flow: free action args
net: flow: Return more fine-grained error when handing flows commands
net: flow: Limit checking of ndo_flow_{set,del}_flows
net/core/flow_table.c | 47 ++++++++++++++++++++++++++++++++++++-----------
1 file changed, 36 insertions(+), 11 deletions(-)
--
2.1.3
^ permalink raw reply
* [PATCH/RFC rocker-net-next 1/6] net: flow: Cancel innermost nested attribute first
From: Simon Horman @ 2015-01-05 6:50 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, Simon Horman
In-Reply-To: <1420440610-20621-1-git-send-email-simon.horman@netronome.com>
Cancel innermost nested attribute first on error when putting flow actions.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Its unclear to me if this makes any difference.
But it seems more logical to me.
---
net/core/flow_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/flow_table.c b/net/core/flow_table.c
index 542ebb5..2af831e 100644
--- a/net/core/flow_table.c
+++ b/net/core/flow_table.c
@@ -967,8 +967,8 @@ static int net_flow_put_flow_action(struct sk_buff *skb,
err = net_flow_put_act_types(skb, a[i].args);
if (err) {
- nla_nest_cancel(skb, action);
nla_nest_cancel(skb, sigs);
+ nla_nest_cancel(skb, action);
return err;
}
nla_nest_end(skb, sigs);
--
2.1.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox