* Re: [PATCH v2.43 0/5] MPLS actions and matches
From: Jesse Gross @ 2013-10-16 20:21 UTC (permalink / raw)
To: Ben Pfaff
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Ravi K, netdev,
Isaku Yamahata
In-Reply-To: <20131016035530.GA29165-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
On Tue, Oct 15, 2013 at 8:55 PM, Ben Pfaff <blp-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Oct 10, 2013 at 09:31:41AM +0900, Simon Horman wrote:
>> I believe this series addresses the feedback that each of you
>> gave with regards to recent previous postings of this patch-set.
>> I'm wondering if you could find some time to review it.
>
> I'm waiting for an ack from Jesse, then I'm going to do a final pass and
> I hope to commit this series at this point. I see some ways that we can
> improve MPLS support afterward but I don't see any blockers.
I guess that we had a deadlock as I was waiting for you. I though that
maybe you would commit the rest of the userspace patches and then I
would just pick up the last two.
^ permalink raw reply
* Re: [RFC] bridge and friends: reduce TheLinuxWay(tm)
From: Vlad Yasevich @ 2013-10-16 20:22 UTC (permalink / raw)
To: Jamal Hadi Salim, Eric Dumazet
Cc: Stephen Hemminger, Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <525EF4E7.1030003@mojatatu.com>
On 10/16/2013 04:19 PM, Jamal Hadi Salim wrote:
>
> And another little glitch, iflink specifies
>
> [IFLA_AF_SPEC] = {
> [AF_INET] = {
> [IFLA_INET_CONF] = ...,
> },
> [AF_INET6] = {
> [IFLA_INET6_FLAGS] = ...,
> [IFLA_INET6_CONF] = ...,
> }
>
> But then bridge hijacks it and specifies:
> [IFLA_AF_SPEC] = {
> [IFLA_BRIDGE_FLAGS]
> [IFLA_BRIDGE_MODE]
> [IFLA_BRIDGE_VLAN_INFO]
> }
>
> Was that intended as:
>
> [IFLA_AF_SPEC] = {
> [AF_BRIDGE] = {
> [IFLA_BRIDGE_FLAGS]
> [IFLA_BRIDGE_MODE]
> [IFLA_BRIDGE_VLAN_INFO]
> }
> }
>
> Now granted that bridging uses PF_BRIDGE as the family and iflink uses
> PF_UNSPEC - but i do think this one is polluting the namespace.
>
Yes, I know about that one. BRIDGE_FLAGS started the polution and then
we continued it with the other attributes....
-vlad
> cheers,
> jamal
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-16 20:22 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks
In-Reply-To: <20131016143246.GB18135@order.stressinduktion.org>
Hello,
On Wed, 16 Oct 2013, Hannes Frederic Sowa wrote:
> On Wed, Oct 16, 2013 at 10:27:47AM +0300, Julian Anastasov wrote:
> >
> > I don't know the IPv6 routing but if we find a way
> > to keep the desired nexthop in rt6i_gateway and to add
> > RTF_GATEWAY checks here and there such solution would be more
> > general. FLOWI_FLAG_KNOWN_NH flag can help, if needed.
>
> I thought about this yesterday but did not see an easy way. How does the IPv4
> implementation accomplish this?
In IPv4 rt->rt_flags has no bit to indicate if the route
is via gateway (like RTF_GATEWAY in IPv6). We added rt_uses_gateway
for this purpose.
In the default case, rt_gateway may contain 0 if we return
cached result, eg. when target is part of a local subnet.
Then IPVS/TEE/RAW can request valid rt_gateway, even with the price
of a cloned result, so that rt_gateway can remember the requested
nexthop which may differ from daddr.
> ipvs caches the dst in its own infrastructure, so we need to be sure we don't
> disconnect this dst from the ipv6 routing table, otherwise ip6_dst_check won't
> recognize when relookups should be done. Playing games with RTF_GATEWAY seems
> dangerous then.
dst_check works for IPVS. There is a problem only
with the recent changes that moved the indication for PMTU
change from dst_check to dst_mtu() calls. But this is safe
for IPVS, it handles FRAG_NEEDED for the tunneling mode itself.
Initially, I thought IPv6 stores zeroes in rt6i_gateway.
But now I see rt6_alloc_cow() to be called for the case I assumed
to fail - when no gateway is used.
So, I'll try to test the IPVS case in the following 1-2 days
and will report after adding some printks. If xt_TEE has
the same problem then it should not be IPVS-specific. RAW not
tested yet.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: Greg KH @ 2013-10-16 20:24 UTC (permalink / raw)
To: Enrico Mioso
Cc: davem, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel, Antonella Pellizzari
In-Reply-To: <1381842408-10800-2-git-send-email-mrkiko.rs@gmail.com>
On Tue, Oct 15, 2013 at 03:06:48PM +0200, Enrico Mioso wrote:
> This is a QMI device, manufactured by TCT Mobile Phones.
> A companion patch blacklisting this device's QMI interface in the option.c
> driver has been sent.
>
> Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
> Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
From: Giuseppe CAVALLARO @ 2013-10-16 20:29 UTC (permalink / raw)
To: Romain Baeriswyl; +Cc: David S. Miller, netdev, linux-kernel, Christian Ruppert
In-Reply-To: <808496140.2212.1381694572197.JavaMail.root@abilis.com>
Hello Romain
On 10/13/2013 10:02 PM, Romain Baeriswyl wrote:
> Hello Guiseppe,
>
> Thanks for your answer. Please find below some details and answers.
>
>>> In order to avoid system overload, the clock RXC from the Phy
>>> should not be
>>> stopped when in LPI mode.
>>>
>>> With the RTL8211E PHY which support EEE mode and with Apple Airport
>>> Extreme that
>>> supports it also, the kernel get frozen as soon as some Ethernet
>>> transfers are
>>
>>
>> hmm, I have a board with this transceiver so I could do some tests
>> this could take a while, unfortunately.
>>
>>> on-going. System seems to be overloaded with too many interrupts.
>>> The 'top'
>>> command reports often around ~80% irq.
>>
>> do you mean lpi mac interrupts?
>
> By disabling the LPI mode with ethtool --set-eee eth0 eee off, the
> interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and
> irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue
> to put the RX path in LPI mode.
>
> Only way I found to get ride of the overload is to keep the RX_CLK running
> in LPI mode. In this configuration, the RX link still continue to go in
> LPI mode and the two above counters continue to run.
>
>>>
>>> By letting the RXC clock running even in LPI mode as proposed
>>> below, the issue
>>> seems solved. Is it the right way to proceed?
>>
>> For EEE capability, RX_CLK may be halted for this reason i used it as
>> default in the stmmac and never seen your issue.
>>
>>>
>>> What is the power impact to not stop RXC in LPI mode?
>>
>> I can point you to "22.2.2.8a Receive direction LPI transition"
>> in IEEE802-3az... where is it reported that the PHY halt the RX_CLK
>> in LPI mode.
>
> Actually the PHY "may" stop RX_CLK.
Another option it could be add a new parameter to enable/disable it.
We can decide a parameter for the stmmac or something for ethtool.
>
>>
>> May I suspect some issues on your HW? or disable it with ethtool
>>
>
> Yes, it could be HW issue. It would be very useful if you could reproduce
> the setup using a SoC with "DesignWare Cores Ethernet MAC" core,
> the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between
> the controller and the PHY.
>
> Which Ethernet switch or router did you use to test the EEE mode?
when I tested EEE I connected with P2P two STi boards.
You can test it too.
> I may try these equipments as well.
>
peppe
^ permalink raw reply
* Re: [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation
From: Giuseppe CAVALLARO @ 2013-10-16 20:37 UTC (permalink / raw)
To: Jimmy Perchet; +Cc: netdev
In-Reply-To: <1381937052-8999-1-git-send-email-jimmy.perchet@parrot.com>
Hello Jimmy
On 10/16/2013 5:24 PM, Jimmy Perchet wrote:
> Hello,
>
> I began using Synopsys IP few weeks ago and figured out that jumbo frames
> are not well supported by stmmac driver.
I tested jumbo on chips w/o enhanced some time ago, so welcome further
tests as you did (maybe on new chips).
>
> This patch series addresses several issues which prevent them from working
> properly :
> *(1/5) Threshold dma mode is needed on rx path if jumbo frames are expected.
hmm, this depends on the HW. In the past I used HW with a Fifo that is
16KiB for rx buffers and 8KiB for tx.
So this could be managed according to these sizes I guess...
>
> *(2/5) RX buffers are not allocated with the needed size because
> priv->dma_buf_sz is updated too late (i.e. after stmmac_init_rx_buffers call)
I'll look at the patch in detail
>
> *(3/5) On low speed link (10MBit/s), some TX descriptors can remain dirty
> if the tx coalescence timer expires before they were treated. Re-arm timer
> in this case.
hmm not clear to me, let me look at the patch. I hope the link should
not impact... never seen on my side.
>
> *(4/5) There is several confusions regarding descriptor's max buffer size,
> typically the "-1" is often forgotten.
also for this I need to look at the patch
> *(4/5) Jumbo frames' last descriptor is never "closed", resulting in truncated
> frames transfer.
it sounds to be a bug... let me check
> *(4/5) Frags could not be jumbo.
> Regarding these last points, I didn't find simpler way than writing
> new "prepare frame" functions for both ring and chain mode and update
> xmit function accordingly.
it is strange and not clear too. At any rate, both modes must be
supported
>
> The last patch is not related to jumbo frames but concern a possible
> optimisation :
> *(5/5) Tx descriptor's cleanup and preparation are serialized, which is not
> necessary and decrease performance. In addition TX descriptor's cleanup is
> performed on NET_-RX- softirq, this is confusing.
> By taking care of "cur_tx" and "dirty_tx" it is possible to avoid serialization
> and defer cleanup in workqueue.
> On my smp embedded system, with 1Gbit/s link which is cpu bound, it increases
> througput by about 90MBit/s (400MBit/s to 490MBit/s).
This sounds another good point, let me enter in the patch
BR
Peppe
>
>
> Best Regards,
> Jimmy Perchet
>
> Jimmy Perchet (5):
> net:stmmac: set threshold/store and forward mode according to mtu
> size.
> net:stmmac: fix rx buffer allocation.
> net:stmmac: ensure we reclaim all dirty descriptors.
> net:stmmac: fix jumbo frame handling.
> net:stmmac: asynchronous tx_clean
>
> drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 99 +++++-----
> drivers/net/ethernet/stmicro/stmmac/common.h | 6 +
> drivers/net/ethernet/stmicro/stmmac/descs_com.h | 8 +-
> drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 6 +
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 6 +
> drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 90 ++++-----
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 219 +++++++++++++---------
> 8 files changed, 233 insertions(+), 207 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 5/5] net: rfkill: gpio: add ACPI support
From: Rafael J. Wysocki @ 2013-10-16 20:55 UTC (permalink / raw)
To: Heikki Krogerus
Cc: John W. Linville, Johannes Berg, Rhyland Klein, linux-acpi,
linux-wireless, netdev, Mika Westerberg
In-Reply-To: <1381920823-15403-6-git-send-email-heikki.krogerus@linux.intel.com>
On Wednesday, October 16, 2013 01:53:43 PM Heikki Krogerus wrote:
> Including ACPI ID for Broadcom GPS receiver BCM4752.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> net/rfkill/rfkill-gpio.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
> index 2dd78c6..5620d3c 100644
> --- a/net/rfkill/rfkill-gpio.c
> +++ b/net/rfkill/rfkill-gpio.c
> @@ -24,6 +24,8 @@
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> #include <linux/slab.h>
> +#include <linux/acpi.h>
> +#include <linux/acpi_gpio.h>
>
> #include <linux/rfkill-gpio.h>
>
> @@ -70,6 +72,23 @@ static const struct rfkill_ops rfkill_gpio_ops = {
> .set_block = rfkill_gpio_set_power,
> };
>
> +static int rfkill_gpio_acpi_probe(struct device *dev,
> + struct rfkill_gpio_data *rfkill)
> +{
> + const struct acpi_device_id *id;
> +
> + id = acpi_match_device(dev->driver->acpi_match_table, dev);
> + if (!id)
> + return -ENODEV;
> +
> + rfkill->name = dev_name(dev);
> + rfkill->type = (unsigned)id->driver_data;
> + rfkill->reset_gpio = acpi_get_gpio_by_index(dev, 0, NULL);
> + rfkill->shutdown_gpio = acpi_get_gpio_by_index(dev, 1, NULL);
> +
> + return 0;
> +}
> +
> static int rfkill_gpio_probe(struct platform_device *pdev)
> {
> struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
> @@ -82,7 +101,11 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
> if (!rfkill)
> return -ENOMEM;
>
> - if (pdata) {
> + if (ACPI_HANDLE(&pdev->dev)) {
> + ret = rfkill_gpio_acpi_probe(&pdev->dev, rfkill);
> + if (ret)
> + return ret;
> + } else if (pdata) {
> clk_name = pdata->power_clk_name;
> rfkill->name = pdata->name;
> rfkill->type = pdata->type;
> @@ -170,12 +193,18 @@ static int rfkill_gpio_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct acpi_device_id rfkill_acpi_match[] = {
> + { "BCM4752", RFKILL_TYPE_GPS },
> + { },
> +};
> +
> static struct platform_driver rfkill_gpio_driver = {
> .probe = rfkill_gpio_probe,
> .remove = rfkill_gpio_remove,
> .driver = {
> .name = "rfkill_gpio",
> .owner = THIS_MODULE,
> + .acpi_match_table = ACPI_PTR(rfkill_acpi_match),
> },
> };
Looks good to me.
Has Mika seen this?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH v2.43 0/5] MPLS actions and matches
From: Ben Pfaff @ 2013-10-16 20:47 UTC (permalink / raw)
To: Jesse Gross
Cc: Simon Horman, dev@openvswitch.org, netdev, Pravin B Shelar,
Ravi K, Isaku Yamahata, Joe Stringer
In-Reply-To: <CAEP_g=-yCas_3MRY0VrP-W6hOi4wRYNW7=8HEB0GYOp--WU60A@mail.gmail.com>
On Wed, Oct 16, 2013 at 01:21:22PM -0700, Jesse Gross wrote:
> On Tue, Oct 15, 2013 at 8:55 PM, Ben Pfaff <blp@nicira.com> wrote:
> > On Thu, Oct 10, 2013 at 09:31:41AM +0900, Simon Horman wrote:
> >> I believe this series addresses the feedback that each of you
> >> gave with regards to recent previous postings of this patch-set.
> >> I'm wondering if you could find some time to review it.
> >
> > I'm waiting for an ack from Jesse, then I'm going to do a final pass and
> > I hope to commit this series at this point. I see some ways that we can
> > improve MPLS support afterward but I don't see any blockers.
>
> I guess that we had a deadlock as I was waiting for you. I though that
> maybe you would commit the rest of the userspace patches and then I
> would just pick up the last two.
Ah, OK.
I will do this, then, after a final pass.
^ permalink raw reply
* Personal Donation Offer
From: frank3 @ 2013-10-16 20:56 UTC (permalink / raw)
To: Recipients
My wife and i adrian won Jackpot Lottery and Decided to donate 2million dollars to you, Contact Mr Adrian on (bayfordga@qq.com) For More Info
^ permalink raw reply
* Re: linux-next: Tree for Oct 16 (net/sched/em_ipset.c)
From: Randy Dunlap @ 2013-10-16 21:48 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-next, linux-kernel, Mark Brown, netdev@vger.kernel.org
In-Reply-To: <1381949500-501-1-git-send-email-treding@nvidia.com>
On 10/16/13 11:51, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131016 tag is also provided for convenience.
>
> Gained two new conflicts, but nothing too exciting. x86 and ARM default
> configurations as well as the x86 allmodconfig mostly build fine on the
> final tree. There was a failure for the ARM at91x40_defconfig, but the
> proper fix wasn't immediately obvious to me, so I've left it broken for
> now.
on i386, when CONFIG_NET_NS is not enabled:
net/sched/em_ipset.c: In function 'em_ipset_change':
net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
net/sched/em_ipset.c: In function 'em_ipset_destroy':
net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
--
~Randy
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Hannes Frederic Sowa @ 2013-10-16 21:59 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks
In-Reply-To: <alpine.LFD.2.03.1310162252220.1917@ssi.bg>
On Wed, Oct 16, 2013 at 11:22:40PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 16 Oct 2013, Hannes Frederic Sowa wrote:
>
> > On Wed, Oct 16, 2013 at 10:27:47AM +0300, Julian Anastasov wrote:
> > >
> > > I don't know the IPv6 routing but if we find a way
> > > to keep the desired nexthop in rt6i_gateway and to add
> > > RTF_GATEWAY checks here and there such solution would be more
> > > general. FLOWI_FLAG_KNOWN_NH flag can help, if needed.
> >
> > I thought about this yesterday but did not see an easy way. How does the IPv4
> > implementation accomplish this?
>
> In IPv4 rt->rt_flags has no bit to indicate if the route
> is via gateway (like RTF_GATEWAY in IPv6). We added rt_uses_gateway
> for this purpose.
>
> In the default case, rt_gateway may contain 0 if we return
> cached result, eg. when target is part of a local subnet.
> Then IPVS/TEE/RAW can request valid rt_gateway, even with the price
> of a cloned result, so that rt_gateway can remember the requested
> nexthop which may differ from daddr.
To have ip6_dst_check working, there must to be a valid link from
the rt6_info to the fib6_node. Otherwise we cannot check the serial
number. As I currently see we also need a link from the fib6_node down
to the dst entry for resource management. Thus we would have to insert
the special dst-entry with RTF_GATEWAY and non-null rt6i_gateway back
into the fib and have it globally visible. This could have unforseen
side effects. We still cache all dst entries in the fib. One think I
foresee as a possible problem is the automatic aggregation of ECMP routes,
too.
IPv4 does not seem to need this link at all.
> > ipvs caches the dst in its own infrastructure, so we need to be sure we don't
> > disconnect this dst from the ipv6 routing table, otherwise ip6_dst_check won't
> > recognize when relookups should be done. Playing games with RTF_GATEWAY seems
> > dangerous then.
>
> dst_check works for IPVS. There is a problem only
> with the recent changes that moved the indication for PMTU
> change from dst_check to dst_mtu() calls. But this is safe
> for IPVS, it handles FRAG_NEEDED for the tunneling mode itself.
Ok, I see.
> Initially, I thought IPv6 stores zeroes in rt6i_gateway.
> But now I see rt6_alloc_cow() to be called for the case I assumed
> to fail - when no gateway is used.
>
> So, I'll try to test the IPVS case in the following 1-2 days
> and will report after adding some printks. If xt_TEE has
> the same problem then it should not be IPVS-specific. RAW not
> tested yet.
We should provide something similar to what IPv4 does with the
KNOWN_NH flag. I guess my idea with exchanging rt6i_dst as nexthop would
solve this without too much hassle but this would have to be checked by
implementing it.
I don't think that storing a changed nexthop in the ipv6 cb is that nice and
maintainable.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH v4 net-next] openvswitch: fix vport-netdev unregister
From: Jesse Gross @ 2013-10-16 22:31 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Pravin B Shelar, Jiri Pirko, Cong Wang,
dev@openvswitch.org, netdev
In-Reply-To: <1381874051-4175-1-git-send-email-ast@plumgrid.com>
On Tue, Oct 15, 2013 at 2:54 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
> The combination of two commits:
> commit 8e4e1713e4
> ("openvswitch: Simplify datapath locking.")
> commit 2537b4dd0a
> ("openvswitch:: link upper device for port devices")
>
> introduced a bug where upper_dev wasn't unlinked upon
> netdev_unregister notification
>
> The following steps:
>
> modprobe openvswitch
> ovs-dpctl add-dp test
> ip tuntap add dev tap1 mode tap
> ovs-dpctl add-if test tap1
> ip tuntap del dev tap1 mode tap
>
> are causing multiple warnings:
>
> [ 62.747557] gre: GRE over IPv4 demultiplexor driver
> [ 62.749579] openvswitch: Open vSwitch switching datapath
> [ 62.755087] device test entered promiscuous mode
> [ 62.765911] device tap1 entered promiscuous mode
> [ 62.766033] IPv6: ADDRCONF(NETDEV_UP): tap1: link is not ready
> [ 62.769017] ------------[ cut here ]------------
> [ 62.769022] WARNING: CPU: 1 PID: 3267 at net/core/dev.c:5501 rollback_registered_many+0x20f/0x240()
> [ 62.769023] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
> [ 62.769051] CPU: 1 PID: 3267 Comm: ip Not tainted 3.12.0-rc3+ #60
> [ 62.769052] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
> [ 62.769053] 0000000000000009 ffff8807f25cbd28 ffffffff8175e575 0000000000000006
> [ 62.769055] 0000000000000000 ffff8807f25cbd68 ffffffff8105314c ffff8807f25cbd58
> [ 62.769057] ffff8807f2634000 ffff8807f25cbdc8 ffff8807f25cbd88 ffff8807f25cbdc8
> [ 62.769059] Call Trace:
> [ 62.769062] [<ffffffff8175e575>] dump_stack+0x55/0x76
> [ 62.769065] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
> [ 62.769067] [<ffffffff8105319a>] warn_slowpath_null+0x1a/0x20
> [ 62.769069] [<ffffffff8162a04f>] rollback_registered_many+0x20f/0x240
> [ 62.769071] [<ffffffff8162a101>] rollback_registered+0x31/0x40
> [ 62.769073] [<ffffffff8162a488>] unregister_netdevice_queue+0x58/0x90
> [ 62.769075] [<ffffffff8154f900>] __tun_detach+0x140/0x340
> [ 62.769077] [<ffffffff8154fb36>] tun_chr_close+0x36/0x60
> [ 62.769080] [<ffffffff811bddaf>] __fput+0xff/0x260
> [ 62.769082] [<ffffffff811bdf5e>] ____fput+0xe/0x10
> [ 62.769084] [<ffffffff8107b515>] task_work_run+0xb5/0xe0
> [ 62.769087] [<ffffffff810029b9>] do_notify_resume+0x59/0x80
> [ 62.769089] [<ffffffff813a41fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 62.769091] [<ffffffff81770f5a>] int_signal+0x12/0x17
> [ 62.769093] ---[ end trace 838756c62e156ffb ]---
> [ 62.769481] ------------[ cut here ]------------
> [ 62.769485] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
> [ 62.769486] sysfs: can not remove 'master', no directory
> [ 62.769486] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
> [ 62.769514] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
> [ 62.769515] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
> [ 62.769518] Workqueue: events ovs_dp_notify_wq [openvswitch]
> [ 62.769519] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
> [ 62.769521] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b28
> [ 62.769523] 0000000000000000 ffffffff81a87a1f ffff8807f2634000 ffff880037038500
> [ 62.769525] Call Trace:
> [ 62.769528] [<ffffffff8175e575>] dump_stack+0x55/0x76
> [ 62.769529] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
> [ 62.769531] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
> [ 62.769533] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
> [ 62.769535] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
> [ 62.769538] [<ffffffff81631ef7>] __netdev_adjacent_dev_remove+0xf7/0x150
> [ 62.769540] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
> [ 62.769542] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
> [ 62.769544] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
> [ 62.769548] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
> [ 62.769550] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
> [ 62.769552] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
> [ 62.769555] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
> [ 62.769557] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
> [ 62.769559] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
> [ 62.769562] [<ffffffff8107659b>] worker_thread+0x11b/0x370
> [ 62.769564] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
> [ 62.769566] [<ffffffff8107f44a>] kthread+0xea/0xf0
> [ 62.769568] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769570] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
> [ 62.769572] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769573] ---[ end trace 838756c62e156ffc ]---
> [ 62.769574] ------------[ cut here ]------------
> [ 62.769576] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
> [ 62.769577] sysfs: can not remove 'upper_test', no directory
> [ 62.769577] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
> [ 62.769603] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
> [ 62.769604] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
> [ 62.769606] Workqueue: events ovs_dp_notify_wq [openvswitch]
> [ 62.769607] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
> [ 62.769609] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b58
> [ 62.769611] 0000000000000000 ffff880807ad3bd9 ffff8807f2634000 ffff880037038500
> [ 62.769613] Call Trace:
> [ 62.769615] [<ffffffff8175e575>] dump_stack+0x55/0x76
> [ 62.769617] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
> [ 62.769619] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
> [ 62.769621] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
> [ 62.769622] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
> [ 62.769624] [<ffffffff81631f22>] __netdev_adjacent_dev_remove+0x122/0x150
> [ 62.769627] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
> [ 62.769629] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
> [ 62.769631] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
> [ 62.769633] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
> [ 62.769636] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
> [ 62.769638] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
> [ 62.769640] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
> [ 62.769642] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
> [ 62.769644] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
> [ 62.769646] [<ffffffff8107659b>] worker_thread+0x11b/0x370
> [ 62.769648] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
> [ 62.769650] [<ffffffff8107f44a>] kthread+0xea/0xf0
> [ 62.769652] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769654] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
> [ 62.769656] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
> [ 62.769657] ---[ end trace 838756c62e156ffd ]---
> [ 62.769724] device tap1 left promiscuous mode
>
> This patch also affects moving devices between net namespaces.
>
> OVS used to ignore netns move notifications which caused problems.
> Like:
> ovs-dpctl add-if test tap1
> ip link set tap1 netns 3512
> and then removing tap1 inside the namespace will cause hang on missing dev_put.
>
> With this patch OVS will detach dev upon receiving netns move event.
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: Tree for Oct 16 (net/sched/em_ipset.c)
From: Stephen Hemminger @ 2013-10-16 22:39 UTC (permalink / raw)
To: Randy Dunlap, Vitaly Lavrov
Cc: Thierry Reding, linux-next, linux-kernel, Mark Brown,
netdev@vger.kernel.org
In-Reply-To: <525F09B0.4080802@infradead.org>
On Wed, 16 Oct 2013 14:48:32 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/16/13 11:51, Thierry Reding wrote:
> > Hi all,
> >
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> > A next-20131016 tag is also provided for convenience.
> >
> > Gained two new conflicts, but nothing too exciting. x86 and ARM default
> > configurations as well as the x86 allmodconfig mostly build fine on the
> > final tree. There was a failure for the ARM at91x40_defconfig, but the
> > proper fix wasn't immediately obvious to me, so I've left it broken for
> > now.
>
> on i386, when CONFIG_NET_NS is not enabled:
>
> net/sched/em_ipset.c: In function 'em_ipset_change':
> net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
> net/sched/em_ipset.c: In function 'em_ipset_destroy':
> net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
>
>
I think this should fix.
--- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
+++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
@@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
{
struct xt_set_info *set = data;
ip_set_id_t index;
- struct net *net = qdisc_dev(tp->q)->nd_net;
+ struct net *net = dev_net(qdisc_dev(tp->q));
if (data_len != sizeof(*set))
return -EINVAL;
@@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
{
const struct xt_set_info *set = (const void *) em->data;
if (set) {
- ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
+ ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
kfree((void *) em->data);
}
}
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-16 22:50 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks
In-Reply-To: <20131016215953.GD18135@order.stressinduktion.org>
Hello,
On Wed, 16 Oct 2013, Hannes Frederic Sowa wrote:
> To have ip6_dst_check working, there must to be a valid link from
> the rt6_info to the fib6_node. Otherwise we cannot check the serial
> number. As I currently see we also need a link from the fib6_node down
> to the dst entry for resource management. Thus we would have to insert
> the special dst-entry with RTF_GATEWAY and non-null rt6i_gateway back
> into the fib and have it globally visible. This could have unforseen
> side effects. We still cache all dst entries in the fib. One think I
> foresee as a possible problem is the automatic aggregation of ECMP routes,
> too.
I'm still not sure what is needed. Looking at
ip6_pol_route(), I see that everything should just work: for
routes without RTF_GATEWAY flag we return cloned route
from rt6_alloc_cow() with valid rt6i_gateway. I still
didn't tested the problem myself, so I'll stop with the
comments before that.
> We should provide something similar to what IPv4 does with the
> KNOWN_NH flag. I guess my idea with exchanging rt6i_dst as nexthop would
> solve this without too much hassle but this would have to be checked by
> implementing it.
>
> I don't think that storing a changed nexthop in the ipv6 cb is that nice and
> maintainable.
Agreed. I'm not going to test that change. I'll test
latest net-next without any changes to see where exactly is
the failure because the IPv6 routing seems capable for what
we need. I have problems with my setup, so I'll need some
days. As Simon is also testing the problem, he can find the
reason before me.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: Rusty Russell @ 2013-10-16 23:27 UTC (permalink / raw)
To: Jason Wang, mst, virtualization, netdev, linux-kernel; +Cc: Greg Kroah-Hartman
In-Reply-To: <1381807139-3450-1-git-send-email-jasowang@redhat.com>
Jason Wang <jasowang@redhat.com> writes:
> We're trying to re-configure the affinity unconditionally in cpu hotplug
> callback. This may lead the issue during resuming from s3/s4 since
>
> - virt queues haven't been allocated at that time.
> - it's unnecessary since thaw method will re-configure the affinity.
>
> Fix this issue by checking the config_enable and do nothing is we're not ready.
>
> The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> The patch is need for 3.8 and above.
Please put 'CC: stable@kernel.org # 3.8+' in the commit.
(The specification of the stable line is poor, but that seems to be one
common method).
Cheers,
Rusty.
^ permalink raw reply
* Re: transmit lockup using smsc95xx ethernet on usb3
From: Sarah Sharp @ 2013-10-17 0:07 UTC (permalink / raw)
To: David Laight
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Xenia Ragiadakou
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B738B-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On Tue, Oct 15, 2013 at 10:59:18AM +0100, David Laight wrote:
> We are seeing complete lockups of the transmit side when using
> the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu.
> These errors are very intermittent - less than once a day, and
> it isn't actually clear that they are related to traffic load.
>
> Most of the systems are running the 3.2 kernel from Ubuntu 12.04
> but I've seen the same problem when running a 3.4 kernel.
Have you tried the latest stable kernel or the latest -rc kernel?
> Looking at the changelog for xhci-ring.c I can see that some
> 'nasty' bugs were fixed between 3.2 and 3.4 (and possibly since)
> but the usbmon trace I've now got doesn't seem to match any
> of the changelog entries.
>
> We are also seeing similar problems if we connect to a USB2
> header.
Do you mean a USB 2.0 port under the xHCI host controller? What does
`lsusb -t` show as the parent host controller in that case?
> Since we can't reproduce the problem quickly it is difficult to
> do any analysis. Any suggestions for increasing the error rate
> would be welcome.
>
> Below is an annotated extract from a usbmon trace while running
> a netperf test that was sending 8192 byte TCP packets (nagle off).
> I've deleted the Bi entries (packets are received throughout)
> and numbered all the others (modulo 10000) so it is easier to
> see when the requests complete, I've also calculated the elapsed
> time and the number of Setup entries between the S and C traces.
>
> The USB ring seems to have 60 outstanding transmits in it,
> each time one completes another is sent. There are a few 10000
> traces of that then:
>
> start:9870 ffff88020ea16000 293811125 S Bo:3:003:2 -115 1514 =
> e2350000 e2450000 22003200 00224d98
> d8460002 1f0057d7 08004500 05d0ff11
> done:9811:6969:60 ffff88020c7c8000 293811236 C Bo:3:003:2 0 1090 >
> start:9871 ffff88020ea16a80 293811242 S Bo:3:003:2 -115 1090 =
> 3a340000 3a440000 22003200 00224d98
> d8460002 1f0057d7 08004500 0428ff12
> ...
> start:9929 ffff88020ea16780 293817964 S Bo:3:003:2 -115 1514 =
> e2350000 e2450000 22003200 00224d98
> d8460002 1f0057d7 08004500 05d0ff4c
> Last successful completion.
> done:9870:6968:60 ffff88020ea16000 293818093 C Bo:3:003:2 0 1514 >
> start:9930 ffff88020ea16000 293818099 S Bo:3:003:2 -115 1514 =
> e2350000 e2450000 22003200 00224d98
> d8460002 1f0057d7 08004500 05d0ff4d
>
> At this point something (untraced) seems to have gone horribly
> wrong in the transmit ring. dmesg shows nothing.
> Two Bo 'fail -71', 6 succeed, one fails -32 the rest fail -104.
> done:9871:6913:60 ffff88020ea16a80 293818155 C Bo:3:003:2 -71 512 >
> done:9872:6927:59 ffff88020ea16f00 293818235 C Bo:3:003:2 -71 0
> done:9873:6875:58 ffff88020ea16480 293818313 C Bo:3:003:2 0 1514 >
> done:9874:6786:57 ffff88020c7c83c0 293818353 C Bo:3:003:2 0 1514 >
> done:9875:6794:56 ffff88020c7c80c0 293818470 C Bo:3:003:2 0 1514 >
> done:9876:6789:55 ffff88020c7c8e40 293818589 C Bo:3:003:2 0 1514 >
> done:9877:6775:54 ffff88020c7c8240 293818702 C Bo:3:003:2 0 1090 >
> done:9878:6751:53 ffff88020c7c8180 293818803 C Bo:3:003:2 0 1514 >
> done:9879:6735:52 ffff88020c7c89c0 293818885 C Bo:3:003:2 -32 0
> done:9880:6671:51 ffff88020c7c8900 293818925 C Bo:3:003:2 -104 0
> ...
> done:9927:1292:4 ffff88020cf0c480 293819015 C Bo:3:003:2 -104 0
> done:9928:1170:3 ffff88020ea160c0 293819016 C Bo:3:003:2 -104 0
> Something is known to be wrong...
> start:9931 ffff88020ea160c0 293819037 S Co:3:003:0
> s 02 01 0000 0002 0000 0
> done:9929:1080:3 ffff88020ea16780 293819044 C Bo:3:003:2 -104 0
> done:9930:945:2 ffff88020ea16000 293819044 C Bo:3:003:2 -104 0
> done:9931:48:1 ffff88020ea160c0 293819085 C Co:3:003:0 0 0
>
> These 10 transmits never finish:
> start:9932 ffff88020ea160c0 293819098 S Bo:3:003:2 -115 1090 =
> 3a340000 3a440000 22003200 00224d98
> d8460002 1f0057d7 08004500 0428ff4e
> ... 9933 to 9940 deleted
> start:9941 ffff88020ea16b40 293819111 S Bo:3:003:2 -115 1514 =
> e2350000 e2450000 22003200 00224d98
> d8460002 1f0057d7 08004500 05d0ff57
>
> All further transmits fail immediately E -12 and generate the
> 'xhci_hcd 0000:00:14.0: ERROR no room on ep ring' message.
> (There are 1070 'E' traces and 1070 'no room' messages.)
> Receives are still working.
> start:9942 ffff88020ea16240 293819113 S Bo:3:003:2 -115 1514 =
> e2350000 e2450000 22003200 00224d98
> d8460002 1f0057d7 08004500 05d0ff58
> done:9942:1550:1 ffff88020ea16240 293820663 E Bo:3:003:2 -12 0
> start:9943 ffff88020ea16240 293820675 S Bo:3:003:2 -115 1514 =
> e2350000 e2450000 22003200 00224d98
> d8460002 1f0057d7 08004500 05d0ff59
> done:9943:1507:1 ffff88020ea16240 293822182 E Bo:3:003:2 -12 0
>
> Eventually something causes a device remove and insert - everything re-initialises.
> This is over 12 hours later.
> done:unknown ffff88020c8570c0 3637139297 C Ii:3:001:1 0:2048 1 = 02
> start:1015 ffff88020c8570c0 3637139302 S Ii:3:001:1 -115:2048 4 <
> start:1016 ffff88020cbeb300 3637139323 S Ci:3:001:0
> s a3 00 0000 0001 0004 4 <
> ffff88020ea16240 3637139331 C Bi:3:003:1 -71 0
> done:1016:9:1 ffff88020cbeb300 3637139332 C Ci:3:001:0 0 4 = 00010100
> start:1017 ffff88020cbeb300 3637139334 S Co:3:001:0
> s 23 01 0010 0001 0000 0
> done:1017:4:1 ffff88020cbeb300 3637139338 C Co:3:001:0 0 0
> done:unknown ffff88020ca9ae40 3637139423 C Ii:3:003:3 -71:1 0
> ffff88020c9db540 3637139428 C Bi:3:003:1 -108 0
> ffff88020c9db780 3637139430 C Bi:3:003:1 -108 0
> ffff88020d8bb540 3637139431 C Bi:3:003:1 -108 0
>
> The last 10 transmits then terminate with error -108:
> done:9932:xxxx ffff88020ea160c0 3637139462 C Bo:3:003:2 -108 0
> ... 9933 to 9940 deleted
> done:9941:xxxx ffff88020ea16b40 3637139482 C Bo:3:003:2 -108 0
> done:1015:21090:3 ffff88020c8570c0 3637160392 C Ii:3:001:1 0:2048 1 = 02
> start:1018 ffff88020c8570c0 3637160396 S Ii:3:001:1 -115:2048 4 <
> done:unknown ffff88020cbf26c0 3637176790 C Ii:3:005:1 -108:8 0
> done:unknown ffff88020c68aa80 3637622497 C Ii:3:002:1 -108:2048 0
>
> Followed by lots of Ci/Co and eventually it all starts working again.
>
> I've not yet tried to look up the control transfers.
>
> These aren't the only errors we are seeing, we also see (separately):
> [21549.917529] hub 3-2:1.0: port 1 disabled by hub (EMI?), re-enabling...
> [ 5822.629579] NETDEV WATCHDOG: eth0 (smsc95xx): transmit queue 0 timed out
> [ 7263.834404] hid-generic 0003:413C:2005.0002: can't reset device, 0000:00:1a.0-1.4.3/input0, status -71 (connected to a USB2 header).
> These all cause a USB bus reset and everything recovers within a couple of seconds.
I would suggest you try with the latest stable kernel, with
CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled. If you try
the latest 3.12-rc, you will only need the CONFIG_USB_DEBUG. Or, if
that output is too much (it will spew on short packets, which may be an
issue with your ethernet adapter), with the 3.12-rc kernel, you can turn
off CONFIG_USB_DEBUG and capture command trace events through the xHCI
trace infrastructure. Xenia can help you with that if necessary (I'm
going to be at a conference starting Friday).
Without that dmesg, I really can't tell what's happening at an xHCI
level.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: linux-next: Tree for Oct 16 (net/sched/em_ipset.c)
From: Randy Dunlap @ 2013-10-17 0:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Vitaly Lavrov, Thierry Reding, linux-next, linux-kernel,
Mark Brown, netdev@vger.kernel.org
In-Reply-To: <20131016153949.5f2257b4@nehalam.linuxnetplumber.net>
On 10/16/13 15:39, Stephen Hemminger wrote:
> On Wed, 16 Oct 2013 14:48:32 -0700
> Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> On 10/16/13 11:51, Thierry Reding wrote:
>>> Hi all,
>>>
>>> I've uploaded today's linux-next tree to the master branch of the
>>> repository below:
>>>
>>> git://gitorious.org/thierryreding/linux-next.git
>>>
>>> A next-20131016 tag is also provided for convenience.
>>>
>>> Gained two new conflicts, but nothing too exciting. x86 and ARM default
>>> configurations as well as the x86 allmodconfig mostly build fine on the
>>> final tree. There was a failure for the ARM at91x40_defconfig, but the
>>> proper fix wasn't immediately obvious to me, so I've left it broken for
>>> now.
>>
>> on i386, when CONFIG_NET_NS is not enabled:
>>
>> net/sched/em_ipset.c: In function 'em_ipset_change':
>> net/sched/em_ipset.c:27:36: error: 'struct net_device' has no member named 'nd_net'
>> net/sched/em_ipset.c: In function 'em_ipset_destroy':
>> net/sched/em_ipset.c:49:34: error: 'struct net_device' has no member named 'nd_net'
>>
>>
>
> I think this should fix.
>
That works. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
>
> --- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
> +++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
> @@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
> {
> struct xt_set_info *set = data;
> ip_set_id_t index;
> - struct net *net = qdisc_dev(tp->q)->nd_net;
> + struct net *net = dev_net(qdisc_dev(tp->q));
>
> if (data_len != sizeof(*set))
> return -EINVAL;
> @@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
> {
> const struct xt_set_info *set = (const void *) em->data;
> if (set) {
> - ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
> + ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
> kfree((void *) em->data);
> }
> }
> --
--
~Randy
^ permalink raw reply
* [PATCH net-next] em_ipset: use dev_net() accessor
From: Stephen Hemminger @ 2013-10-17 0:29 UTC (permalink / raw)
To: Randy Dunlap, David Miller
Cc: Vitaly Lavrov, Thierry Reding, linux-next, linux-kernel,
Mark Brown, netdev@vger.kernel.org, Jamal Hadi Salim
In-Reply-To: <525F2D7D.7010708@infradead.org>
Randy found that if network namespace not enabled then
nd_net does not exist and would cause compilation failure.
This is handled correctly by using the dev_net() macro.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
--- a/net/sched/em_ipset.c 2013-10-06 14:48:25.030449222 -0700
+++ b/net/sched/em_ipset.c 2013-10-16 15:38:05.030278287 -0700
@@ -24,7 +24,7 @@ static int em_ipset_change(struct tcf_pr
{
struct xt_set_info *set = data;
ip_set_id_t index;
- struct net *net = qdisc_dev(tp->q)->nd_net;
+ struct net *net = dev_net(qdisc_dev(tp->q));
if (data_len != sizeof(*set))
return -EINVAL;
@@ -46,7 +46,7 @@ static void em_ipset_destroy(struct tcf_
{
const struct xt_set_info *set = (const void *) em->data;
if (set) {
- ip_set_nfnl_put(qdisc_dev(p->q)->nd_net, set->index);
+ ip_set_nfnl_put(dev_net(qdisc_dev(p->q)), set->index);
kfree((void *) em->data);
}
}
^ permalink raw reply
* [PATCH] drivers: net: wireless: b43: Fix possible NULL ptr dereference
From: Felipe Pena @ 2013-10-17 0:40 UTC (permalink / raw)
To: Stefano Brivio, John W. Linville
Cc: linux-wireless, b43-dev, netdev, linux-kernel, Felipe Pena
On the ternary expression the 'e' variable could be NULL dereferenced,
when b43_nphy_get_rf_ctl_over_rev7 function returns NULL.
Signed-off-by: Felipe Pena <felipensp@gmail.com>
---
drivers/net/wireless/b43/phy_n.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 7c970d3..05ee7f1 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -164,7 +164,8 @@ static void b43_nphy_rf_ctl_override_rev7(struct b43_wldev *dev, u16 field,
}
en_addr = en_addrs[override][i];
- val_addr = (i == 0) ? e->val_addr_core0 : e->val_addr_core1;
+ if (e)
+ val_addr = (i == 0) ? e->val_addr_core0 : e->val_addr_core1;
if (off) {
b43_phy_mask(dev, en_addr, ~en_mask);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/3] ipvs: avoid rcu_barrier during netns cleanup
From: Simon Horman @ 2013-10-17 0:49 UTC (permalink / raw)
To: Julian Anastasov
Cc: Pablo Neira Ayuso, lvs-devel, netdev, netfilter-devel,
Wensong Zhang
In-Reply-To: <alpine.LFD.2.03.1310162231380.1917@ssi.bg>
On Wed, Oct 16, 2013 at 10:52:14PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 16 Oct 2013, Pablo Neira Ayuso wrote:
>
> > I can enqueue this fix to nf if you like. No need to resend, I can
> > manually apply.
> >
> > Let me know.
>
> It is not critical. I waited weeks the net tree to be
> copied into net-next because it collides with the recent
> "ipvs: make the service replacement more robust" change in
> net tree :) But if a rcu_barrier in the netns cleanup looks
> scary enough you can push it to nf. IMHO, it just adds
> unneeded delay there.
If it is not critical I would prefer for it to travel through
nf-next. Though I do not feel strongly about this.
^ permalink raw reply
* Re: [PATCH v2.43 0/5] MPLS actions and matches
From: Simon Horman @ 2013-10-17 0:56 UTC (permalink / raw)
To: Ben Pfaff
Cc: Jesse Gross, dev@openvswitch.org, netdev, Pravin B Shelar, Ravi K,
Isaku Yamahata, Joe Stringer
In-Reply-To: <20131016204743.GB4526@nicira.com>
On Wed, Oct 16, 2013 at 01:47:43PM -0700, Ben Pfaff wrote:
> On Wed, Oct 16, 2013 at 01:21:22PM -0700, Jesse Gross wrote:
> > On Tue, Oct 15, 2013 at 8:55 PM, Ben Pfaff <blp@nicira.com> wrote:
> > > On Thu, Oct 10, 2013 at 09:31:41AM +0900, Simon Horman wrote:
> > >> I believe this series addresses the feedback that each of you
> > >> gave with regards to recent previous postings of this patch-set.
> > >> I'm wondering if you could find some time to review it.
> > >
> > > I'm waiting for an ack from Jesse, then I'm going to do a final pass and
> > > I hope to commit this series at this point. I see some ways that we can
> > > improve MPLS support afterward but I don't see any blockers.
> >
> > I guess that we had a deadlock as I was waiting for you. I though that
> > maybe you would commit the rest of the userspace patches and then I
> > would just pick up the last two.
>
> Ah, OK.
>
> I will do this, then, after a final pass.
I have noticed a minor problem in the first patch of v2.43
and I have also noticed that it no longer applies on top of master.
I have prepared v2.44 and will send it shortly.
^ permalink raw reply
* [PATCH v2.44 3/5] lib: Support pushing of MPLS LSE before or after VLAN tag
From: Simon Horman @ 2013-10-17 1:15 UTC (permalink / raw)
To: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
Jesse Gross, Ben Pfaff
Cc: Isaku Yamahata, Ravi K
In-Reply-To: <1381972511-27221-1-git-send-email-horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
From: Joe Stringer <joe-Q1GJJQv1iO6lP80pJB477g@public.gmane.org>
This patch modifies the push_mpls behaviour to allow
pushing of an MPLS LSE either before any VLAN tag that may be present.
Pushing the MPLS LSE before any VLAN tag that is present is the
behaviour specified in OpenFlow 1.3.
Pushing the MPLS LSE after the any VLAN tag that is present is the
behaviour specified in OpenFlow 1.1 and 1.2. This is the only behaviour
that was supported prior to this patch.
When an push_mpls action has been inserted using OpenFlow 1.2 or earlier
the behaviour of pushing the MPLS LSE before any VLAN tag that may be
present is implemented by by inserting VLAN actions around the MPLS push
action during odp translation; Pop VLAN tags before committing MPLS
actions, and push the expected VLAN tag afterwards.
The trigger condition for the two different behaviours is the value of the
mpls_before_vlan field of struct ofpact_push_mpls. This field is set when
parsing OpenFlow actions.
Signed-off-by: Joe Stringer <joe-Q1GJJQv1iO6lP80pJB477g@public.gmane.org>
Signed-off-by: Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
---
v2.44
* No change
v2.43 [Simon Horman]
* Trivial rebase as the result of replacing 'mpls_before_vlan' field
of struct ofpact_push_mpls with a 'position' field.
v2.42
* No change
v2.41 [Simon Horman]
* Use 'mpls_before_vlan' field of struct ofpact_push_mpls.
* Reword changelog to describe the difference in behaviour between
different Open Flow versions.
v2.40 [Simon Horman]
* Trivial rebase for removal of set_ethertype()
v2.36 - v2.39
* No change
v2.35 [Joe Stringer]
* First post
---
lib/flow.c | 2 +-
lib/packets.c | 10 +-
lib/packets.h | 2 +-
ofproto/ofproto-dpif-xlate.c | 27 ++---
tests/ofproto-dpif.at | 237 +++++++++++++++++++++++++++++++++++++++++++
5 files changed, 259 insertions(+), 19 deletions(-)
diff --git a/lib/flow.c b/lib/flow.c
index 0678c6f..6242ef9 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -1061,7 +1061,7 @@ flow_compose(struct ofpbuf *b, const struct flow *flow)
}
if (eth_type_mpls(flow->dl_type)) {
- b->l2_5 = b->l3;
+ b->l2_5 = (char*)b->l2 + ETH_HEADER_LEN;
push_mpls(b, flow->dl_type, flow->mpls_lse);
}
}
diff --git a/lib/packets.c b/lib/packets.c
index 922c5db..f8a58b6 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -220,11 +220,11 @@ eth_pop_vlan(struct ofpbuf *packet)
/* Set ethertype of the packet. */
void
-set_ethertype(struct ofpbuf *packet, ovs_be16 eth_type)
+set_ethertype(struct ofpbuf *packet, ovs_be16 eth_type, bool inner)
{
struct eth_header *eh = packet->data;
- if (eh->eth_type == htons(ETH_TYPE_VLAN)) {
+ if (inner && eh->eth_type == htons(ETH_TYPE_VLAN)) {
ovs_be16 *p;
p = ALIGNED_CAST(ovs_be16 *,
(char *)(packet->l2_5 ? packet->l2_5 : packet->l3) - 2);
@@ -332,8 +332,8 @@ push_mpls(struct ofpbuf *packet, ovs_be16 ethtype, ovs_be32 lse)
if (!is_mpls(packet)) {
/* Set ethtype and MPLS label stack entry. */
- set_ethertype(packet, ethtype);
- packet->l2_5 = packet->l3;
+ set_ethertype(packet, ethtype, false);
+ packet->l2_5 = (char*)packet->l2 + ETH_HEADER_LEN;
}
/* Push new MPLS shim header onto packet. */
@@ -354,7 +354,7 @@ pop_mpls(struct ofpbuf *packet, ovs_be16 ethtype)
size_t len;
mh = packet->l2_5;
len = (char*)packet->l2_5 - (char*)packet->l2;
- set_ethertype(packet, ethtype);
+ set_ethertype(packet, ethtype, true);
if (mh->mpls_lse & htonl(MPLS_BOS_MASK)) {
packet->l2_5 = NULL;
} else {
diff --git a/lib/packets.h b/lib/packets.h
index 7388152..38fec70 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -143,7 +143,7 @@ void compose_rarp(struct ofpbuf *, const uint8_t eth_src[ETH_ADDR_LEN]);
void eth_push_vlan(struct ofpbuf *, ovs_be16 tci);
void eth_pop_vlan(struct ofpbuf *);
-void set_ethertype(struct ofpbuf *packet, ovs_be16 eth_type);
+void set_ethertype(struct ofpbuf *packet, ovs_be16 eth_type, bool inner);
const char *eth_from_hex(const char *hex, struct ofpbuf **packetp);
void eth_format_masked(const uint8_t eth[ETH_ADDR_LEN],
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 3a71ba8..14fd037 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -2494,24 +2494,27 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
break;
}
- case OFPACT_PUSH_MPLS:
- if (compose_mpls_push_action(ctx,
- ofpact_get_PUSH_MPLS(a)->ethertype)) {
+ case OFPACT_PUSH_MPLS: {
+ struct ofpact_push_mpls *oam = ofpact_get_PUSH_MPLS(a);
+
+ if (compose_mpls_push_action(ctx, oam->ethertype)) {
return;
}
- /* Save and pop any existing VLAN tags. They will be pushed
- * back onto the packet after pushing the MPLS LSE. The overall
- * effect is to push the MPLS LSE after any VLAN tags that may
- * be present. This is the behaviour described for OpenFlow 1.1
- * and 1.2. This code needs to be enhanced to make this
- * conditional to also and support pushing the MPLS LSE before
- * any VLAN tags that may be present, the behaviour described
- * for OpenFlow 1.3. */
+ /* Save and pop any existing VLAN tags if the MPLS LSE should
+ * be pushed after VLAN tags. The overall effect is to push
+ * the MPLS LSE after any VLAN tags that may be present. This
+ * is the behaviour described for OpenFlow 1.1 and 1.2.
+ * Do not save and therefore pop the VLAN tags if the MPLS LSE
+ * should be pushed before any VLAN tags that are present.
+ * This is the behaviour described for OpenFlow 1.3. */
ctx->final_vlan_tci = *ctx->next_vlan_tci;
- flow->vlan_tci = htons(0);
+ if (oam->position == OFPACT_MPLS_AFTER_VLAN) {
+ flow->vlan_tci = htons(0);
+ }
ctx->next_vlan_tci = &ctx->final_vlan_tci;
break;
+ }
case OFPACT_POP_MPLS:
if (compose_mpls_pop_action(ctx,
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index bc9bcf4..6b2072b 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -1174,6 +1174,243 @@ NXST_FLOW reply:
OVS_VSWITCHD_STOP
AT_CLEANUP
+AT_SETUP([ofproto-dpif - OF1.3+ VLAN+MPLS handling])
+OVS_VSWITCHD_START([dnl
+ add-port br0 p1 -- set Interface p1 type=dummy
+])
+ON_EXIT([kill `cat ovs-ofctl.pid`])
+
+AT_CAPTURE_FILE([ofctl_monitor.log])
+AT_DATA([flows.txt], [dnl
+cookie=0xa dl_src=40:44:44:44:55:44 actions=push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],controller
+cookie=0xa dl_src=40:44:44:44:55:45 actions=push_vlan:0x8100,mod_vlan_vid:99,push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],controller
+cookie=0xa dl_src=40:44:44:44:55:46 actions=push_vlan:0x8100,mod_vlan_vid:99,push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],controller
+cookie=0xa dl_src=40:44:44:44:55:47 actions=push_vlan:0x8100,load:99->OXM_OF_VLAN_VID[[]],push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],controller
+cookie=0xa dl_src=40:44:44:44:55:48 actions=push_vlan:0x8100,load:99->OXM_OF_VLAN_VID[[]],push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],controller
+cookie=0xa dl_src=40:44:44:44:55:49 actions=push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],push_vlan:0x8100,mod_vlan_vid:99,controller
+cookie=0xa dl_src=40:44:44:44:55:50 actions=push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],push_vlan:0x8100,mod_vlan_vid:99,controller
+cookie=0xa dl_src=40:44:44:44:55:51 actions=push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],push_vlan:0x8100,load:99->OXM_OF_VLAN_VID[[]],mod_vlan_pcp:1,controller
+cookie=0xa dl_src=40:44:44:44:55:52 actions=push_mpls:0x8847,load:10->OXM_OF_MPLS_LABEL[[]],load:3->OXM_OF_MPLS_TC[[]],push_vlan:0x8100,load:99->OXM_OF_VLAN_VID[[]],mod_vlan_pcp:1,controller
+])
+AT_CHECK([ovs-ofctl --protocols=OpenFlow13 add-flows br0 flows.txt])
+
+dnl Modified MPLS controller action.
+dnl The input packet has a VLAN tag, but because we push an MPLS tag in
+dnl OF1.3 mode, we can no longer see it.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:44,dst=50:54:00:00:00:07),eth_type(0x8100),vlan(vid=88,pcp=7),encap(eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no))'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:44,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:44,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:44,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, we push a VLAN tag, then an MPLS tag in OF1.3 mode, so we
+dnl can only see the MPLS tag in the result.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:45,dst=50:54:00:00:00:07),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no)'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:45,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:45,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:45,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, the input packet is vlan-tagged; we update this tag then
+dnl push an MPLS tag in OF1.3 mode. As such, we can only see the MPLS tag in
+dnl the result.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:46,dst=50:54:00:00:00:07),eth_type(0x8100),vlan(vid=88,pcp=7),encap(eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no))'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:46,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:46,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:46,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, we push a VLAN tag, then an MPLS tag in OF1.3 mode, so we
+dnl can only see the MPLS tag in the result.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:47,dst=50:54:00:00:00:07),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no)'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:47,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:47,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:47,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, the input packet is vlan-tagged; we update this tag then
+dnl push an MPLS tag in OF1.3 mode. As such, we can only see the MPLS tag in
+dnl the result.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:48,dst=50:54:00:00:00:07),eth_type(0x8100),vlan(vid=88,pcp=7),encap(eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no))'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:48,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:48,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=64 in_port=1 (via action) data_len=64 (unbuffered)
+mpls,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=40:44:44:44:55:48,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, we push the MPLS tag before pushing a VLAN tag, so we see
+dnl both of these in the final flow.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:49,dst=50:54:00:00:00:07),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no)'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=0,dl_src=40:44:44:44:55:49,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=0,dl_src=40:44:44:44:55:49,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=0,dl_src=40:44:44:44:55:49,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, the input packet in vlan-tagged, which should be stripped
+dnl before we push the MPLS and VLAN tags.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:50,dst=50:54:00:00:00:07),eth_type(0x8100),vlan(vid=88,pcp=7),encap(eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no))'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=0,dl_src=40:44:44:44:55:50,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=0,dl_src=40:44:44:44:55:50,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=0,dl_src=40:44:44:44:55:50,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, we push the MPLS tag before pushing a VLAN tag, so we see
+dnl both of these in the final flow.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:51,dst=50:54:00:00:00:07),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no)'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=1,dl_src=40:44:44:44:55:51,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=1,dl_src=40:44:44:44:55:51,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=1,dl_src=40:44:44:44:55:51,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+dnl Modified MPLS controller action.
+dnl In this test, the input packet in vlan-tagged, which should be stripped
+dnl before we push the MPLS and VLAN tags.
+AT_CHECK([ovs-ofctl monitor br0 65534 -P nxm --detach --pidfile 2> ofctl_monitor.log])
+
+for i in 1 2 3; do
+ ovs-appctl netdev-dummy/receive p1 'in_port(1),eth(src=40:44:44:44:55:52,dst=50:54:00:00:00:07),eth_type(0x8100),vlan(vid=88,pcp=7),encap(eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=0,ttl=64,frag=no))'
+done
+OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 6])
+ovs-appctl -t ovs-ofctl exit
+
+AT_CHECK([cat ofctl_monitor.log], [0], [dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=1,dl_src=40:44:44:44:55:52,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=1,dl_src=40:44:44:44:55:52,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+dnl
+NXT_PACKET_IN (xid=0x0): cookie=0xa total_len=68 in_port=1 (via action) data_len=68 (unbuffered)
+mpls,metadata=0,in_port=0,dl_vlan=99,dl_vlan_pcp=1,dl_src=40:44:44:44:55:52,dl_dst=50:54:00:00:00:07,mpls_label=10,mpls_tc=3,mpls_ttl=64,mpls_bos=1
+])
+
+AT_CHECK([ovs-appctl time/warp 5000], [0], [ignore])
+AT_CHECK([ovs-ofctl dump-flows br0 | ofctl_strip | sort], [0], [dnl
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:44 actions=push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:45 actions=mod_vlan_vid:99,push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:46 actions=mod_vlan_vid:99,push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:47 actions=load:0x63->OXM_OF_VLAN_VID[[]],push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:48 actions=load:0x63->OXM_OF_VLAN_VID[[]],push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:49 actions=push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],mod_vlan_vid:99,CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:50 actions=push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],mod_vlan_vid:99,CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:51 actions=push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],load:0x63->OXM_OF_VLAN_VID[[]],mod_vlan_pcp:1,CONTROLLER:65535
+ cookie=0xa, n_packets=3, n_bytes=180, dl_src=40:44:44:44:55:52 actions=push_mpls:0x8847,load:0xa->OXM_OF_MPLS_LABEL[[]],load:0x3->OXM_OF_MPLS_TC[[]],load:0x63->OXM_OF_VLAN_VID[[]],mod_vlan_pcp:1,CONTROLLER:65535
+NXST_FLOW reply:
+])
+
+OVS_VSWITCHD_STOP
+AT_CLEANUP
+
AT_SETUP([ofproto-dpif - fragment handling])
OVS_VSWITCHD_START
ADD_OF_PORTS([br0], [1], [2], [3], [4], [5], [6], [90])
--
1.8.4
^ permalink raw reply related
* [PATCH v2.44 4/5] datapath: Break out deacceleration portion of vlan_push
From: Simon Horman @ 2013-10-17 1:15 UTC (permalink / raw)
To: dev, netdev, Jesse Gross, Ben Pfaff
Cc: Pravin B Shelar, Ravi K, Isaku Yamahata, Joe Stringer
In-Reply-To: <1381972511-27221-1-git-send-email-horms@verge.net.au>
Break out deacceleration portion of vlan_push into vlan_put
so that it may be re-used by mpls_push.
For both vlan_push and mpls_push if there is an accelerated VLAN tag
present then it should be deaccelerated, adding it to the data of
the skb, before the new tag is added.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
v2.41 - v2.44
* No change
v2.40
* As suggested by Jesse Gross
+ Simplify vlan_push by returning an error code
rather than an error code encoded as a struct xkb_buff *
v2.39
* First post
---
datapath/actions.c | 29 +++++++++++++++++++----------
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/datapath/actions.c b/datapath/actions.c
index 30ea1d2..d961e5d 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -105,22 +105,31 @@ static int pop_vlan(struct sk_buff *skb)
return 0;
}
-static int push_vlan(struct sk_buff *skb, const struct ovs_action_push_vlan *vlan)
+/* push down current VLAN tag */
+static int put_vlan(struct sk_buff *skb)
{
- if (unlikely(vlan_tx_tag_present(skb))) {
- u16 current_tag;
+ u16 current_tag = vlan_tx_tag_get(skb);
- /* push down current VLAN tag */
- current_tag = vlan_tx_tag_get(skb);
+ if (!__vlan_put_tag(skb, skb->vlan_proto, current_tag))
+ return -ENOMEM;
- if (!__vlan_put_tag(skb, skb->vlan_proto, current_tag))
- return -ENOMEM;
+ if (skb->ip_summed == CHECKSUM_COMPLETE)
+ skb->csum = csum_add(skb->csum, csum_partial(skb->data
+ + (2 * ETH_ALEN), VLAN_HLEN, 0));
- if (skb->ip_summed == CHECKSUM_COMPLETE)
- skb->csum = csum_add(skb->csum, csum_partial(skb->data
- + (2 * ETH_ALEN), VLAN_HLEN, 0));
+ return 0;
+}
+static int push_vlan(struct sk_buff *skb, const struct ovs_action_push_vlan *vlan)
+{
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ int err;
+
+ err = put_vlan(skb);
+ if (unlikely(err))
+ return err;
}
+
__vlan_hwaccel_put_tag(skb, vlan->vlan_tpid, ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
return 0;
}
--
1.8.4
^ permalink raw reply related
* [PATCH v2.44 0/5] MPLS actions and matches
From: Simon Horman @ 2013-10-17 1:15 UTC (permalink / raw)
To: dev, netdev, Jesse Gross, Ben Pfaff
Cc: Pravin B Shelar, Ravi K, Isaku Yamahata, Joe Stringer
Hi,
This series implements MPLS actions and matches based on work by
Ravi K, Leo Alterman, Yamahata-san and Joe Stringer.
This series provides two changes
* Patches 1 - 3
Provide user-space support for the VLAN/MPLS tag insertion order
up to and including OpenFlow 1.2, and the different ordering
specified from OpenFlow 1.3. In a nutshell the datapath always
uses the OpenFlow 1.3 ordering, which is to always insert tags
immediately after the L2 header, regardless of the presence of other
tags. And ovs-vswtichd provides compatibility for the behaviour up
to OpenFlow 1.2, which is that MPLS tags should follow VLAN tags
if present.
Patch 1 has been updated since v3.43.
Patches 2 and 3 were last updated in v2.42.
Ben, these are for you to review.
* Patches 4 and 5
Adding basic MPLS action and match support to the kernel datapath
These patches were last updated in v2.41.
Jesse, these are for you to review.
Differences between v2.44 and v2.43:
* Rebase for the following changes:
f47ea02 ("Set datapath mask bits when setting a flow field.")
7fdb60a ("Add support for write-actions")
7358063 ("odp-util: Elaborate the comment for odp_flow_format() function.")
* Correct final_vlan_tci and next_vlan_tci initialisation in xlate_actions__()
Differences between v2.43 and v2.42:
* As suggested by Ben Pfaff
Move vlan state into struct xlate_ctx
1. Add final_vlan_tci member to struct xlate_ctx instead of vlan_tci member
struct xlate_xin. This seems to be a better palace for it as it does
not need to be accessible from the caller.
2. Move local vlan_tci variable of do_xlate_actions() to be the
next_vlan_tci member of strict xlate_ctx. This allows for it to work
across resubmit actions and goto table instructions.
* Code contributed by Ben Pfaff
+ Use enum for to control order of MPLS LSE insertion
This makes the logic somewhat clearer
* Add a helper push_mpls_from_openflow() to consolidate
the same logic that appears in three locations.
Differences between v2.42 and v2.41:
* Rebase for:
+ 0585f7a ("datapath: Simplify mega-flow APIs.")
+ a097c0b ("datapath: Restructure datapath.c and flow.c")
* As suggested by Jesse Gross
+ Take into account that push_mpls() will have freed the skb on error
+ Remove dubious !eth_p_mpls(skb->protocol) condition from push_mpls
The !eth_p_mpls(skb->protocol) condition on setting inner_protocol
has no effect. Its motivation was to ensure that inner_protocol was
only set the first time that mpls_push occured. However this is already
ensured by the !ovs_skb_get_inner_protocol(skb) condition.
+ Return -EINVAL instead of -ENOMEM from pop_mpls() if the skb is too short
+ Do not add @inner_protocol to kernel doc for struct ovs_skb_cb.
The patch no longer adds an inner_protocol member to struct ovs_skb_cb
+ Do not add and set otherwise unsued inner_protocol variable in
rpl_dev_queue_xmit()
* As suggested by Pravin Shelar
+ Implement compatibility code in existing rpl_skb_gso_segment
rather than introducing to use rpl___skb_gso_segment
Differences between v2.41 and v2.40:
* As suggested by Ben Pfaff
+ Expand struct ofpact_reg_load to include a mpls_before_vlan field
rather than using the compat field of the ofpact field of
struct ofpact_reg_load.
+ Pass version to ofpacts_pull_openflow11_actions and
ofpacts_pull_openflow11_instructions. This removes the invalid
assumption that that these functions are passed a full message and are
thus able to deduce the OpenFlow version.
Differences between v2.40 and v2.39:
* Rebase for:
+ New dev_queue_xmit compat code
+ Updated put_vlan()
+ Removal of mpls_depth field from struct flow
* As suggested by Jesse Gross
+ Remove bogus mac_len update from push_mpls()
+ Slightly simplify push_mpls() by using eth_hdr()
+ Remove dubious condition !eth_p_mpls(inner_protocol) on
an skb being considered to be MPLS in netdev_send()
+ Only use compatibility code for MPLS GSO segmentation on kernels
older than 3.11
+ Revamp setting of inner_protocol
1. Do not unconditionally set inner_protocol to the value of
skb->protocol in ovs_execute_actions().
2. Initialise inner_protocol it to zero only if compatibility code is in
use. In the case where compatibility code is not in use it will either
be zero due since the allocation of the skb or some other value set
by some other user.
3. Conditionally set the inner_protocol in push_mpls() to the value of
skb->protocol when entering push_mpls(). The condition is that
inner_protocol is zero and the value of skb->protocol is not an MPLS
ethernet type.
- This new scheme:
+ Pushes logic to set inner_protocol closer to the case where it is
needed.
+ Avoids over-writing values set by other users.
* As suggested by Pravin Shelar
+ Only set and restore skb->protocol in rpl___skb_gso_segment() in the
case of MPLS
+ Add inner_protocol field to struct ovs_gso_cb instead of ovs_skb_cb.
This moves compatibility code closer to where it is used
and creates fewer differences with mainline.
* Update comment on mac_len updates in datapath/actions.c
* Remove HAVE_INNER_PROCOTOL and instead just check
against kernel version 3.11 directly.
HAVE_INNER_PROCOTOL is a hang-over from work done prior
to the merge of inner_protocol into the kernel.
* Remove dubious condition !eth_p_mpls(inner_protocol) on
using inner_protocol as the type in rpl_skb_network_protocol()
* Do not update type of features in rpl_dev_queue_xmit.
Though arguably correct this is not an inherent part of
the changes made by this patch.
* Use skb_cow_head() in push_mpls()
+ Call skb_cow_head(skb, MPLS_HLEN) instead of
make_writable(skb, skb->mac_len) to ensure that there is enough head
room to push an MPLS LSE regardless of whether the skb is cloned or not.
+ This is consistent with the behaviour of rpl__vlan_put_tag().
+ This is a fix for crashes reported when performing mpls_push
with headroom less than 4. This problem was introduced in v3.36.
* Skip popping in mpls_pop if the skb is too short to contain an MPLS LSE
Differences between v2.39 and v2.38:
* Rebase for removal of vlan, checksum and skb->mark compat code
- This includes adding adding a new patch,
"[PATCH v2.39 6/7] datapath: Break out deacceleration portion of
vlan_push" to allow re-use of some existing code.
Differences between v2.38 and v2.37:
* Rebase for SCTP support
* Refactor validate_tp_port() to iterate over eth_types rather
than open-coding the loop. With the addition of SCTP this logic
is now used three times.
Differences between v2.37 and v2.36:
* Rebase
Differences between v2.36 and v2.35:
* Rebase
* Do not add set_ethertype() to datapath/actions.c.
As this patch has evolved this function had devolved into
to sets of functionality wrapped into a single function with
only one line of common code. Refactor things to simply
open-code setting the ether type in the two locations where
set_ethertype() was previously used. The aim here is to improve
readability.
* Update setting skb->ethertype after mpls push and pop.
- In the case of push_mpls it should be set unconditionally
as in v2.35 the behaviour of this function to always push
an MPLS LSE before any VLAN tags.
- In the case of mpls_pop eth_p_mpls(skb->protocol) is a better
test than skb->protocol != htons(ETH_P_8021Q) as it will give the
correct behaviour in the presence of other VLAN ethernet types,
for example 0x88a8 which is used by 802.1ad. Moreover, it seems
correct to update the ethernet type if it was previously set
according to the top-most MPLS LSE.
* Deaccelerate VLANs when pushing MPLS tags the
- Since v2.35 MPLS push will insert an MPLS LSE before any VLAN tags.
This means that if an accelerated tag is present it should be
deaccelerated to ensure it ends up in the correct position.
* Update skb->mac_len in push_mpls() so that it will be correct
when used by a subsequent call to pop_mpls().
As things stand I do not believe this is strictly necessary as
ovs-vswitchd will not send a pop MPLS action after a push MPLS action.
However, I have added this in order to code more defensively as I believe
that if such a sequence did occur it would be rather unobvious why
it didn't work.
* Do not add skb_cow_head() call in push_mpls().
It is unnecessary as there is a make_writable() call.
This change was also made in v2.30 but some how the
code regressed between then and v2.35.
Differences between v2.35 and v2.34:
* Add support for the tag ordering specified up until OpenFlow 1.2 and
the ordering specified from OpenFlow 1.3.
* Correct error in datapath patch's handling of GSO in the presence
of MPLS and absence of VLANs.
To aid review this series is available in git at:
git://github.com/horms/openvswitch.git devel/mpls-v2.44
Patch list and overall diffstat:
Joe Stringer (3):
odp: Allow VLAN actions after MPLS actions
ofp-actions: Add separate OpenFlow 1.3 action parser
lib: Support pushing of MPLS LSE before or after VLAN tag
Simon Horman (2):
datapath: Break out deacceleration portion of vlan_push
datapath: Add basic MPLS support to kernel
datapath/Modules.mk | 1 +
datapath/actions.c | 158 ++++++++-
datapath/datapath.c | 4 +-
datapath/flow.c | 29 ++
datapath/flow.h | 17 +-
datapath/flow_netlink.c | 286 +++++++++++++--
datapath/flow_netlink.h | 2 +-
datapath/linux/compat/gso.c | 70 +++-
datapath/linux/compat/gso.h | 41 +++
datapath/linux/compat/include/linux/netdevice.h | 6 +-
datapath/linux/compat/netdevice.c | 10 +-
datapath/mpls.h | 15 +
include/linux/openvswitch.h | 7 +-
lib/flow.c | 2 +-
lib/odp-util.c | 9 +-
lib/odp-util.h | 3 +-
lib/ofp-actions.c | 91 ++++-
lib/ofp-actions.h | 16 +
lib/ofp-print.c | 2 +-
lib/ofp-util.c | 24 +-
lib/ofp-util.h | 2 +-
lib/packets.c | 10 +-
lib/packets.h | 2 +-
ofproto/ofproto-dpif-xlate.c | 134 +++++--
tests/ofproto-dpif.at | 446 ++++++++++++++++++++++++
utilities/ovs-ofctl.c | 8 +-
26 files changed, 1275 insertions(+), 120 deletions(-)
create mode 100644 datapath/mpls.h
--
1.8.4
^ permalink raw reply
* [PATCH v2.44 2/5] ofp-actions: Add separate OpenFlow 1.3 action parser
From: Simon Horman @ 2013-10-17 1:15 UTC (permalink / raw)
To: dev, netdev, Jesse Gross, Ben Pfaff
Cc: Pravin B Shelar, Ravi K, Isaku Yamahata, Joe Stringer
In-Reply-To: <1381972511-27221-1-git-send-email-horms@verge.net.au>
From: Joe Stringer <joe@wand.net.nz>
This patch adds new ofpact_from_openflow13() and
ofpacts_from_openflow13() functions parallel to the existing ofpact
handling code. In the OpenFlow 1.3 version, push_mpls is handled
differently, but all other actions are handled by the existing code.
In the case of push_mpls for OpenFlow 1.3 the new mpls_before_vlan field of
struct ofpact_push_mpls is set to true. This will be used by a subsequent
patch to allow allow the correct VLAN+MPLS datapath behaviour to be
determined at odp translation time.
enum ofpact_mpls_position contributed by Ben Pfaff.
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Ben, please feel free to add yourself as a co-author
as you wrote the enum ofpact_mpls_position portion.
v2.44
* No change
v2.43 [Ben Pfaff and Simon Horman]
* Code contributed by Ben Pfaff
+ Use enum for to control order of MPLS LSE insertion
This makes the logic somewhat clearer
* Add a helper push_mpls_from_openflow() to consolidate
the same logic that appears in three locations.
v2.42
* No change
v2.41 [Simon Horman]
* As suggested by Ben Pfaff
+ Expand struct ofpact_reg_load to include a mpls_before_vlan field
rather than using the compat field of the ofpact field of
struct ofpact_reg_load.
+ Pass version to ofpacts_pull_openflow11_actions and
ofpacts_pull_openflow11_instructions. This removes the invalid
assumption that that these functions are passed a full message and are
thus able to deduce the OpenFlow version.
v2.36 - v2.40
* No change
v2.35 [Joe Stringer]
* First post
---
lib/ofp-actions.c | 91 ++++++++++++++++++++++++++++++++++++++++++++-------
lib/ofp-actions.h | 16 +++++++++
lib/ofp-print.c | 2 +-
lib/ofp-util.c | 24 ++++++++------
lib/ofp-util.h | 2 +-
utilities/ovs-ofctl.c | 8 ++---
6 files changed, 115 insertions(+), 28 deletions(-)
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index 06f9f6b..430d969 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -238,6 +238,22 @@ sample_from_openflow(const struct nx_action_sample *nas,
}
static enum ofperr
+push_mpls_from_openflow(ovs_be16 ethertype, enum ofpact_mpls_position position,
+ struct ofpbuf *out)
+{
+ struct ofpact_push_mpls *oam;
+
+ if (!eth_type_mpls(ethertype)) {
+ return OFPERR_OFPBAC_BAD_ARGUMENT;
+ }
+ oam = ofpact_put_PUSH_MPLS(out);
+ oam->ethertype = ethertype;
+ oam->position = position;
+
+ return 0;
+}
+
+static enum ofperr
decode_nxast_action(const union ofp_action *a, enum ofputil_action_code *code)
{
const struct nx_action_header *nah = (const struct nx_action_header *) a;
@@ -430,10 +446,8 @@ ofpact_from_nxast(const union ofp_action *a, enum ofputil_action_code code,
case OFPUTIL_NXAST_PUSH_MPLS: {
struct nx_action_push_mpls *nxapm = (struct nx_action_push_mpls *)a;
- if (!eth_type_mpls(nxapm->ethertype)) {
- return OFPERR_OFPBAC_BAD_ARGUMENT;
- }
- ofpact_put_PUSH_MPLS(out)->ethertype = nxapm->ethertype;
+ error = push_mpls_from_openflow(nxapm->ethertype,
+ OFPACT_MPLS_AFTER_VLAN, out);
break;
}
@@ -844,10 +858,8 @@ ofpact_from_openflow11(const union ofp_action *a, struct ofpbuf *out)
case OFPUTIL_OFPAT11_PUSH_MPLS: {
struct ofp11_action_push *oap = (struct ofp11_action_push *)a;
- if (!eth_type_mpls(oap->ethertype)) {
- return OFPERR_OFPBAC_BAD_ARGUMENT;
- }
- ofpact_put_PUSH_MPLS(out)->ethertype = oap->ethertype;
+ error = push_mpls_from_openflow(oap->ethertype,
+ OFPACT_MPLS_AFTER_VLAN, out);
break;
}
@@ -1108,6 +1120,35 @@ ofpacts_from_openflow11_for_action_set(const union ofp_action *in,
}
\f
+static enum ofperr
+ofpact_from_openflow13(const union ofp_action *a, struct ofpbuf *out)
+{
+ enum ofputil_action_code code;
+ enum ofperr error;
+
+ error = decode_openflow11_action(a, &code);
+ if (error) {
+ return error;
+ }
+
+ if (code == OFPUTIL_OFPAT11_PUSH_MPLS) {
+ struct ofp11_action_push *oap = (struct ofp11_action_push *)a;
+ error = push_mpls_from_openflow(oap->ethertype,
+ OFPACT_MPLS_BEFORE_VLAN, out);
+ } else {
+ error = ofpact_from_openflow11(a, out);
+ }
+
+ return error;
+}
+
+static enum ofperr
+ofpacts_from_openflow13(const union ofp_action *in, size_t n_in,
+ struct ofpbuf *out)
+{
+ return ofpacts_from_openflow(in, n_in, out, ofpact_from_openflow13);
+}
+\f
/* OpenFlow 1.1 instructions. */
#define DEFINE_INST(ENUM, STRUCT, EXTENSIBLE, NAME) \
@@ -1314,11 +1355,14 @@ get_actions_from_instruction(const struct ofp11_instruction *inst,
*n_actions = (ntohs(inst->len) - sizeof *inst) / OFP11_INSTRUCTION_ALIGN;
}
-/* Attempts to convert 'actions_len' bytes of OpenFlow 1.1 actions from the
+/* Attempts to convert 'actions_len' bytes of OpenFlow actions from the
* front of 'openflow' into ofpacts. On success, replaces any existing content
* in 'ofpacts' by the converted ofpacts; on failure, clears 'ofpacts'.
* Returns 0 if successful, otherwise an OpenFlow error.
*
+ * Actions are processed according to their OpenFlow version which
+ * is provided in the 'version' parameter.
+ *
* In most places in OpenFlow 1.1 and 1.2, actions appear encapsulated in
* instructions, so you should call ofpacts_pull_openflow11_instructions()
* instead of this function.
@@ -1330,15 +1374,27 @@ get_actions_from_instruction(const struct ofp11_instruction *inst,
* valid in a specific context. */
enum ofperr
ofpacts_pull_openflow11_actions(struct ofpbuf *openflow,
+ enum ofp_version version,
unsigned int actions_len,
struct ofpbuf *ofpacts)
{
- return ofpacts_pull_actions(openflow, actions_len, ofpacts,
- ofpacts_from_openflow11);
+ switch (version) {
+ case OFP10_VERSION:
+ case OFP11_VERSION:
+ case OFP12_VERSION:
+ return ofpacts_pull_actions(openflow, actions_len, ofpacts,
+ ofpacts_from_openflow11);
+ case OFP13_VERSION:
+ return ofpacts_pull_actions(openflow, actions_len, ofpacts,
+ ofpacts_from_openflow13);
+ default:
+ NOT_REACHED();
+ }
}
enum ofperr
ofpacts_pull_openflow11_instructions(struct ofpbuf *openflow,
+ enum ofp_version version,
unsigned int instructions_len,
struct ofpbuf *ofpacts)
{
@@ -1389,7 +1445,18 @@ ofpacts_pull_openflow11_instructions(struct ofpbuf *openflow,
get_actions_from_instruction(insts[OVSINST_OFPIT11_APPLY_ACTIONS],
&actions, &n_actions);
- error = ofpacts_from_openflow11(actions, n_actions, ofpacts);
+ switch (version) {
+ case OFP10_VERSION:
+ case OFP11_VERSION:
+ case OFP12_VERSION:
+ error = ofpacts_from_openflow11(actions, n_actions, ofpacts);
+ break;
+ case OFP13_VERSION:
+ error = ofpacts_from_openflow13(actions, n_actions, ofpacts);
+ break;
+ default:
+ NOT_REACHED();
+ }
if (error) {
goto exit;
}
diff --git a/lib/ofp-actions.h b/lib/ofp-actions.h
index 5996651..d6aabf9 100644
--- a/lib/ofp-actions.h
+++ b/lib/ofp-actions.h
@@ -327,12 +327,26 @@ struct ofpact_reg_load {
union mf_subvalue subvalue; /* Least-significant bits are used. */
};
+/* The position in the packet at which to insert an MPLS header.
+ *
+ * Used NXAST_PUSH_MPLS, OFPAT11_PUSH_MPLS. */
+enum ofpact_mpls_position {
+ /* Add the MPLS LSE after the Ethernet header but before any VLAN tags.
+ * OpenFlow 1.3+ requires this behavior. */
+ OFPACT_MPLS_BEFORE_VLAN,
+
+ /* Add the MPLS LSE after the Ethernet header and any VLAN tags.
+ * OpenFlow 1.1 and 1.2 require this behavior. */
+ OFPACT_MPLS_AFTER_VLAN
+};
+
/* OFPACT_PUSH_VLAN/MPLS/PBB
*
* Used for NXAST_PUSH_MPLS, OFPAT11_PUSH_MPLS. */
struct ofpact_push_mpls {
struct ofpact ofpact;
ovs_be16 ethertype;
+ enum ofpact_mpls_position position;
};
/* OFPACT_POP_MPLS
@@ -524,9 +538,11 @@ enum ofperr ofpacts_pull_openflow10(struct ofpbuf *openflow,
unsigned int actions_len,
struct ofpbuf *ofpacts);
enum ofperr ofpacts_pull_openflow11_actions(struct ofpbuf *openflow,
+ enum ofp_version version,
unsigned int actions_len,
struct ofpbuf *ofpacts);
enum ofperr ofpacts_pull_openflow11_instructions(struct ofpbuf *openflow,
+ enum ofp_version version,
unsigned int instructions_len,
struct ofpbuf *ofpacts);
enum ofperr ofpacts_check(const struct ofpact[], size_t ofpacts_len,
diff --git a/lib/ofp-print.c b/lib/ofp-print.c
index a31de9d..9a84645 100644
--- a/lib/ofp-print.c
+++ b/lib/ofp-print.c
@@ -2228,7 +2228,7 @@ ofp_print_group_desc(struct ds *s, const struct ofp_header *oh)
struct ofputil_group_desc gd;
int retval;
- retval = ofputil_decode_group_desc_reply(&gd, &b);
+ retval = ofputil_decode_group_desc_reply(&gd, &b, oh->version);
if (retval) {
if (retval != EOF) {
ds_put_cstr(s, " ***parse error***");
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 173b534..570447a 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -1504,7 +1504,8 @@ ofputil_decode_flow_mod(struct ofputil_flow_mod *fm,
return error;
}
- error = ofpacts_pull_openflow11_instructions(&b, b.size, ofpacts);
+ error = ofpacts_pull_openflow11_instructions(&b, oh->version,
+ b.size, ofpacts);
if (error) {
return error;
}
@@ -2360,7 +2361,8 @@ ofputil_decode_flow_stats_reply(struct ofputil_flow_stats *fs,
return EINVAL;
}
- if (ofpacts_pull_openflow11_instructions(msg, length - sizeof *ofs -
+ if (ofpacts_pull_openflow11_instructions(msg, oh->version,
+ length - sizeof *ofs -
padded_match_len, ofpacts)) {
VLOG_WARN_RL(&bad_ofmsg_rl, "OFPST_FLOW reply bad instructions");
return EINVAL;
@@ -3092,7 +3094,8 @@ ofputil_decode_packet_out(struct ofputil_packet_out *po,
return error;
}
- error = ofpacts_pull_openflow11_actions(&b, ntohs(opo->actions_len),
+ error = ofpacts_pull_openflow11_actions(&b, oh->version,
+ ntohs(opo->actions_len),
ofpacts);
if (error) {
return error;
@@ -5674,8 +5677,8 @@ ofputil_append_group_desc_reply(const struct ofputil_group_desc *gds,
}
static enum ofperr
-ofputil_pull_buckets(struct ofpbuf *msg, size_t buckets_length,
- struct list *buckets)
+ofputil_pull_buckets(struct ofpbuf *msg, enum ofp_version version,
+ size_t buckets_length, struct list *buckets)
{
struct ofp11_bucket *ob;
@@ -5708,8 +5711,8 @@ ofputil_pull_buckets(struct ofpbuf *msg, size_t buckets_length,
buckets_length -= ob_len;
ofpbuf_init(&ofpacts, 0);
- error = ofpacts_pull_openflow11_actions(msg, ob_len - sizeof *ob,
- &ofpacts);
+ error = ofpacts_pull_openflow11_actions(msg, version,
+ ob_len - sizeof *ob, &ofpacts);
if (error) {
ofpbuf_uninit(&ofpacts);
ofputil_bucket_list_destroy(buckets);
@@ -5745,7 +5748,7 @@ ofputil_pull_buckets(struct ofpbuf *msg, size_t buckets_length,
* otherwise a positive errno value. */
int
ofputil_decode_group_desc_reply(struct ofputil_group_desc *gd,
- struct ofpbuf *msg)
+ struct ofpbuf *msg, enum ofp_version version)
{
struct ofp11_group_desc_stats *ogds;
size_t length;
@@ -5774,7 +5777,8 @@ ofputil_decode_group_desc_reply(struct ofputil_group_desc *gd,
return OFPERR_OFPBRC_BAD_LEN;
}
- return ofputil_pull_buckets(msg, length - sizeof *ogds, &gd->buckets);
+ return ofputil_pull_buckets(msg, version, length - sizeof *ogds,
+ &gd->buckets);
}
/* Converts abstract group mod 'gm' into a message for OpenFlow version
@@ -5857,7 +5861,7 @@ ofputil_decode_group_mod(const struct ofp_header *oh,
gm->type = ogm->type;
gm->group_id = ntohl(ogm->group_id);
- return ofputil_pull_buckets(&msg, msg.size, &gm->buckets);
+ return ofputil_pull_buckets(&msg, oh->version, msg.size, &gm->buckets);
}
/* Parse a queue status request message into 'oqsr'.
diff --git a/lib/ofp-util.h b/lib/ofp-util.h
index d5f34d7..5fa8fee 100644
--- a/lib/ofp-util.h
+++ b/lib/ofp-util.h
@@ -973,7 +973,7 @@ int ofputil_decode_group_stats_reply(struct ofpbuf *,
struct ofputil_group_stats *);
int ofputil_decode_group_desc_reply(struct ofputil_group_desc *,
- struct ofpbuf *);
+ struct ofpbuf *, enum ofp_version);
void ofputil_append_group_desc_reply(const struct ofputil_group_desc *,
struct list *buckets,
diff --git a/utilities/ovs-ofctl.c b/utilities/ovs-ofctl.c
index 2b89755..630591c 100644
--- a/utilities/ovs-ofctl.c
+++ b/utilities/ovs-ofctl.c
@@ -2970,8 +2970,8 @@ ofctl_parse_ofp11_actions(int argc OVS_UNUSED, char *argv[] OVS_UNUSED)
/* Convert to ofpacts. */
ofpbuf_init(&ofpacts, 0);
size = of11_in.size;
- error = ofpacts_pull_openflow11_actions(&of11_in, of11_in.size,
- &ofpacts);
+ error = ofpacts_pull_openflow11_actions(&of11_in, OFP11_VERSION,
+ of11_in.size, &ofpacts);
if (error) {
printf("bad OF1.1 actions: %s\n\n", ofperr_get_name(error));
ofpbuf_uninit(&ofpacts);
@@ -3039,8 +3039,8 @@ ofctl_parse_ofp11_instructions(int argc OVS_UNUSED, char *argv[] OVS_UNUSED)
/* Convert to ofpacts. */
ofpbuf_init(&ofpacts, 0);
size = of11_in.size;
- error = ofpacts_pull_openflow11_instructions(&of11_in, of11_in.size,
- &ofpacts);
+ error = ofpacts_pull_openflow11_instructions(&of11_in, OFP11_VERSION,
+ of11_in.size, &ofpacts);
if (!error) {
/* Verify actions. */
struct flow flow;
--
1.8.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