* Re: iproute2 tc: Print qdisc, stats, class, filter info to string rather than FILE
From: Florian Westphal @ 2015-01-07 22:13 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <20150107215331.GA19197@angus-think.lan>
Vadim Kochan <vadim4j@gmail.com> wrote:
> I'd like to make possible to generate plot info about class hierarchy
> with qdisc, filters, stats info, but I see that all this staffs are
> printed to 'FILE *fp' which makes this hard to implement and seems to me
> that it should be changed to be printed to 'char *s' (memory safety
> should be considered by asprintf or similar), so this is a big change
> but all this is possible and I ready to do it, but before do it I'd like
> to ask if this could be acceptable as idea.
>
> BUT maybe someone can advise me easier solution ?
Would fmemopen/open_memstream(3) do what you want?
^ permalink raw reply
* Re: [PATCH 2/2] Fix copy-paste bug: assign from src struct not dest
From: Johannes Berg @ 2015-01-07 22:16 UTC (permalink / raw)
To: Giel van Schijndel
Cc: Andy Shevchenko, linux-kernel, Kalle Valo, Eliad Peller,
John W. Linville, Arik Nemtsov, open list:TI WILINK WIRELES...,
open list:NETWORKING DRIVERS
In-Reply-To: <20150107191836.GA18978@salidar.dom.custoft.eu>
On Wed, 2015-01-07 at 20:18 +0100, Giel van Schijndel wrote:
> IMO the aligned block of code has the significant advantage of taking
> advantage of humans' ability to spot things that break a pattern. Which
> in this case becomes *very* visible when properly aligned, because
> without the alignment there is no (visual) pattern (or at least not one
> very suitable for my "visual processing system", I know the same applies
> to at least some others).
Yeah, well, but why even invoke that "visual processing system"?
If you look, for example, at the __skb_clone function it just uses a
macro:
#define C(x) n->x = skb->x
and then
C(len);
C(data_len);
etc.
johannes
^ permalink raw reply
* Re: iproute2 tc: Print qdisc, stats, class, filter info to string rather than FILE
From: Vadim Kochan @ 2015-01-07 22:12 UTC (permalink / raw)
To: Florian Westphal; +Cc: Vadim Kochan, netdev
In-Reply-To: <20150107221309.GG11324@breakpoint.cc>
On Wed, Jan 07, 2015 at 11:13:09PM +0100, Florian Westphal wrote:
> Vadim Kochan <vadim4j@gmail.com> wrote:
> > I'd like to make possible to generate plot info about class hierarchy
> > with qdisc, filters, stats info, but I see that all this staffs are
> > printed to 'FILE *fp' which makes this hard to implement and seems to me
> > that it should be changed to be printed to 'char *s' (memory safety
> > should be considered by asprintf or similar), so this is a big change
> > but all this is possible and I ready to do it, but before do it I'd like
> > to ask if this could be acceptable as idea.
> >
> > BUT maybe someone can advise me easier solution ?
>
> Would fmemopen/open_memstream(3) do what you want?
I briefly looked on it, and it might help, THANKS A LOT!
^ permalink raw reply
* Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
From: Jesse Gross @ 2015-01-07 22:45 UTC (permalink / raw)
To: Thomas Graf
Cc: Tom Herbert, David Miller, Stephen Hemminger, Pravin B Shelar,
Linux Netdev List, dev@openvswitch.org
In-Reply-To: <20150107102740.GM21820@casper.infradead.org>
On Wed, Jan 7, 2015 at 2:27 AM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/06/15 at 07:46pm, Tom Herbert wrote:
>> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
>> > The VXLAN receive code is currently conservative in what it accepts and
>> > will reject any frame that uses any of the reserved VXLAN protocol fields.
>> > The VXLAN draft specifies that "reserved fields MUST be set to zero on
>> > transmit and ignored on receive.".
>> >
>> IMO it is an unfortunate decision in VXLAN to ignore set reserved
>> fields on receive. Had they not done this, then adding a protocol
>> field to the header would have been feasible and we wouldn't need yet
>> another encapsulation protocol (i.e. VXLAN-GPE). Rejecting frames with
>> reserved bits set is the better behavior, but I think the comment
>> about this needs to be clear about why this diverges from RFC7348.
>
> Agreed. Do you want to give it a shot? I know you have been involved
> on all aspects of this topic for a long time in NVO3 ;-)
There is little chance of this happening. Besides the IETF procedural
aspects, ignoring unknown reserved bits on receive is the long
standing standard way of extending protocols. It's how TCP was
extended to support ECN, for example.
>> > Retain the current conservative parsing behaviour by default but allows
>> > these fields to be used by VXLAN extensions which are explicitly enabled
>> > on the VXLAN socket respectively VXLAN net_device.
>> >
>> Conceptually, VXLAN has both mandatory flags and optional flags for
>> extensions. You may want to look at the VXLAN RCO patches that added
>> an extension and infrastructure for them.
>
> I've seen your proposed changes. I think they could be easily rebased
> on top of this and use the enablement infrastructure. In fact, I see
> this as the only feasible option to deal with VXLAN extensions: Leave
> it to the user to decide which extensions to run. That way we can
> support any combination of extensions, even conflicting ones. All we
> have to do is catch incompatible extension configurations on a socket
> and reject them at configuration time. Expecting that NVO3/IETF will
> find consensus on a list of compatible set of extensions with perfect
> forward and backwards compatibility is unrealistic in my eyes. We have
> Geneve and GUE to solve it properly in the future.
My concern is that having multiple (and potentially overlapping)
extensions is going to make the VXLAN code very messy and hard to
follow. I think there's already quite a big of complexity there from
the DOVE extensions (which are basically dead at this point to the
best of my knowledge). We already see this some with the discussion
over the header struct but that's just the beginning - can you imagine
the code that checks a single bit for several different
interpretations? Not to mention the fact that the location of the bits
in some of these proposals has already been shuffled several times. It
seems very painful...
^ permalink raw reply
* Re: [PATCH 3/6] vxlan: Only bind to sockets with correct extensions enabled
From: Jesse Gross @ 2015-01-07 22:45 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, Stephen Hemminger, Pravin Shelar, netdev,
dev@openvswitch.org
In-Reply-To: <46b4ceefbd8513250f64ba9c7297a8d2743f3108.1420594925.git.tgraf@suug.ch>
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> A VXLAN net_device looking for an appropriate socket may only
> consider a socket which has the exact set of extensions enabled.
> If none can be found, a new socket must be created.
Maybe it's just the phrasing of the commit message but won't the new
socket that needs to be created immediately fail? I think this is
really just checking that you don't try to instantiate two different
sets of extensions on the same UDP port - it's not like this is going
to somehow create a new socket and they will be able to coexist.
^ permalink raw reply
* Re: [PATCH 5/6] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
From: Jesse Gross @ 2015-01-07 22:46 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, Stephen Hemminger, Pravin Shelar, netdev,
dev@openvswitch.org
In-Reply-To: <10cbd42aca443d862b8b62017b5a4356326e026f.1420594925.git.tgraf@suug.ch>
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> A subsequent patch will introduce VXLAN options. Rename the existing
> GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic
> tunnel metadata options.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
This is generally a good idea (even outside of the larger context of
this patch series) although a couple comments below:
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index d1eecf7..c60ae3f 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -387,20 +387,20 @@ static int parse_flow_nlattrs(const struct nlattr *attr,
> return __parse_flow_nlattrs(attr, a, attrsp, log, false);
> }
>
> -static int genev_tun_opt_from_nlattr(const struct nlattr *a,
> - struct sw_flow_match *match, bool is_mask,
> - bool log)
> +static int tun_md_opt_from_nlattr(const struct nlattr *a,
> + struct sw_flow_match *match, bool is_mask,
> + bool log)
I think this is a somewhat overzealous conversion. This function is
verifying OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS and as such has some
elements of Geneve protocol knowledge baked in (such as the check that
the options are a multiple of 4 bytes). It's also nice for the log
messages to indicate which netlink key is causing the problem and not
be too generic.
> @@ -1148,10 +1145,10 @@ int ovs_nla_put_flow(const struct sw_flow_key *swkey,
> goto nla_put_failure;
>
> if ((swkey->tun_key.ipv4_dst || is_mask)) {
> - const struct geneve_opt *opts = NULL;
> + const void *opts = NULL;
>
> if (output->tun_key.tun_flags & TUNNEL_OPTIONS_PRESENT)
> - opts = GENEVE_OPTS(output, swkey->tun_opts_len);
> + opts = TUN_METADATA_OPTS(output, swkey->tun_opts_len);
>
> if (ipv4_tun_to_nlattr(skb, &output->tun_key, opts,
> swkey->tun_opts_len))
I think it's probably better to factor this block of code out into a
new function as you have done in the next patch (and include it with
this one). It makes it clearer that it is Geneve-specific.
^ permalink raw reply
* Re: [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension
From: Jesse Gross @ 2015-01-07 22:46 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, Stephen Hemminger, Pravin Shelar, netdev,
dev@openvswitch.org
In-Reply-To: <9c1b0b0acde09019acb61b9b1a4eb4b18c62642a.1420594925.git.tgraf@suug.ch>
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> The group policy metadata is handled in the same way as Geneve options
> and transported as binary blob in a new Netlink attribute
> OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS which is mutually exclusive to the
> existing OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS.
Can you explain some more what the encoding would look like if
additional options were defined (including ones that are potentially
mutually exclusive)? The Geneve options are binary but that is coming
directly from the protocol specification. However, this isn't an on
the wire format so I'm not sure what it would look like or how it
would be defined to avoid conflict and allow evolution.
^ permalink raw reply
* Re: [PATCH 3/6] vxlan: Only bind to sockets with correct extensions enabled
From: Thomas Graf @ 2015-01-07 22:52 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, Stephen Hemminger, Pravin Shelar, netdev,
dev@openvswitch.org
In-Reply-To: <CAEP_g=8_BFYO67Qj+TQUprqomBrwPLSGJvA3+F=9E3bgKhcrEA@mail.gmail.com>
On 01/07/15 at 02:45pm, Jesse Gross wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> > A VXLAN net_device looking for an appropriate socket may only
> > consider a socket which has the exact set of extensions enabled.
> > If none can be found, a new socket must be created.
>
> Maybe it's just the phrasing of the commit message but won't the new
> socket that needs to be created immediately fail? I think this is
> really just checking that you don't try to instantiate two different
> sets of extensions on the same UDP port - it's not like this is going
> to somehow create a new socket and they will be able to coexist.
Your interpretation is correct and the phrasing is poor. It prevents
a non-GBP socket from being used for a GBP socket. I will rework the
commit message.
^ permalink raw reply
* Re: [PATCH 5/6] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
From: Thomas Graf @ 2015-01-07 22:55 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, Stephen Hemminger, Pravin Shelar, netdev,
dev@openvswitch.org
In-Reply-To: <CAEP_g=-X_S1qmMQt3VjOUT9+qUEnxeJxUSf-B90Yktns72zWaA@mail.gmail.com>
On 01/07/15 at 02:46pm, Jesse Gross wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> > A subsequent patch will introduce VXLAN options. Rename the existing
> > GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic
> > tunnel metadata options.
> >
> > Signed-off-by: Thomas Graf <tgraf@suug.ch>
>
> This is generally a good idea (even outside of the larger context of
> this patch series) although a couple comments below:
>
> > diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> > index d1eecf7..c60ae3f 100644
> > --- a/net/openvswitch/flow_netlink.c
> > +++ b/net/openvswitch/flow_netlink.c
> > @@ -387,20 +387,20 @@ static int parse_flow_nlattrs(const struct nlattr *attr,
> > return __parse_flow_nlattrs(attr, a, attrsp, log, false);
> > }
> >
> > -static int genev_tun_opt_from_nlattr(const struct nlattr *a,
> > - struct sw_flow_match *match, bool is_mask,
> > - bool log)
> > +static int tun_md_opt_from_nlattr(const struct nlattr *a,
> > + struct sw_flow_match *match, bool is_mask,
> > + bool log)
>
> I think this is a somewhat overzealous conversion. This function is
> verifying OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS and as such has some
> elements of Geneve protocol knowledge baked in (such as the check that
> the options are a multiple of 4 bytes). It's also nice for the log
> messages to indicate which netlink key is causing the problem and not
> be too generic.
OK. I was planning on always padding vxlan_opts to 4 bytes as well but
I agree with you. It seems clearer to have distinct functions for each
and they can share code where it makes sense.
> > @@ -1148,10 +1145,10 @@ int ovs_nla_put_flow(const struct sw_flow_key *swkey,
> > goto nla_put_failure;
> >
> > if ((swkey->tun_key.ipv4_dst || is_mask)) {
> > - const struct geneve_opt *opts = NULL;
> > + const void *opts = NULL;
> >
> > if (output->tun_key.tun_flags & TUNNEL_OPTIONS_PRESENT)
> > - opts = GENEVE_OPTS(output, swkey->tun_opts_len);
> > + opts = TUN_METADATA_OPTS(output, swkey->tun_opts_len);
> >
> > if (ipv4_tun_to_nlattr(skb, &output->tun_key, opts,
> > swkey->tun_opts_len))
>
> I think it's probably better to factor this block of code out into a
> new function as you have done in the next patch (and include it with
> this one). It makes it clearer that it is Geneve-specific.
OK, will do.
^ permalink raw reply
* [PATCH] net/at91_ether: prepare and unprepare clock
From: Alexandre Belloni @ 2015-01-07 22:59 UTC (permalink / raw)
To: Nicolas Ferre, David S. Miller
Cc: Boris Brezillon, linux-arm-kernel, linux-kernel, netdev,
Alexandre Belloni
The clock is enabled without being prepared, this leads to:
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:889 __clk_enable+0x24/0xa8()
and a non working ethernet interface.
Use clk_prepare_enable() and clk_disable_unprepare() to handle the clock.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/net/ethernet/cadence/at91_ether.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 55eb7f2af2b4..7ef55f5fa664 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -340,7 +340,7 @@ static int __init at91ether_probe(struct platform_device *pdev)
res = PTR_ERR(lp->pclk);
goto err_free_dev;
}
- clk_enable(lp->pclk);
+ clk_prepare_enable(lp->pclk);
lp->hclk = ERR_PTR(-ENOENT);
lp->tx_clk = ERR_PTR(-ENOENT);
@@ -406,7 +406,7 @@ static int __init at91ether_probe(struct platform_device *pdev)
err_out_unregister_netdev:
unregister_netdev(dev);
err_disable_clock:
- clk_disable(lp->pclk);
+ clk_disable_unprepare(lp->pclk);
err_free_dev:
free_netdev(dev);
return res;
@@ -424,7 +424,7 @@ static int at91ether_remove(struct platform_device *pdev)
kfree(lp->mii_bus->irq);
mdiobus_free(lp->mii_bus);
unregister_netdev(dev);
- clk_disable(lp->pclk);
+ clk_disable_unprepare(lp->pclk);
free_netdev(dev);
return 0;
@@ -440,7 +440,7 @@ static int at91ether_suspend(struct platform_device *pdev, pm_message_t mesg)
netif_stop_queue(net_dev);
netif_device_detach(net_dev);
- clk_disable(lp->pclk);
+ clk_disable_unprepare(lp->pclk);
}
return 0;
}
@@ -451,7 +451,7 @@ static int at91ether_resume(struct platform_device *pdev)
struct macb *lp = netdev_priv(net_dev);
if (netif_running(net_dev)) {
- clk_enable(lp->pclk);
+ clk_prepare_enable(lp->pclk);
netif_device_attach(net_dev);
netif_start_queue(net_dev);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension
From: Thomas Graf @ 2015-01-07 23:01 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, Stephen Hemminger, Pravin Shelar, netdev,
dev@openvswitch.org
In-Reply-To: <CAEP_g=__Ssxj3B_0sbp5D+Gh8YmQ7ub9giK4A_QYWVmYctjm-w@mail.gmail.com>
On 01/07/15 at 02:46pm, Jesse Gross wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf <tgraf@suug.ch> wrote:
> > The group policy metadata is handled in the same way as Geneve options
> > and transported as binary blob in a new Netlink attribute
> > OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS which is mutually exclusive to the
> > existing OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS.
>
> Can you explain some more what the encoding would look like if
> additional options were defined (including ones that are potentially
> mutually exclusive)? The Geneve options are binary but that is coming
> directly from the protocol specification. However, this isn't an on
> the wire format so I'm not sure what it would look like or how it
> would be defined to avoid conflict and allow evolution.
The encoding will be based on struct ovs_vxlan_opts which is extended
as needed by appending new members to the end of the struct. Parsers
will look at the provided length to see which fields are provided.
The user space side looks as follows. I will add similar logic to the
kernel side as soon as we have a 2nd extension.
+/* Returns true if attribute is long enough to cover member of type. */
+#define NL_PROVIDES_MEMBER(attr, type, member, size) \
+ (nl_attr_get_size(attr) >= (offsetof(type, member) + size))
+
[...]
+ case OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS: {
+ struct ovs_vxlan_opts *vxlan_opts;
+
+ /* Length verification done per member */
+ vxlan_opts = (struct ovs_vxlan_opts *)nl_attr_get_unspec(a, 0);
+
+ if (NL_PROVIDES_MEMBER(a, struct ovs_vxlan_opts, gbp, sizeof(vxlan_opts->gbp))) {
+ tun->gbp_id = htons(vxlan_opts->gbp & 0xFFFF);
+ tun->gbp_flags = (vxlan_opts->gbp >> 16) & 0xFF;
+ }
+ break;
+ }
^ permalink raw reply
* Re: [PATCH v4 14/20] selftests/size: add install target to enable test install
From: Tim Bird @ 2015-01-07 23:05 UTC (permalink / raw)
To: Shuah Khan, mmarek@suse.cz, gregkh@linuxfoundation.org,
akpm@linux-foundation.org, rostedt@goodmis.org, mingo@redhat.com,
davem@davemloft.net, keescook@chromium.org,
tranmanphong@gmail.com, mpe@ellerman.id.au, cov@codeaurora.org,
dh.herrmann@gmail.com, hughd@google.com, bobby.prani@gmail.com,
serge.hallyn@ubuntu.com, ebiederm@xmission.com,
josh@joshtriplett.org, koct9i@gmail.com,
"masami.hiramatsu.pt@hitachi.com" <masami.hiram
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <5861e16e1b533cae37471a8cf18597d3e9e6b6f6.1420571615.git.shuahkh@osg.samsung.com>
On 01/06/2015 11:43 AM, Shuah Khan wrote:
> Add a new make target to enable installing test. This target
> installs test in the kselftest install location and add to the
> kselftest script to run the test. Install target can be run
> only from top level kernel source directory.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> ---
> tools/testing/selftests/size/Makefile | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/size/Makefile b/tools/testing/selftests/size/Makefile
> index 04dc25e..a1478fa 100644
> --- a/tools/testing/selftests/size/Makefile
> +++ b/tools/testing/selftests/size/Makefile
> @@ -1,12 +1,22 @@
> CC = $(CROSS_COMPILE)gcc
>
> +TEST_STR = ./get_size || echo 'get_size selftests: [FAIL]'
> +
> all: get_size
>
> get_size: get_size.c
> $(CC) -static -ffreestanding -nostartfiles -s $< -o $@
>
> +install:
> +ifdef INSTALL_KSFT_PATH
> + install ./get_size $(INSTALL_KSFT_PATH)
> + @echo "$(TEST_STR)" >> $(KSELFTEST)
> +else
> + @echo "Run make kselftest_install in top level source directory"
> +endif
> +
> run_tests: all
> - ./get_size
> + @$(TEST_STR)
>
> clean:
> $(RM) get_size
>
Acked-by: Tim Bird <tim.bird@sonymobile.com>
^ permalink raw reply
* Re: [PATCH 2/2] Fix copy-paste bug: assign from src struct not dest
From: Arend van Spriel @ 2015-01-07 23:06 UTC (permalink / raw)
To: Johannes Berg
Cc: Giel van Schijndel, Andy Shevchenko, linux-kernel, Kalle Valo,
Eliad Peller, John W. Linville, Arik Nemtsov,
open list:TI WILINK WIRELES..., NETWORKING DRIVERS
In-Reply-To: <1420668978.3407.28.camel@sipsolutions.net>
On 01/07/15 23:16, Johannes Berg wrote:
> On Wed, 2015-01-07 at 20:18 +0100, Giel van Schijndel wrote:
>
>> IMO the aligned block of code has the significant advantage of taking
>> advantage of humans' ability to spot things that break a pattern. Which
>> in this case becomes *very* visible when properly aligned, because
>> without the alignment there is no (visual) pattern (or at least not one
>> very suitable for my "visual processing system", I know the same applies
>> to at least some others).
>
> Yeah, well, but why even invoke that "visual processing system"?
>
> If you look, for example, at the __skb_clone function it just uses a
> macro:
>
> #define C(x) n->x = skb->x
This requires fixed names so I generally prefer to add them:
#define C(d, s, f) (d)->f = (s)->f
> and then
>
> C(len);
> C(data_len);
C(acx, conf, window_size);
C(acx, conf, increase_time);
Regards,
Arend
>
> etc.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH iproute2 -next v2] ip: route: add congestion control metric
From: Stephen Hemminger @ 2015-01-07 23:06 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: fw, netdev
In-Reply-To: <1420630098-21621-1-git-send-email-dborkman@redhat.com>
On Wed, 7 Jan 2015 12:28:18 +0100
Daniel Borkmann <dborkman@redhat.com> wrote:
> + if (i != RTAX_CC_ALGO)
> + val = *(unsigned *)RTA_DATA(mxrta[i]);
Please use rta_getattr_u32 here.
Yes, I know you copied old code, but the old code predated the helper
functions.
^ permalink raw reply
* Re: iproute2 tc: Print qdisc, stats, class, filter info to string rather than FILE
From: Stephen Hemminger @ 2015-01-07 23:08 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <20150107215331.GA19197@angus-think.lan>
On Wed, 7 Jan 2015 23:53:31 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Hi,
>
> I'd like to make possible to generate plot info about class hierarchy
> with qdisc, filters, stats info, but I see that all this staffs are
> printed to 'FILE *fp' which makes this hard to implement and seems to me
> that it should be changed to be printed to 'char *s' (memory safety
> should be considered by asprintf or similar), so this is a big change
> but all this is possible and I ready to do it, but before do it I'd like
> to ask if this could be acceptable as idea.
>
> BUT maybe someone can advise me easier solution ?
>
> Regards,
> --
> 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
Rather than screen scraping tc command, why not use libmnl and get the
data you want programmatically.
^ permalink raw reply
* Re: [patch iproute2 2/2] iplink: print out addrgenmode attribute
From: Stephen Hemminger @ 2015-01-07 23:10 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, thaller
In-Reply-To: <1420561426-3118-2-git-send-email-jiri@resnulli.us>
On Tue, 6 Jan 2015 17:23:46 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> addrgenmode is currently write only by ip. So display this information
> if provided by kernel as well.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Patch does not apply to current iproute2 git
^ permalink raw reply
* Re: [patch iproute2 1/2] libnetlink: add parse_rtattr_one_nested helper
From: Stephen Hemminger @ 2015-01-07 23:15 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, thaller
In-Reply-To: <1420561426-3118-1-git-send-email-jiri@resnulli.us>
On Tue, 6 Jan 2015 17:23:45 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Sometimes, it is more convenient to get only one specific nested attribute by
> type. For example for IFLA_AF_SPEC where type is address family (AF_INET6).
> So add this helper for this purpose.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
This one applies.
^ permalink raw reply
* Re: WIP alternative - was Re: [PATCH v3 14/20] selftests/size: add install target to enable test install
From: Shuah Khan @ 2015-01-07 23:22 UTC (permalink / raw)
To: Tim Bird, mmarek@suse.cz, gregkh@linuxfoundation.org,
akpm@linux-foundation.org, rostedt@goodmis.org, mingo@redhat.com,
davem@davemloft.net, keescook@chromium.org,
tranmanphong@gmail.com, mpe@ellerman.id.au, cov@codeaurora.org,
dh.herrmann@gmail.com, hughd@google.com, bobby.prani@gmail.com,
serge.hallyn@ubuntu.com, ebiederm@xmission.com,
josh@joshtriplett.org, koct9i@gmail.com
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <54AB08AB.7040009@sonymobile.com>
On 01/05/2015 02:56 PM, Tim Bird wrote:
> On 01/05/2015 01:28 PM, Shuah Khan wrote:
>> On 12/31/2014 07:31 PM, Tim Bird wrote:
> ...
>>> The install phase is desperately needed for usage of kselftest in
>>> cross-target situations (applicable to almost all embedded). So this
>>> is great stuff.
>>
>> Thanks.
>>
>>>
>>> I worked a bit on isolating the install stuff to a makefile include file.
>>> This allows simplifying some of the sub-level Makefiles a bit, and allowing
>>> control of some of the install and run logic in less places.
>>>
>>> This is still a work in progress, but before I got too far along, I wanted
>>> to post it for people to provide feedback. A couple of problems cropped
>>> up that are worth discussing, IMHO.
>>>
>>> 1) I think it should be a requirement that each test has a single
>>> "main" program to execute to run the tests. If multiple tests are supported
>>> or more flexibility is desired for additional arguments, or that sort of
>>> thing, then that's fine, but the automated script builder should be able
>>> to run just a single program or script to have things work. This also
>>> makes things more consistent. In the case of the firmware test, I created
>>> a single fw_both.sh script to do this, instead of having two separate
>>> blocks in the kselftest.sh script.
>>
>> It is a good goal for individual tests to use a main program to run
>> tests, even though, I would not make it a requirement. I would like to
>> leave that decision up to the individual test writer.
>>
> OK. It helps to have a single line when trying to isolate
> RUN_TEST creation into the include file, but there may be other
> ways to accomplish this.
>
>>>
>>> 2) I've added a CROSS_INSTALL variable, which can call an arbitrary program
>>> to place files on the target system (rather than just calling 'install').
>>> In my case, I'd use my own 'ttc cp' command, which I can extend as necessary
>>> to put things on a remote machine. This works for a single directory,
>>> but things get dicier with sub-directory trees full of files (like
>>> the ftrace test uses.)
>>>
>>> If additional items need to be installed to the target, then maybe a setup
>>> program should be used, rather than just copying files.
>>>
>>> 3) Some of the scripts were using /bin/bash to execute them, rather
>>> than rely on the interpreter line in the script itself (and having
>>> the script have executable privileges). Is there a reason for this?
>>> I modified a few scripts to be executable, and got rid of the
>>> explicit execution with /bin/bash.
>>
>> Probably no reason other than the choice made by the test writer.
>> It could be cleaned up and made consistent, however, I would see
>> this as a separate enhancement type work that could be done on its
>> own and not include it in the install work.
>
> OK - this was also something that simplified the creation
> of the RUN_TEST variable in the isolated include file.
> Also, having the interpreter explicit in the invocation line
> in the Makefile as well as in the script itself is a bit redundant.
>>>
>>> The following is just a start... Let me know if this direction looks
>>> OK, and I'll finish this up. The main item to look at is
>>> kselftest.include file. Note that these patches are based on Shuah's
>>> series - but if you want to use these ideas I can rebase them onto
>>> mainline, and break them out per test sub-level like Shuah did.
>>
>> One of the reasons I picked install target approach is to enable the
>> feature by extending the existing run_tests support. This way we will
>> have the feature available quickly. Once that is supported, we can work
>> on evolving to a generic approach to use the include file approach, as
>> the changes you are proposing are based on the the series I sent out,
>> and makes improvements to it.
>>
>> kselftest.include file approach could work for several tests and tests
>> that can't use the generic could add their own install support.
>>
>> I propose evolving to a generic kselftest.include as the second step in
>> evolving the install feature. Can I count on you do the work and update
>> the tests to use kselftest.include, CROSS_INSTALL variable support?
>
> Yes. I'd be happy to evolve it through phases to support the include
> file and cross-target install feature.
Thanks that would be great.
>
> Is there anything I can help with in the mean time? Some of the tests
> require a directory tree of files rather than just a few top-level files
> (e.g. ftrace).
I left out couple of tests in this first round. exec and powerpc. Would
you like to add install target support for these tests? That is the next
thing on my list of todo and if you would like to get that working, you
are welcome to.
>
> I was thinking about doing some work to tar-ify the needed directories of
> data files during build, and untar it in the execution area during the
> install step. Do you want me to propose something there?
More like generating tar-ball of the install directory for remote
installs perhaps. Since install feature is using existing Makefile,
user can specify a override install location. Is there a need for,
more like use for generating a tar-ball for remote installs?
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 1/6] vxlan: Allow for VXLAN extensions to be implemented
From: Thomas Graf @ 2015-01-07 23:24 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Linux Netdev List,
Stephen Hemminger, David Miller, Tom Herbert
In-Reply-To: <CAEP_g=_Xr=6nVoeVT8dgRZoM0bNXDiiua5GrjweZ1GaT1ixhZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/07/15 at 02:45pm, Jesse Gross wrote:
> My concern is that having multiple (and potentially overlapping)
> extensions is going to make the VXLAN code very messy and hard to
> follow. I think there's already quite a big of complexity there from
> the DOVE extensions (which are basically dead at this point to the
> best of my knowledge). We already see this some with the discussion
> over the header struct but that's just the beginning - can you imagine
> the code that checks a single bit for several different
> interpretations?
I'm not disagreeing with you Jesse. I think it's manageable though.
I don't think the code as proposed is overly difficult to understand
or messy. I'm glad to adjust the struct definition if the union style
is considered messy, no problem.
We have these reserved bits in a widely used protocol and it is our
choice to make use of these bits or not. My opinion is that we should.
Good candidates to me seem to be GBP for security labels, RCO for
checksumming and GPE for non-L2 over VXLAN.
I would love for everybody to switch over to Geneve or GUE and as you
know I'm highly interested in pushing it forward. Reality is that it
might be another couple of years for it to become fully established.
> Not to mention the fact that the location of the bits
> in some of these proposals has already been shuffled several times. It
> seems very painful...
I don't really want to defend the process behind these drafts. I
believe that code defines the standard, in particular open source code.
As for GBP, we are the authors of the draft and this has been deployed
to hardware as well so this won't change.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Thomas Graf @ 2015-01-07 23:27 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Stephen Hemminger,
David S. Miller
In-Reply-To: <CAADnVQJErdNJrXOOSqEqkbC8524VCH2E9vYL-WdTb_6SGsTwvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/07/15 at 09:32am, Alexei Starovoitov wrote:
> I'm afraid 'union' style with first u8 flags working as selector
> won't work for the case you're describing, but since
> md.gbp = ntohs(vxh->gbp.policy_id);
> 2652: 41 0f b7 55 0a movzwl 0xa(%r13),%edx
> then at least from performance side it's ok at least on x86.
> So this _packed stuff is fine, though not pretty.
> It's internal header, so we can improve it later.
I'm not sure I understand your first sentence but I'm not
married to the code as-is.
Would you like something like this?
struct vxlanhdr_gbp {
__u8 vx_flags;
+#ifdef __LITTLE_ENDIAN_BITFIELD
+ __u8 reserved_flags1:3,
+ policy_applied:1,
+ reserved_flags2:2,
+ dont_learn:1,
+ reserved_flags3:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ __u8 reserved_flags1:1,
+ dont_learn:1,
+ reserved_flags2:2,
+ policy_applied:1,
+ reserved_flags3:3;
+#else
+#error "Please fix <asm/byteorder.h>"
+#endif
+ __be16 policy_id;
+ __be32 vx_vni;
};
struct vxlanhdr {
+ union {
+ struct {
+#ifdef __LITTLE_ENDIAN_BITFIELD
+ __u8 reserved_flags1:3,
+ vni_present:1,
+ reserved_flags2:3,
+ gbp_present:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ __u8 gbp_present:1,
+ reserved_flags2:3,
+ vni_present:1,
+ reserved_flags1:3;
+#else
+#error "Please fix <asm/byteorder.h>"
+#endif
+ __u8 vx_reserved1;
+ __be16 vx_reserved2;
+ };
+ __be32 vx_flags;
+ };
+ __be32 vx_vni;
};
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH iproute2 -next v2] ip: route: add congestion control metric
From: Daniel Borkmann @ 2015-01-07 23:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: fw, netdev
In-Reply-To: <20150107150657.1defa6bd@urahara>
On 01/08/2015 12:06 AM, Stephen Hemminger wrote:
> On Wed, 7 Jan 2015 12:28:18 +0100
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
>> + if (i != RTAX_CC_ALGO)
>> + val = *(unsigned *)RTA_DATA(mxrta[i]);
>
> Please use rta_getattr_u32 here.
>
> Yes, I know you copied old code, but the old code predated the helper
> functions.
No problem, that looks better indeed. Will add it.
Btw, while we're on the topic, we ignore errors for all rta_addattr*()
functions f.e. in iproute_modify(). I think at least we should undo the
mxlock in case of an error (or bail out entirely as a different option).
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Alexei Starovoitov @ 2015-01-07 23:39 UTC (permalink / raw)
To: Thomas Graf
Cc: David S. Miller, Jesse Gross, Stephen Hemminger, Pravin Shelar,
netdev@vger.kernel.org, dev@openvswitch.org
In-Reply-To: <20150107232740.GE21149@casper.infradead.org>
On Wed, Jan 7, 2015 at 3:27 PM, Thomas Graf <tgraf@suug.ch> wrote:
>
> Would you like something like this?
yes. imo this version is much easier to read
and reason about different bits in protocol.
May be even use a flag mask on '__be32 vx_flags'
instead of calling out 'gbp_present' as explicit bitfield.
Then different vxlan extensions proposals don't
have to fight over positions in the first byte of
single 'struct vxlanhdr'...
but to me the below two structs look good as-is.
> struct vxlanhdr_gbp {
> __u8 vx_flags;
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> + __u8 reserved_flags1:3,
> + policy_applied:1,
> + reserved_flags2:2,
> + dont_learn:1,
> + reserved_flags3:1;
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> + __u8 reserved_flags1:1,
> + dont_learn:1,
> + reserved_flags2:2,
> + policy_applied:1,
> + reserved_flags3:3;
> +#else
> +#error "Please fix <asm/byteorder.h>"
> +#endif
> + __be16 policy_id;
> + __be32 vx_vni;
> };
>
> struct vxlanhdr {
> + union {
> + struct {
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> + __u8 reserved_flags1:3,
> + vni_present:1,
> + reserved_flags2:3,
> + gbp_present:1;
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> + __u8 gbp_present:1,
> + reserved_flags2:3,
> + vni_present:1,
> + reserved_flags1:3;
> +#else
> +#error "Please fix <asm/byteorder.h>"
> +#endif
> + __u8 vx_reserved1;
> + __be16 vx_reserved2;
> + };
> + __be32 vx_flags;
> + };
> + __be32 vx_vni;
> };
>
^ permalink raw reply
* [PATCH 1/1] update ip-sysctl.txt documentation (v2)
From: Ani Sinha @ 2015-01-07 23:45 UTC (permalink / raw)
To: corbet, davem, edumazet, linux-doc, linux-kernel, ani, P, netdev,
fruggeri
Update documentation to reflect the fact that
/proc/sys/net/ipv4/route/max_size is no longer used for ipv4.
Signed-off-by: Ani Sinha <ani@arista.com>
---
Documentation/networking/ip-sysctl.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 9bffdfc..85b0221 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -66,6 +66,8 @@ fwmark_reflect - BOOLEAN
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
+ From linux kernel 3.6 onwards, this is deprecated for ipv4
+ as route cache is no longer used.
neigh/default/gc_thresh1 - INTEGER
Minimum number of entries to keep. Garbage collector will not
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/1] update ip-sysctl.txt documentation
From: Ani Sinha @ 2015-01-07 23:46 UTC (permalink / raw)
To: David Laight
Cc: corbet@lwn.net, davem@davemloft.net, edumazet@google.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
P@draigbrady.com, netdev@vger.kernel.org, fruggeri@arista.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAC2762@AcuExch.aculab.com>
On Wed, Jan 7, 2015 at 2:11 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Ani Sinha
>> Update documentation to reflect the fact that
>> /proc/sys/net/ipv4/route/max_size is no longer used for ipv4.
>>
>> Signed-off-by: Ani Sinha <ani@arista.com>
>> ---
>> Documentation/networking/ip-sysctl.txt | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
>> index 9bffdfc..2a28261 100644
>> --- a/Documentation/networking/ip-sysctl.txt
>> +++ b/Documentation/networking/ip-sysctl.txt
>> @@ -64,8 +64,10 @@ fwmark_reflect - BOOLEAN
>> Default: 0
>>
>> route/max_size - INTEGER
>> - Maximum number of routes allowed in the kernel. Increase
>> - this when using large numbers of interfaces and/or routes.
>> + Post linux kernel 3.6, this is deprecated for ipv4 as route cache is no
>> + longer used. For ipv6, this is used to limit the maximum number of ipv6
>> + routes allowed in the kernel. Increase this when using large numbers of
>> + interfaces and/or routes.
>
> Now imagine you are reading ip-sysctl.txt, the new text is all wrong.
> Something like:
> Limit on the size of the ip route caches.
> Ignored for ipv4 after kernel 3.6 because the ipv4 route cache was removed.
> Increase this when using large numbers of interfaces and/or routes.
> would read better.
Ok please take a look at my patch v2.
^ permalink raw reply
* [PATCH net-next] openvswitch: Add ovs_vport_get_index() to hide vport implementation
From: Daniele Di Proietto @ 2015-01-07 23:48 UTC (permalink / raw)
To: netdev; +Cc: Daniele Di Proietto
datapath.c should not access private vport data. This commit adds
'ovs_vport_get_index()' to vport.c and '.get_index()' to vport_ops
to hide vport implementation details.
Signed-off-by: Daniele Di Proietto <daniele.di.proietto@gmail.com>
---
net/openvswitch/datapath.c | 5 +----
net/openvswitch/vport-internal_dev.c | 1 +
net/openvswitch/vport-netdev.c | 8 ++++++++
net/openvswitch/vport-netdev.h | 1 +
net/openvswitch/vport.c | 9 +++++++++
net/openvswitch/vport.h | 2 ++
6 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4e9a5f0..a1b113f 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -185,10 +185,7 @@ static int get_dpifindex(const struct datapath *dp)
rcu_read_lock();
local = ovs_vport_rcu(dp, OVSP_LOCAL);
- if (local)
- ifindex = netdev_vport_priv(local)->dev->ifindex;
- else
- ifindex = 0;
+ ifindex = ovs_vport_get_index(local);
rcu_read_unlock();
diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
index 6a55f71..d0090b0 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -250,6 +250,7 @@ static struct vport_ops ovs_internal_vport_ops = {
.create = internal_dev_create,
.destroy = internal_dev_destroy,
.get_name = ovs_netdev_get_name,
+ .get_index = ovs_netdev_get_index,
.send = internal_dev_recv,
};
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 4776282..06a4824 100644
--- a/net/openvswitch/vport-netdev.c
+++ b/net/openvswitch/vport-netdev.c
@@ -182,6 +182,13 @@ const char *ovs_netdev_get_name(const struct vport *vport)
return netdev_vport->dev->name;
}
+int ovs_netdev_get_index(const struct vport *vport)
+{
+ const struct netdev_vport *netdev_vport = netdev_vport_priv(vport);
+
+ return netdev_vport->dev->ifindex;
+}
+
static unsigned int packet_length(const struct sk_buff *skb)
{
unsigned int length = skb->len - ETH_HLEN;
@@ -231,6 +238,7 @@ static struct vport_ops ovs_netdev_vport_ops = {
.create = netdev_create,
.destroy = netdev_destroy,
.get_name = ovs_netdev_get_name,
+ .get_index = ovs_netdev_get_index,
.send = netdev_send,
};
diff --git a/net/openvswitch/vport-netdev.h b/net/openvswitch/vport-netdev.h
index 6f7038e..892520a 100644
--- a/net/openvswitch/vport-netdev.h
+++ b/net/openvswitch/vport-netdev.h
@@ -39,6 +39,7 @@ netdev_vport_priv(const struct vport *vport)
}
const char *ovs_netdev_get_name(const struct vport *);
+int ovs_netdev_get_index(const struct vport *);
void ovs_netdev_detach_dev(struct vport *);
int __init ovs_netdev_init(void);
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 53f3ebb..884bba5 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -633,3 +633,12 @@ int ovs_vport_get_egress_tun_info(struct vport *vport, struct sk_buff *skb,
return vport->ops->get_egress_tun_info(vport, skb, info);
}
+
+int ovs_vport_get_index(const struct vport *vport)
+{
+ /* return 0 if get_index is not implemented */
+ if (!vport || !vport->ops->get_index)
+ return 0;
+
+ return vport->ops->get_index(vport);
+}
diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
index 99c8e71..8645dab 100644
--- a/net/openvswitch/vport.h
+++ b/net/openvswitch/vport.h
@@ -57,6 +57,7 @@ int ovs_vport_get_upcall_portids(const struct vport *, struct sk_buff *);
u32 ovs_vport_find_upcall_portid(const struct vport *, struct sk_buff *);
int ovs_vport_send(struct vport *, struct sk_buff *);
+int ovs_vport_get_index(const struct vport *);
int ovs_tunnel_get_egress_info(struct ovs_tunnel_info *egress_tun_info,
struct net *net,
@@ -171,6 +172,7 @@ struct vport_ops {
/* Called with rcu_read_lock or ovs_mutex. */
const char *(*get_name)(const struct vport *);
+ int (*get_index)(const struct vport *);
int (*send)(struct vport *, struct sk_buff *);
int (*get_egress_tun_info)(struct vport *, struct sk_buff *,
--
2.1.4
^ 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