* [PATCH net-next 0/2] net: dsa: bcm_sf2: GPHY power down
From: Florian Fainelli @ 2015-02-05 19:40 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hi David,
This patch series implement GPHY power up and down in the SF2 switch
driver in order to conserve power whenever possible (e.g: port is brought
down or unused during Wake-on-LAN).
Florian Fainelli (2):
net: dsa: bcm_sf2: move GPHY enabling to its own function
net: dsa: bcm_sf2: implement GPHY power down
drivers/net/dsa/bcm_sf2.c | 64 ++++++++++++++++++++++++++++++++++--------
drivers/net/dsa/bcm_sf2_regs.h | 4 +++
2 files changed, 56 insertions(+), 12 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: [ovs-dev] [RFC: add openvswitch actions using BPF 2/2] openvswitch: implements the BPF_PROG action in datapath
From: Andy Zhou @ 2015-02-05 19:34 UTC (permalink / raw)
To: Thomas Graf; +Cc: dev@openvswitch.com, netdev@vger.kernel.org
In-Reply-To: <20150205150733.GG5546@pox.localdomain>
On Thu, Feb 5, 2015 at 7:07 AM, Thomas Graf <tgraf@noironetworks.com> wrote:
> On 02/04/15 at 02:48pm, Andy Zhou wrote:
>> BPF_PROG action allows an action to be implemented in eBPF language and
>> downloaded by the userspace at runtime.
>>
>> Signed-off-by: Andy Zhou <azhou@nicira.com>
>
> Thanks a lot for putting this together Andy and Joe and everybody else
> who was involved. This is much further than what I expected as a first
> step.
>
> One slight open from my side is the avoidance of versioning help of
> helpers. We want to avoid v2, v3, ... helpers if the need should arise
> to extend an existing helper.
I share the concern. Addressing this upfront is a good idea. On the other hand
I am not sure if this is completely avoidable at a reasonable cost.
>
> I think it should be doable with BPF to have the verifier accept if
> a helper is called with less args than expected, to initialize those
> to 0. This would allow for helpers to support additional arguments.
I am not sure it is fundamentally better than V2, v3... On the other hand,
I agree this looks technically possible.
>
> I think this needs to be documented and expectations should be clear.
> Other than that I'm very very happy with where this is going.
Agreed,
> It seems very doable to also allow for a BPF prog to be registered
> upon flow table miss.
Yes, this is possible, but at the cost of flow set up rate. It may
still be practical
with some optimization, such as caching action lists so we don't
regenerate or download
the same program.
^ permalink raw reply
* Re: [ovs-dev] [RFC: add openvswitch actions using BPF 5/9] bpf: add the first BPF program.
From: Andy Zhou @ 2015-02-05 19:16 UTC (permalink / raw)
To: Thomas Graf; +Cc: dev@openvswitch.com, netdev@vger.kernel.org
In-Reply-To: <20150205141854.GD5546@pox.localdomain>
On Thu, Feb 5, 2015 at 6:18 AM, Thomas Graf <tgraf@noironetworks.com> wrote:
> First of all, I *love* this. I have some questions on versioning of
> helpers in the kernel. I will put comments in the respective kernel
> patches directly.
>
Thanks for the feedbacks.
> On 02/04/15 at 02:49pm, Andy Zhou wrote:
>> +EXTRA_DIST += $(srcdir)/bpf/ovs-bpf-helpers.h \
>> + $(srcdir)/bpf/bpf-shared.h \
>> + $(srcdir)/bpf/ovs-actions.c
>> +
>> +DEP_FILES = $(srcdir)/bpf/ovs-bpf-helpers.h \
>> + $(srcdir)/bpf/bpf-shared.h \
>> + $(srcdir)/datapath/linux/compat/include/linux/openvswitch.h
>
> Some tab / space mixing here.
Will fix.
>
>> +bpf/ovs-actions.bpf: $(srcdir)/bpf/ovs-actions.c $(DEP_FILES)
>> + $(AM_V_GEN)clang -DHAVE_CONFIG_H $(BPF_INCLUDES) $(NOSTDINC_FLAGS) \
>> + $(AM_CFLAGS) $(EXTRA_CFLAGS) -Wno-unused-value -Wno-pointer-sign \
>> + -O2 -emit-llvm -c $< -o -| $(LLC) -filetype=obj -o $@
>
> I assume you will convert this to a Makefile template
Yes. It needs to be addressed. Not sure if additional changes are
required now that
BPF backend is merged into LLVM upstream,
^ permalink raw reply
* Re: [PATCH net] ipv6: addrconf: add missing validate_link_af handler
From: Jiri Pirko @ 2015-02-05 19:11 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <0f0921b794041725c882546a614defde18fba7ea.1423143235.git.daniel@iogearbox.net>
Thu, Feb 05, 2015 at 02:39:11PM CET, daniel@iogearbox.net wrote:
>We still need a validate_link_af() handler with an appropriate nla policy,
>similarly as we have in IPv4 case, otherwise size validations are not being
>done properly in that case.
>
>Fixes: f53adae4eae5 ("net: ipv6: add tokenized interface identifier support")
>Fixes: bc91b0f07ada ("ipv6: addrconf: implement address generation modes")
>Cc: Jiri Pirko <jiri@resnulli.us>
>Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Thanks Daniel.
>---
> net/ipv6/addrconf.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
>diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>index f7c8bbe..dac9419 100644
>--- a/net/ipv6/addrconf.c
>+++ b/net/ipv6/addrconf.c
>@@ -4572,6 +4572,22 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token)
> return 0;
> }
>
>+static const struct nla_policy inet6_af_policy[IFLA_INET6_MAX + 1] = {
>+ [IFLA_INET6_ADDR_GEN_MODE] = { .type = NLA_U8 },
>+ [IFLA_INET6_TOKEN] = { .len = sizeof(struct in6_addr) },
>+};
>+
>+static int inet6_validate_link_af(const struct net_device *dev,
>+ const struct nlattr *nla)
>+{
>+ struct nlattr *tb[IFLA_INET6_MAX + 1];
>+
>+ if (dev && !__in6_dev_get(dev))
>+ return -EAFNOSUPPORT;
>+
>+ return nla_parse_nested(tb, IFLA_INET6_MAX, nla, inet6_af_policy);
>+}
>+
> static int inet6_set_link_af(struct net_device *dev, const struct nlattr *nla)
> {
> int err = -EINVAL;
>@@ -5393,6 +5409,7 @@ static struct rtnl_af_ops inet6_ops = {
> .family = AF_INET6,
> .fill_link_af = inet6_fill_link_af,
> .get_link_af_size = inet6_get_link_af_size,
>+ .validate_link_af = inet6_validate_link_af,
> .set_link_af = inet6_set_link_af,
> };
>
>--
>1.9.3
>
^ permalink raw reply
* Re: [RFC: add openvswitch actions using BPF 1/9] hack: Do not compile datapath
From: Andy Zhou @ 2015-02-05 19:11 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0SM8Zsap4Y0gw@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20150205134454.GA5546-4EA/1caXOu0mYvmMESoHnA@public.gmane.org>
Yes. That's the plan.
On Thu, Feb 5, 2015 at 5:44 AM, Thomas Graf <tgraf@noironetworks.com> wrote:
> On 02/04/15 at 02:49pm, Andy Zhou wrote:
>> The OVS eBPF patch sets are developed against master 'net-next' tree,
>> which is currently targeting for kernel version 3.19.
>>
>> The datapath in OVS mater does not currently support 3.19 kernel.
>> But we should not really using OVS datapath, The changes in the
>> follow patches are only changes in user space programs, which should
>> work with the kernel module built from the 'net-next' tree.
>>
>> This patch disables building of the datapath and disables the
>> configuration time kernel version check.
>>
>> Signed-off-by: Andy Zhou <azhou@nicira.com>
>
> You can drop this when the datapath sync series is fully merged.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH iproute2 4/4] iproute: Descriptions of fou and gue options in ip-link man pages
From: Stephen Hemminger @ 2015-02-05 18:56 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <1422550321-30901-5-git-send-email-therbert@google.com>
On Thu, 29 Jan 2015 08:52:01 -0800
Tom Herbert <therbert@google.com> wrote:
> Add section for additional arguments to GRE, IPIP, and SIT types
> that are related to Foo-over-UDP and Generic UDP Encapsulation.
> Also, added an example GUE configuration in the examples section.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied to master branch.
^ permalink raw reply
* Re: [PATCH iproute2 3/4] iproute: Description of new options for VXLAN in ip-link man pages
From: Stephen Hemminger @ 2015-02-05 18:55 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <1422550321-30901-4-git-send-email-therbert@google.com>
On Thu, 29 Jan 2015 08:52:00 -0800
Tom Herbert <therbert@google.com> wrote:
> Add description for UDP checksums and remote checksum offload.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Resubmit this when you fix up patch #2
^ permalink raw reply
* Re: [PATCH iproute2 2/4] vxlan: Add support for remote checksum offload
From: Stephen Hemminger @ 2015-02-05 18:54 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <1422550321-30901-3-git-send-email-therbert@google.com>
On Thu, 29 Jan 2015 08:51:59 -0800
Tom Herbert <therbert@google.com> wrote:
> This patch adds support to remote checksum checksum offload
> to VXLAN. This patch adds remcsumtx and remcsumrx to ip vxlan
> configuration to enable remote checksum offload for transmit
> and receive on the VXLAN tunnel.
>
> https://tools.ietf.org/html/draft-herbert-vxlan-rco-00
>
> Example:
>
> ip link add name vxlan0 type vxlan id 42 group 239.1.1.1 dev eth0 \
> udpcsum remcsumtx remcsumrx
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Does not apply to current iproute2 net-next branch because
the vxlan group policy extensions was applied first.
Please fix conflicts and resubmit.
^ permalink raw reply
* Re: [PATCH iproute2 1/4] ip link: Add support for remote checksum offload to IP tunnels
From: Stephen Hemminger @ 2015-02-05 18:51 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev
In-Reply-To: <1422550321-30901-2-git-send-email-therbert@google.com>
On Thu, 29 Jan 2015 08:51:58 -0800
Tom Herbert <therbert@google.com> wrote:
> This patch adds support to remote checksum checksum offload
> confinguration for IPIP, SIT, and GRE tunnels. This patch
> adds a [no]encap-remcsum to ip link command which applicable
> when configured tunnels that use GUE.
>
> http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
>
> Example:
>
> ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
> ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum \
> encap-remcsum
>
> This would create an GRE tunnel in GUE encapsulation where the source
> port is automatically selected (based on hash of inner packet),
> checksums in the encapsulating UDP header are enabled (needed.for
> remote checksum offload), and remote checksum ffload is configured to
> be used on the tunnel (affects TX side).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied to master since this does not depend on any net-next features.
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] iproute2: bridge vlan range support
From: Stephen Hemminger @ 2015-02-05 18:48 UTC (permalink / raw)
To: roopa; +Cc: netdev, shemminger, vyasevic, wkok, sfeldma
In-Reply-To: <1422239185-14054-1-git-send-email-roopa@cumulusnetworks.com>
On Sun, 25 Jan 2015 18:26:23 -0800
roopa@cumulusnetworks.com wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This series adds support for vlan ranges in iproute2 bridge add
> and show commands.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
>
> Roopa Prabhu (2):
> iproute2: bridge: support vlan range for adds
> iproute2: bridge vlan show new option to print ranges
>
> bridge/br_common.h | 1 +
> bridge/bridge.c | 6 ++++-
> bridge/vlan.c | 55 ++++++++++++++++++++++++++++++++++++++++-----
> include/linux/if_bridge.h | 2 ++
> include/linux/rtnetlink.h | 1 +
> 5 files changed, 58 insertions(+), 7 deletions(-)
>
Applied to net-next branch of iproute2
Go ahead and send more patches if you decide on different output format.
^ permalink raw reply
* Re: [PATCH iproute2] ss: group DCTCP socket statistics
From: Stephen Hemminger @ 2015-02-05 18:44 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev
In-Reply-To: <1422310659-9357-1-git-send-email-hagen@jauu.net>
On Mon, 26 Jan 2015 23:17:39 +0100
Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> Keep ss output consistent and format DCTCP socket statistics similar to skmen
> and timer where a group of logical values are grouped by brackets. This makes
> parser scripts *and* humans more happy.
>
>
> Current output of 'ss -inetm dst :80':
> ESTAB 0 0 192.168.11.14:55511 173.194.66.189:443
> timer:(keepalive,14sec,0) uid:1000 ino:428768
> sk:ffff88020ceb5b00 <-> skmem:(r0,rb372480,t0,tb87040,f0,w0,o0,bl0)
> ts sack wscale:7,7 rto:250 rtt:49.225/20.837 ato:40 mss:1408 cwnd:10
> ce_state 23 alpha 23 ab_ecn 23 ab_tot 23 send 2.3Mbps
> lastsnd:121026 lastrcv:121026 lastack:30850 pacing_rate 4.6Mbps
> retrans:0/2 rcv_rtt:40.416 rcv_space:2920
>
> New grouped output:
> ESTAB 0 0 192.168.11.14:55511 173.194.66.189:443
> timer:(keepalive,14sec,0) uid:1000 ino:428768
> sk:ffff88020ceb5b00 <-> skmem:(r0,rb372480,t0,tb87040,f0,w0,o0,bl0)
> ts sack wscale:7,7 rto:250 rtt:49.225/20.837 ato:40 mss:1408 cwnd:10
> dctcp(ce_state:23,alpha:23,ab_ecn:23,ab_tot:23) send 2.3Mbps
> lastsnd:121026 lastrcv:121026 lastack:30850 pacing_rate 4.6Mbps
> retrans:0/2 rcv_rtt:40.416 rcv_space:2920
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Acked-by: Daniel Borkmann <dborkman@redhat.com>
> Acked-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
> ---
> misc/ss.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
The patch looks fine, although changing output formats is normally not good
because someone might be scripting from this. But DCTCP is so new I am
willing to allow the change.
The problem is that the patch does not apply to either the master
(or net-next) branchs of upstream source.
Please fix that and resubmit.
^ permalink raw reply
* Re: [patch iproute2 repost 1/2] tc: push bpf common code into separate file
From: Stephen Hemminger @ 2015-02-05 18:39 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, jhs
In-Reply-To: <1421682990-11072-1-git-send-email-jiri@resnulli.us>
On Mon, 19 Jan 2015 16:56:29 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Both patches applied to net-next branch.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Initialize unmasked key and uid len
From: Eric Dumazet @ 2015-02-05 18:37 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev, ogerlitz, Joe Stringer
In-Reply-To: <1423158984-1674-1-git-send-email-pshelar@nicira.com>
On Thu, 2015-02-05 at 09:56 -0800, Pravin B Shelar wrote:
> Flow alloc needs to initialize unmasked key pointer. Otherwise
> it can crash kernel trying to free random unmasked-key pointer.
> CC: Joe Stringer <joestringer@nicira.com>
> Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> net/openvswitch/flow_table.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
> index 5e57628..d58447d 100644
> --- a/net/openvswitch/flow_table.c
> +++ b/net/openvswitch/flow_table.c
> @@ -85,6 +85,8 @@ struct sw_flow *ovs_flow_alloc(void)
>
> flow->sf_acts = NULL;
> flow->mask = NULL;
> + flow->id.unmasked_key = NULL;
> + flow->id.ufid_len = 0;
> flow->stats_last_writer = NUMA_NO_NODE;
At this stage, one has to wonder why not using kmem_cache_zalloc()
and reduce icache pressure right ?
And please please add :
Fixes: e64457191a259 ("openvswitch: Restructure datapath.c and flow.c")
or whatever commit was the bug origin.
Thanks
^ permalink raw reply
* Re: [PATCH 0/2 net-next] iproute2: VXLAN Group Policy extension
From: Stephen Hemminger @ 2015-02-05 18:32 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev
In-Reply-To: <cover.1421329802.git.tgraf@suug.ch>
On Thu, 15 Jan 2015 14:54:24 +0100
Thomas Graf <tgraf@suug.ch> wrote:
> Stephen,
>
> Against net-next branch. I assume you only want to apply patch 1/2 after
> the next header sync. I've included 2/2 if anyone wants to use it now and
> needs the header bits
>
> Thomas Graf (2):
> vxlan: Group policy extension
> vxlan: synchronize <linux/if_link.h> header
>
> include/linux/if_link.h | 3 +++
> ip/iplink_vxlan.c | 11 +++++++++++
> man/man8/ip-link.8.in | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 59 insertions(+)
>
I picked headers up in separate merge.
The iplink changes are waiting in net-next branch.
^ permalink raw reply
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: B Viswanath @ 2015-02-05 18:31 UTC (permalink / raw)
To: Scott Feldman
Cc: Siva Mannem, David Miller, Roopa Prabhu, Netdev,
Jiří Pírko
In-Reply-To: <CAE4R7bDRHwUnt7jzPw_CzwsZfou2B2mRgZ_9t4AfRWe2Z_EtYg@mail.gmail.com>
On 5 February 2015 at 23:25, Scott Feldman <sfeldma@gmail.com> wrote:
<snip>
>>>> I now see why rocker is broken. Sorry for the churn.
>>>> As Scott/Roopa suggested, a new flag IFLA_BRPORT_AGING_SYNC (similar
>>>> to IFLA_BRPORT_LEARNING_SYNC) can be defined and stored in
>>>> net_bridge_port->flags when user configures it. Some thing like below.
>>>>
>>>> $ sudo bridge link set dev swp1 ageing_sync on self
>>>>
>>>> And bridge ageing logic does not age externally learnt entry *only* if
>>>> IFLA_BRPORT_AGING_SYNC flag on fdb entry's net_bridge_port is set.
>>>> This ensures that existing behavior continues to be default behavior
>>>> and is of no harm to rocker.
>>>>
>>>> Please let me know your comments on above approach.
>>>
>>> I am not sure you really want to pass on this burden of deciding who
>>> should age to the end user. I think user should not be forced to be
>>> aware of all the device and driver properties.
>>>
>>> May be a different way would be that -
>>>
>>> 1. driver specifies whether it can supporting ageing by itself (the
>>> chip) during registration.
>>> 2. driver also allows that kernel turn off the driver/device ageing.
>>> 3. when a bridge is created with all ports from same device which
>>> supports ageing (and which is currently enabled), then bridge defers
>>> ageing to driver. Otherwise bridge disables ageing on all
>>> participating devices and takes care of ageing by itself.
>>> 4. When ageing is disabled on a device, all other bridges that use any
>>> ports from that device start ageing themselves.
>>>
>>> I guess this sounds complicated, but it can ensure that user gets the
>>> best default behaviour based on the device. Any alternate suggestions
>>> ?
>
> So let me see if I can summarize the PROs and CONs of using the
> default behavior of the bridge driver for ageing externally learned
> FDB entries:
>
> PROs
>
> 1) No new user knobs; just use existing bridge ageing settings for
> both internal and
> externally learned FDB entries.
> 2) Because we're using SW bridge, all offloaded switches behave the
> same w.r.t. ageing.
> 3) Because we're using SW bridge, bug fixes and enhancements apply to
> all offloaded switches.
> 4) Switch device model w.r.t. FDB ageing is simple to understand.
> 5) User's view of the ageing process is the same for internal and
> external learned FDB entries.
> The last-used stats make sense.
> 6) Leveraging what's already there...bridge ageing function is
> tried-and-true....let's reuse it if we can.
>
> CONs
>
> 1) Scale-ability. The bridge driver can't keep up with ageing many
> (10^5, for example) entries.
> 2) Scale-ability. Keeping the entries periodically refreshed requires
> a refresh sync from
> the device to the bridge driver, and the bridge driver/kernel can't keep up.
> 3) With the bridge driver, the ageing settings are per-bridge, not per-port.
>
> Did I miss any points?
There is one more
4. On links with wirespeed traffic, software ageing FDB entries
independently without having the knowledge of the traffic means that
CPU will ageout entries it should not. I don't know if this breaks
some RFC, but it can certainly cause big packet loss.
Such a packet loss is considered bad, and is a primary reason why
hardware supports ageing. Otherwise there is no reason hw needs to
support it. Based on experience, I can say that it is a necessity, now
even more with 10G and 40G links.
>
> I think it boils down to use-ability vs. scale-ability. My personal
> opinion is I'm skeptical there are real scale-ability issues because
> the on-board switch CPU should easily be able to handle the ageing
> tasks. After all, the CPU will for the most part be idle, only
> worrying about the occasional ctrl pkt (STP, LLDP, OSPF, etc). I'm
> most interested in keeping the user's experience simple, so if we can
> extend the existing bridge ageing model to offloaded devices without
> changing the users' experience compared to the non-offloaded case.
I agree with no changes in user experience. I think my design change
suggestion can make sure that no user experience changes for all
regular use cases, and certainly no changes for non-switch-devices.
Thanks
Vissu
>
> So let's draw out the CONs for using the bridge driver's ageing function as-is.
>
> -scott
^ permalink raw reply
* Re: [PATCH iproute2 v2 0/3] ip netns: Run over all netns
From: Stephen Hemminger @ 2015-02-05 18:29 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1421590219-19365-1-git-send-email-vadim4j@gmail.com>
On Sun, 18 Jan 2015 16:10:16 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> From: Vadim Kochan <vadim4j@gmail.com>
>
> Allow 'ip netns del' and 'ip netns exec' run over each network namespace names.
>
> 'ip netns exec' executes command forcely on eacn nsname.
>
> Added new '-all' 'ip' option to run over each netns,
> it can be used for other utils as generic option.
>
> v2:
> Use '-all' option instead of netns name 'all'.
>
> Vadim Kochan (3):
> lib: Exec func on each netns
> ip netns: Allow exec on each netns
> ip netns: Delete all netns
>
> include/namespace.h | 6 ++++
> include/utils.h | 5 +++
> ip/ip.c | 5 ++-
> ip/ipnetns.c | 98 ++++++++++++++++++++++++++++++++---------------------
> lib/namespace.c | 22 ++++++++++++
> lib/utils.c | 28 +++++++++++++++
> man/man8/ip-netns.8 | 28 ++++++++++++---
> man/man8/ip.8 | 7 +++-
> 8 files changed, 153 insertions(+), 46 deletions(-)
>
Accepted
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 1/4] include: update headers
From: Stephen Hemminger @ 2015-02-05 18:26 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: shemminger, netdev
In-Reply-To: <1422454550-32222-1-git-send-email-nicolas.dichtel@6wind.com>
On Wed, 28 Jan 2015 15:15:47 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Copy from sanitized headers.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
>
> v2: took last headers from net-next
>
> include/linux/if_link.h | 4 ++++
> include/linux/neighbour.h | 1 +
> include/linux/net_namespace.h | 23 +++++++++++++++++++++++
> include/linux/rtnetlink.h | 5 +++++
> 4 files changed, 33 insertions(+)
> create mode 100644 include/linux/net_namespace.h
All kernel headers for iproute2 must come from the result of:
$ make headers_install
Please submit a patch to net-next which makes net_namespace.h
(from include/uapi/linux/net_namespace.h) get correctly installed into
usr/include/linux/net_namespace.h
The file is missing from include/uapi/linux/Kbuild
^ permalink raw reply
* Re: [ovs-dev] [PATCH] net: openvswitch: Support masked set actions.
From: Jarno Rajahalme @ 2015-02-05 18:20 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev, dev@openvswitch.org
In-Reply-To: <CAEP_g=8vm3+028GVdh-4DidOzpgfNiNQB7T1OqJ-_jOdPNU5Dw@mail.gmail.com>
Sorry for not remembering about these…
On Dec 10, 2014, at 6:03 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Tue, Dec 9, 2014 at 4:10 PM, Jarno Rajahalme <jrajahalme@nicira.com> wrote:
>> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
>> index df3c7f2..276bb60 100644
>> --- a/net/openvswitch/flow_netlink.c
>> +++ b/net/openvswitch/flow_netlink.c
>> @@ -2007,6 +2117,18 @@ int ovs_nla_put_actions(const struct nlattr *attr, int len, struct sk_buff *skb)
>> return err;
>> break;
>>
>> + case OVS_ACTION_ATTR_SET_MASKED:
>> + err = masked_set_action_to_attr(a, skb);
>> + if (err)
>> + return err;
>> + break;
>
> I don't think this is necessary - the default case will handle things
> that don't need any special processing.
>
Right, the masked_set_action_to_attr() function is actually the same as the default processing, so it can be removed. Thanks for pointing this out!
> I think you can also remove the port checks in validate_tp_port()
> since the reasoning behind them is the same as the IP proto check.
>
The reasoning for removing the the IP proto check was that it may be wildcarded, and that we are checking for the presence of the IP header anyway when executing the check.
Same applies to the ports, in principle the flow could wildcard them and a set action could set one or both of them regardless (even though the current OVS userspace still exact matches all the fields it sets, but this may change in the future).
For transport protocol we validate the flow for the right IP proto field value, and in execution we use sib_make_writeable() to make sure the packet actually has the space for the header, so we can safely drop the flow key transport port checks from validate_tp_port(). All that remains there are the ethertype checks, which we need to keep as the ip.proto field is also used for the ARP opcode, which could collide with a valid IPPROTO_ value. However, it seems strange to have a function named validate_tp_ports() to only check that the ethertype is either IPv4 or IPv6, so I will inline the checks to validate_set().
> Otherwise, I'm generally happy with this though.
I’ll send a v3 later today.
Thanks,
Jarno
^ permalink raw reply
* Re: [PATCH iproute2] iproute2: ip-link.8.in: Spelling fixes
From: Stephen Hemminger @ 2015-02-05 18:10 UTC (permalink / raw)
To: Reese Moore; +Cc: netdev@vger.kernel.org, Stephen Hemminger, Dmitry Kozlov
In-Reply-To: <38b8ee6572c14c858a43065286346b5e@BRMWP-EXMB11.corp.brocade.com>
On Wed, 4 Feb 2015 19:04:48 +0000
Reese Moore <ram@vt.edu> wrote:
> In the ip-link(8) man page, for the gretap, ip6gre, and ip6gretap types, the
> word tunnel was incorrectly spelled 'tuunel'.
>
> Signed-off-by: Reese Moore <ram@vt.edu>
Applied thanks.
^ permalink raw reply
* Re: [Patch iproute2] skbedit: print action too
From: Stephen Hemminger @ 2015-02-05 18:09 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <1422485562-15572-1-git-send-email-xiyou.wangcong@gmail.com>
On Wed, 28 Jan 2015 14:52:42 -0800
Cong Wang <xiyou.wangcong@gmail.com> wrote:
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> tc/m_skbedit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tc/m_skbedit.c b/tc/m_skbedit.c
> index 36323a9..c5deee0 100644
> --- a/tc/m_skbedit.c
> +++ b/tc/m_skbedit.c
> @@ -193,7 +193,7 @@ static int print_skbedit(struct action_util *au, FILE *f, struct rtattr *arg)
> fprintf(f, " mark %d", *mark);
> }
>
> - fprintf(f, "\n\t index %d ref %d bind %d", p->index, p->refcnt, p->bindcnt);
> + fprintf(f, " %s\n\t index %d ref %d bind %d", action_n2a(p->action, b1, sizeof (b1)), p->index, p->refcnt, p->bindcnt);
>
> if (show_stats) {
> if (tb[TCA_SKBEDIT_TM]) {
It is good to show everything that is set.
The output of tc show commands should match the arguments used
to create. In this case you are printing does not match the input.
Also, I would rather see this in a separate fprintf rather than
overloading existing call.
Please cleanup and resubmit.
^ permalink raw reply
* Re: crash when setting ovs instance over net-next
From: Pravin Shelar @ 2015-02-05 17:57 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Jesse Gross, netdev@vger.kernel.org
In-Reply-To: <54D31C9D.9040607@mellanox.com>
On Wed, Feb 4, 2015 at 11:32 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> With latest net-next (commit 06eb395 "pkt_sched: fq: better control of DDOS
> traffic")
> under the below config [2], I see this crash [1], will send you also my
> .config
>
> The user-space bits are openvswitch-2.0.90-1 rpm built from the git.
>
> Or.
>
Thanks for the report. I sent out fix "openvswitch: Initialize
unmasked key and uid len"
^ permalink raw reply
* [PATCH net-next] openvswitch: Initialize unmasked key and uid len
From: Pravin B Shelar @ 2015-02-05 17:56 UTC (permalink / raw)
To: netdev; +Cc: ogerlitz, Pravin B Shelar, Joe Stringer
Flow alloc needs to initialize unmasked key pointer. Otherwise
it can crash kernel trying to free random unmasked-key pointer.
general protection fault: 0000 [#1] SMP
3.19.0-rc6-net-next+ #457
Hardware name: Supermicro X7DWU/X7DWU, BIOS 1.1 04/30/2008
RIP: 0010:[<ffffffff8111df0e>] [<ffffffff8111df0e>] kfree+0xac/0x196
Call Trace:
[<ffffffffa060bd87>] flow_free+0x21/0x59 [openvswitch]
[<ffffffffa060bde0>] ovs_flow_free+0x21/0x23 [openvswitch]
[<ffffffffa0605b4a>] ovs_packet_cmd_execute+0x2f3/0x35f [openvswitch]
[<ffffffffa0605995>] ? ovs_packet_cmd_execute+0x13e/0x35f [openvswitch]
[<ffffffff811fe6fb>] ? nla_parse+0x4f/0xec
[<ffffffff8139a2fc>] genl_family_rcv_msg+0x26d/0x2c9
[<ffffffff8107620f>] ? __lock_acquire+0x90e/0x9aa
[<ffffffff8139a3be>] genl_rcv_msg+0x66/0x89
[<ffffffff8139a358>] ? genl_family_rcv_msg+0x2c9/0x2c9
[<ffffffff81399591>] netlink_rcv_skb+0x3e/0x95
[<ffffffff81399898>] ? genl_rcv+0x18/0x37
[<ffffffff813998a7>] genl_rcv+0x27/0x37
[<ffffffff81399033>] netlink_unicast+0x103/0x191
[<ffffffff81399382>] netlink_sendmsg+0x2c1/0x310
[<ffffffff811007ad>] ? might_fault+0x50/0xa0
[<ffffffff8135c773>] do_sock_sendmsg+0x5f/0x7a
[<ffffffff8135c799>] sock_sendmsg+0xb/0xd
[<ffffffff8135cacf>] ___sys_sendmsg+0x1a3/0x218
[<ffffffff8113e54b>] ? get_close_on_exec+0x86/0x86
[<ffffffff8115a9d0>] ? fsnotify+0x32c/0x348
[<ffffffff8115a720>] ? fsnotify+0x7c/0x348
[<ffffffff8113e5f5>] ? __fget+0xaa/0xbf
[<ffffffff8113e54b>] ? get_close_on_exec+0x86/0x86
[<ffffffff8135cccd>] __sys_sendmsg+0x3d/0x5e
[<ffffffff8135cd02>] SyS_sendmsg+0x14/0x16
[<ffffffff81411852>] system_call_fastpath+0x12/0x17
CC: Joe Stringer <joestringer@nicira.com>
Reported-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/openvswitch/flow_table.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 5e57628..d58447d 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -85,6 +85,8 @@ struct sw_flow *ovs_flow_alloc(void)
flow->sf_acts = NULL;
flow->mask = NULL;
+ flow->id.unmasked_key = NULL;
+ flow->id.ufid_len = 0;
flow->stats_last_writer = NUMA_NO_NODE;
/* Initialize the default stat node. */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Scott Feldman @ 2015-02-05 17:55 UTC (permalink / raw)
To: B Viswanath
Cc: Siva Mannem, David Miller, Roopa Prabhu, Netdev,
Jiří Pírko
In-Reply-To: <CAE4R7bBKXHfbOz-BT1jW2=+hTi=6hZZHRUVpYUvOj1yF+XEtUw@mail.gmail.com>
On Thu, Feb 5, 2015 at 9:10 AM, Scott Feldman <sfeldma@gmail.com> wrote:
> On Thu, Feb 5, 2015 at 3:05 AM, B Viswanath <marichika4@gmail.com> wrote:
>> On 5 February 2015 at 15:56, Siva Mannem <siva.mannem.lnx@gmail.com> wrote:
>>> On Thu, Feb 5, 2015 at 1:23 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: Scott Feldman <sfeldma@gmail.com>
>>>> Date: Wed, 4 Feb 2015 23:13:07 -0800
>>>>
>>>>> I'd like to see this patch reverted so we can have a more
>>>>> comprehensive discussion/solution. With this patch applied, the only
>>>>> user (rocker) of NETDEV_SWITCH_FDB_ADD is broken. So please undo this
>>>>> patch so rocker isn't broken and let's work on a knob to suit both
>>>>> modes: 1) let bridge manage aging, 2) let device manage aging.
>>>>
>>>> Patch reverted.
Thank you.
>>> I now see why rocker is broken. Sorry for the churn.
>>> As Scott/Roopa suggested, a new flag IFLA_BRPORT_AGING_SYNC (similar
>>> to IFLA_BRPORT_LEARNING_SYNC) can be defined and stored in
>>> net_bridge_port->flags when user configures it. Some thing like below.
>>>
>>> $ sudo bridge link set dev swp1 ageing_sync on self
>>>
>>> And bridge ageing logic does not age externally learnt entry *only* if
>>> IFLA_BRPORT_AGING_SYNC flag on fdb entry's net_bridge_port is set.
>>> This ensures that existing behavior continues to be default behavior
>>> and is of no harm to rocker.
>>>
>>> Please let me know your comments on above approach.
>>
>> I am not sure you really want to pass on this burden of deciding who
>> should age to the end user. I think user should not be forced to be
>> aware of all the device and driver properties.
>>
>> May be a different way would be that -
>>
>> 1. driver specifies whether it can supporting ageing by itself (the
>> chip) during registration.
>> 2. driver also allows that kernel turn off the driver/device ageing.
>> 3. when a bridge is created with all ports from same device which
>> supports ageing (and which is currently enabled), then bridge defers
>> ageing to driver. Otherwise bridge disables ageing on all
>> participating devices and takes care of ageing by itself.
>> 4. When ageing is disabled on a device, all other bridges that use any
>> ports from that device start ageing themselves.
>>
>> I guess this sounds complicated, but it can ensure that user gets the
>> best default behaviour based on the device. Any alternate suggestions
>> ?
So let me see if I can summarize the PROs and CONs of using the
default behavior of the bridge driver for ageing externally learned
FDB entries:
PROs
1) No new user knobs; just use existing bridge ageing settings for
both internal and
externally learned FDB entries.
2) Because we're using SW bridge, all offloaded switches behave the
same w.r.t. ageing.
3) Because we're using SW bridge, bug fixes and enhancements apply to
all offloaded switches.
4) Switch device model w.r.t. FDB ageing is simple to understand.
5) User's view of the ageing process is the same for internal and
external learned FDB entries.
The last-used stats make sense.
6) Leveraging what's already there...bridge ageing function is
tried-and-true....let's reuse it if we can.
CONs
1) Scale-ability. The bridge driver can't keep up with ageing many
(10^5, for example) entries.
2) Scale-ability. Keeping the entries periodically refreshed requires
a refresh sync from
the device to the bridge driver, and the bridge driver/kernel can't keep up.
3) With the bridge driver, the ageing settings are per-bridge, not per-port.
Did I miss any points?
I think it boils down to use-ability vs. scale-ability. My personal
opinion is I'm skeptical there are real scale-ability issues because
the on-board switch CPU should easily be able to handle the ageing
tasks. After all, the CPU will for the most part be idle, only
worrying about the occasional ctrl pkt (STP, LLDP, OSPF, etc). I'm
most interested in keeping the user's experience simple, so if we can
extend the existing bridge ageing model to offloaded devices without
changing the users' experience compared to the non-offloaded case.
So let's draw out the CONs for using the bridge driver's ageing function as-is.
-scott
^ permalink raw reply
* Re: [PATCH net] rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY
From: Thomas Graf @ 2015-02-05 17:52 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Mitch Williams, Jeff Kirsher
In-Reply-To: <ceaf2a9c514600d14c9f6a89a8c38e553a85e9fe.1423158127.git.daniel@iogearbox.net>
On 02/05/15 at 06:44pm, Daniel Borkmann wrote:
> ifla_vf_policy[] is wrong in advertising its individual member types as
> NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
> len member as *max* attribute length [0, len].
>
> The issue is that when do_setvfinfo() is being called to set up a VF
> through ndo handler, we could set corrupted data if the attribute length
> is less than the size of the related structure itself.
>
> The intent is exactly the opposite, namely to make sure to pass at least
> data of minimum size of len.
>
> Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
> Cc: Mitch Williams <mitch.a.williams@intel.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [PATCH v2] socket.7: add description for SO_BUSY_POLL
From: Eliezer Tamir @ 2015-02-05 17:48 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man, David Miller, lkml, netdev, Andrew Morton,
Eliezer Tamir
In-Reply-To: <CAKgNAki16GXAs5J5cXPzftxxrvaugOvQSamVsGe4jFQF9V=fAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/02/2015 15:17, Michael Kerrisk (man-pages) wrote:
> On 20 January 2014 at 18:28, Eliezer Tamir
> <eliezer.tamir-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>> On 20/01/2014 18:28, Michael Kerrisk (man-pages) wrote:
>>> On 07/10/2013 04:18 PM, Eliezer Tamir wrote:
>>>> Add description for the SO_BUSY_POLL socket option to the socket(7) manpage.
>>>
>>> Long after the fact, I've applied this. Thanks, Eliezer.
>>>
>>> Would you be willing also to write a patch for the POLL_BUSY_LOOP flag of
>>> poll()?
>>
>> Yes, Me or someone from our team will do that.
>
> Hi Eliezer,
>
> Could you or someone from your team send me a POLL_BUSY_LOOP doc patch?
Hi Michael,
Right now POLL_BUSY_LOOP is only used internally to control busylooping,
as a signal between sock_poll() and do_poll().
Our original intention was to expose that to the users of epoll().
The work on epoll() support is not finished yet.
I think we should not document this until we finalize epoll() support.
Thanks,
Eliezer
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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