* Re: am335x: no multicast reception over VLAN
From: Mugunthan V N @ 2016-03-30 16:52 UTC (permalink / raw)
To: Yegor Yefremov
Cc: Grygorii Strashko, netdev, linux-omap@vger.kernel.org, drivshin,
ml
In-Reply-To: <CAGm1_kvXA4egrK8-oCedYjvPm7BhJdy_w-5ON24snYdKiN3K7g@mail.gmail.com>
On Wednesday 30 March 2016 02:05 PM, Yegor Yefremov wrote:
> On Wed, Mar 30, 2016 at 7:33 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
>>> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>>>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>>>> <grygorii.strashko@ti.com> wrote:
>>>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>>>> Hi Mugunthan,
>>>>>>
>>>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>>> Hi Yegor
>>>>>>>
>>>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>>>> VLAN ID:
>>>>>>>>
>>>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>>>
>>>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>>>> could both receive and send multicast packets via VLAN.
>>>>>>>
>>>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>>>
>>>>>> I'm trying multicast tx/rx on eth1.100.
>>>>>>
>>>>>> eth1 has no problems.
>>>>>>
>>>>>
>>>>> it'd be nice if will be able to post here output fom commands:
>>>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>>>> # ifconfig -a
>>>>> # tcpdump -e -f -Q in -i eth0
>>>>> # tcpdump -e -f -Q in -i eth0.100
>>>>
>>>> Which kernel/branch do you want me to test?
>>>>
>>>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>>>
>>>> So far I was using vanilla kernel.
>>>
>>> Your branch (but better 4.5 kernels (or 4.4)).
>>> Just when you've done with configuration run cmds 1&2,
>>> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
>>> then stop test and run cmd 1 again.
>>>
>>> After all could you provide your console output here, pls.
>>>
>>>
>>
>> To use command 1, you need TI kernel [1] as it won't build with vanilla
>> kernel.
>>
>> [1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
>
> # uname -a
> Linux buildroot 4.1.18 #1 SMP Wed Mar 30 09:48:37 CEST 2016 armv7l GNU/Linux
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x1, member_list = 0x3
>
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x1, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
I don't see multicast entry added to ALE table for 01:00:5e:03:1d:47,
can you run the receive command in background/another terminal and get
the dump when receiving on eth1 and eth1.100 as well and don't enable
tcpdump as it will put the switch in promiscuous mode.
>
> # ifconfig -a
> can0 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> NOARP MTU:16 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:165
>
> eth0 Link encap:Ethernet HWaddr 74:6A:8F:00:16:12
> inet addr:192.168.254.254 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:175
>
> eth1 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
> inet addr:192.168.1.233 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:245 errors:0 dropped:0 overruns:0 frame:0
> TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:40995 (40.0 KiB) TX bytes:14086 (13.7 KiB)
>
> eth1.100 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
> inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:65 errors:0 dropped:0 overruns:0 frame:0
> TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:8369 (8.1 KiB) TX bytes:6340 (6.1 KiB)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:65536 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:344 (344.0 B) TX bytes:344 (344.0 B)
>
> # tcpdump -e -f -Q in -i eth1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 00:47:40.240731 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
> (oui Unknown), ethertype 802.1Q (0x8100), length 65: vlan 100, p 0,
> ethertype IPv4, 192.168.100.1.59870 > 224.3.29.71.10000: UDP, length
> 19
> 00:47:45.259285 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
> (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 100, p 0,
> ethertype ARP, Reply 192.168.100.1 is-at 06:15:4d:85:61:1e (oui
> Unknown), length 42
>
> # tcpdump -e -f -Q in -i eth1.100
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1.100, link-type EN10MB (Ethernet), capture size 262144 bytes
> 00:48:52.477500 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
> (oui Unknown), ethertype IPv4 (0x0800), length 61: 192.168.100.1.54382
>> 224.3.29.71.10000: UDP, length 19
> 00:48:57.486437 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
> (oui Unknown), ethertype ARP (0x0806), length 56: Reply 192.168.100.1
> is-at 06:15:4d:85:61:1e (oui Unknown), length 42
You had received these packets as tcpdump will enable promiscuous mode
so that you receive all the packets from the wire.
>
> What does "no super" mean and where can I see the "--fwd-state <value
> 0-3>" value/description?
Multicast supervisory packets are designated by the super bit in the
table entry. Supervisory packets are not dropped due to rate limiting,
OUI, or VLAN processing.
You can get the documentation in TRM under title "Multicast Forward
State (MCAST_FWD_STATE)" for forward state description.
Regards
Mugunthan V N
^ permalink raw reply
* Re: Question on rhashtable in worst-case scenario.
From: Ben Greear @ 2016-03-30 16:52 UTC (permalink / raw)
To: David Miller, johannes
Cc: linux-kernel, herbert, linux-wireless, netdev, tgraf
In-Reply-To: <20160330.123821.328761526754742195.davem@davemloft.net>
On 03/30/2016 09:38 AM, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 30 Mar 2016 11:14:12 +0200
>
>> On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote:
>>> Looks like rhashtable has too much policy in it to properly deal with
>>> cases where there are too many hash collisions, so I am going to work
>>> on reverting it's use in mac80211.
>>
>> I'm not really all that happy with that approach - can't we fix the
>> rhashtable? It's a pretty rare corner case that many keys really are
>> identical and no kind of hash algorithm, but it seems much better to
>> still deal with it than to remove the rhashtable usage and go back to
>> hand-rolling something.
>
> Yeah reverting seems like a really idiotic way to deal with the issue.
>
If someone can fix rhashtable, then great.
I read some earlier comments [1] back when someone else reported
similar problems, and the comments seemed to indicate that rhashtable was
broken in this manner on purpose to protect against hashing attacks.
If you are baking in this type of policy to what should be a basic
data-type, then it is not useful for how it is being used in
the mac80211 stack.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1512.2/01681.html
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Sowmini Varadhan @ 2016-03-30 17:00 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, intel-wired-lan, jesse.brandeburg, alexander.duyck,
jeffrey.t.kirsher
In-Reply-To: <20160330064213.12927.46852.stgit@localhost.localdomain>
On (03/29/16 23:44), Alexander Duyck wrote:
> This patch has been sanity checked only. I cannot yet guarantee it
> resolves the original issue that was reported. I'll try to get a
> reproduction environment setup tomorrow but I don't know how long that
> should take.
I tried this out with rds-stress on my test-pair, unfortunately, I
still see the Tx hang.
Setting up the test is quite easy- for reference, the instructions
are here:
https://sourceforge.net/p/e1000/mailman/message/34936766/
--Sowmini
^ permalink raw reply
* Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
From: Troy Kisky @ 2016-03-30 17:04 UTC (permalink / raw)
To: Greg Ungerer, Zhi Li, Fugang Duan; +Cc: netdev
In-Reply-To: <56FB46EA.7050401@uclinux.org>
On 3/29/2016 8:24 PM, Greg Ungerer wrote:
> Hi Troy,
>
> Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error
> messages') adds a write to a register that is not present in all
> implementations of the FEC hardware module. None of the ColdFire
> SoC parts with the FEC module have the FTRL (0x1b0) register.
>
> Does this need a quirk flag to key access to this register of?
> Or can you piggyback on the FEC_QUIRK_HAS_RACC flag?
>
> Regards
> Greg
I'm no expert on what hardware has which registers, but piggybacking
works for all the processors that I use. Let's see what Freescale
says, but would you like to submit a patch to move it inside the quirk's
"if", or do you want me to do it?
^ permalink raw reply
* Re: [PATCH RFC net-next] net: core: Pass XPS select queue decision to skb_tx_hash
From: John Fastabend @ 2016-03-30 17:04 UTC (permalink / raw)
To: Saeed Mahameed, Saeed Mahameed, netdev
Cc: Eric Dumazet, Tom Herbert, Jiri Pirko, David S. Miller,
John Fastabend
In-Reply-To: <56FBD35D.4090805@dev.mellanox.co.il>
On 16-03-30 06:23 AM, Saeed Mahameed wrote:
>
>
> On 3/30/2016 3:18 AM, John Fastabend wrote:
>> I would prefer to not have another strange quirk users have to
>> remember in order to do tx classification. So with this change
>> depending on the driver the queue selection precedence changes.
> This change doesn't depend on the driver it affects all drivers that
> implement the select queue ndo and use the default fallback
> "pick_tx_queue" which this patch came to fix, or any driver that doesn't
> implement the ndo (the fallback is the default in this case).
Yep, sorry I read the patch to quickly and without coffee thanks!
>> In short I agree with the problem statement but think we can find a
>> better solution. One idea that comes to mind is we can have a tc
>> action to force the queue selection? Now that we have the egress tc
>> hook it would probably be fairly cheap to implement and if users want
>> this behavior they can ask for it explicitly. If your thinking about
>> tc stuff we could fix the tooling to set this action when ever dcb is
>> turned on or hardware rate limiting is enabled, etc. And even if we
>> wanted we could have the driver add the rule in the cases where
>> firmware protocols are configuring the QOS/etc.
> Why would you ask for a bug fix explicitly ? IMHO this how I expect the
> pick _tx_queue routine to behave, why would I disable XPS in order for
> select queue to choose according TC QoS ?
> as this patch suggests we can benefit from both without any additional
> tooling !
>
OK, so let me see if I get this right now. This was the precedence
before the patch in the normal no select queue case,
(1) socket mapping sk_tx_queue_mapping iff !ooo_okay
(2) xps
(3) skb->queue_mapping
(4) qoffset/qcount (hash over tc queues)
(5) hash over num_tx_queues
With this patch the precedence is a bit changed because
skb_tx_hash is always called.
(1) socket mapping sk_tx_queue_mapping iff !ooo_okay
(2) skb->queue_mapping
(3) qoffset/qcount
(hash over tc queues if xps choice is > qcount)
(4) xps
(5) hash over num_tx_queues
Sound right? Nice thing about this with correct configuration
of tc with qcount = xps_queues it sort of works as at least
I expect it to. I think the question is are people OK with
letting skb->queue_mapping take precedence. I am at least
because it makes the skb edit queue_mapping action from tc
easier to use.
And just a comment on the code why not just move get_xps_queue
into skb_tx_hash at this point if its always being called as the
"hint". Then we avoid calling it in the case queue_mapping is
set.
>>> if (skb_vlan_tag_present(skb))
>>> up = skb_vlan_tag_get(skb) >> VLAN_PRIO_SHIFT;
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index cb0d5d0..ad81ffe 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -3130,16 +3130,16 @@ static inline int netif_set_xps_queue(struct
>>> net_device *dev,
>>> #endif
>>> u16 __skb_tx_hash(const struct net_device *dev, struct sk_buff *skb,
>>> - unsigned int num_tx_queues);
>>> + unsigned int num_tx_queues, int txq_hint);
>>>
>> [...]
>>
>> And all this seems like it would only ever be called by drivers select
>> queue routines which I really wish we could kill off one of these days
>> instead of add to. Now if the signal is something higher in the stack
>> and not the driver I think it is OK.
> I agree, drivers shouldn't call this function, the only reason drivers
> call this function is to bypass get_xps_queue
> and after this patch i don't think driver will need to call it, since it
> will be called even if XPS is configured.
>
yep.
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Alexander Duyck @ 2016-03-30 17:12 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Alexander Duyck, Netdev, intel-wired-lan, Brandeburg, Jesse,
Jeff Kirsher
In-Reply-To: <20160330170011.GB27540@oracle.com>
On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/29/16 23:44), Alexander Duyck wrote:
>> This patch has been sanity checked only. I cannot yet guarantee it
>> resolves the original issue that was reported. I'll try to get a
>> reproduction environment setup tomorrow but I don't know how long that
>> should take.
>
> I tried this out with rds-stress on my test-pair, unfortunately, I
> still see the Tx hang.
>
> Setting up the test is quite easy- for reference, the instructions
> are here:
> https://sourceforge.net/p/e1000/mailman/message/34936766/
Yeah. The patch was sort of a knee-jerk reaction to being told that
the patch referenced caused a regression. From what I can tell that
is not the case as I am also seeing the Tx hangs when I run the test
with the frames being linearized.
I'll do some research this morning to see if I can find a root cause.
Unfortunately the malicious driver detection isn't very well
documented so I can't be certain what is causing it to be triggered.
- Alex
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Sowmini Varadhan @ 2016-03-30 17:20 UTC (permalink / raw)
To: Alexander Duyck
Cc: Alexander Duyck, Netdev, intel-wired-lan, Brandeburg, Jesse,
Jeff Kirsher
In-Reply-To: <CAKgT0UdTgaeamyLetGPK0mqMNS-80BTc8t-WdSGJuuLDfz4JOg@mail.gmail.com>
On (03/30/16 10:12), Alexander Duyck wrote:
> Yeah. The patch was sort of a knee-jerk reaction to being told that
> the patch referenced caused a regression. From what I can tell that
> is not the case as I am also seeing the Tx hangs when I run the test
> with the frames being linearized.
I'm not sure how important of a subtlety this is, but the actual
console log after the patch is the following:
i40e 0000:82:00.0: TX driver issue detected, PF reset issued
i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
i40e 0000:82:00.0: TX driver issue detected, PF reset issued
i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
i40e 0000:82:00.0: TX driver issue detected, PF reset issued
Comparing with what I'd pasted in the sourceforge thread earlier,
I see that it does not say "Hung Tx queue etc." any more, though
it still resets.
Not sure if that changed info is significant?
--Sowmini
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Alexander Duyck @ 2016-03-30 17:35 UTC (permalink / raw)
To: Sowmini Varadhan
Cc: Alexander Duyck, Netdev, intel-wired-lan, Brandeburg, Jesse,
Jeff Kirsher
In-Reply-To: <20160330172001.GD27540@oracle.com>
On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/30/16 10:12), Alexander Duyck wrote:
>> Yeah. The patch was sort of a knee-jerk reaction to being told that
>> the patch referenced caused a regression. From what I can tell that
>> is not the case as I am also seeing the Tx hangs when I run the test
>> with the frames being linearized.
>
> I'm not sure how important of a subtlety this is, but the actual
> console log after the patch is the following:
>
> i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> i40e 0000:82:00.0: TX driver issue detected, PF reset issued
>
> Comparing with what I'd pasted in the sourceforge thread earlier,
> I see that it does not say "Hung Tx queue etc." any more, though
> it still resets.
>
> Not sure if that changed info is significant?
It might be. Right now I am chasing down the Tx driver issue as that
I what I am reproducing in my environment as well.
>From what I can tell by enabling msglvl tx_err it is reporting MDD
event 0x2. Unfortunately the documentation doesn't say what that is
so I am checking a few different possibilities.
- Alex
^ permalink raw reply
* Re: [PATCH] stmmac: Fix phy without MDIO subnode
From: Robert Gadsdon @ 2016-03-30 18:22 UTC (permalink / raw)
To: Giuseppe CAVALLARO, John Keeping; +Cc: Gabriel Fernandez, netdev, linux-kernel
In-Reply-To: <56F4F9F6.8070103@st.com>
I have applied this to my Rock2 - Kernel 4.6-rc1 - and eth0 is present,
now, but no network traffic gets through:
To rock2:
$ ping rgrock2
PING rgrock2 (192.168.0.xx) 56(84) bytes of data.
^C
--- rgrock2 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
>From rock2:
# ping 192.168.0.x
PING 192.168.0.x (192.168.0.2) 56(84) bytes of data.
>From 192.168.0.xx icmp_seq=1 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=2 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=3 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=4 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=5 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=6 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=7 Destination Host Unreachable
>From 192.168.0.xx icmp_seq=8 Destination Host Unreachable
--- 192.168.0.x ping statistics ---
9 packets transmitted, 0 received, +8 errors, 100% packet loss, time 8001ms
Everything worked OK with kernel 4.5-rc7, and with 4.5 Final with the
-rc7 versions of stmmac_platform.c and stmmac_mdio.c substituted..
Robert Gadsdon. March 30, 2016
^ permalink raw reply
* Re: [PATCH RFC net-next] net: core: Pass XPS select queue decision to skb_tx_hash
From: Saeed Mahameed @ 2016-03-30 18:30 UTC (permalink / raw)
To: John Fastabend
Cc: Saeed Mahameed, Linux Netdev List, Eric Dumazet, Tom Herbert,
Jiri Pirko, David S. Miller, John Fastabend
In-Reply-To: <56FC0723.4040003@gmail.com>
On Wed, Mar 30, 2016 at 8:04 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> OK, so let me see if I get this right now. This was the precedence
> before the patch in the normal no select queue case,
>
> (1) socket mapping sk_tx_queue_mapping iff !ooo_okay
> (2) xps
> (3) skb->queue_mapping
> (4) qoffset/qcount (hash over tc queues)
> (5) hash over num_tx_queues
>
> With this patch the precedence is a bit changed because
> skb_tx_hash is always called.
>
> (1) socket mapping sk_tx_queue_mapping iff !ooo_okay
> (2) skb->queue_mapping
> (3) qoffset/qcount
> (hash over tc queues if xps choice is > qcount)
> (4) xps
> (5) hash over num_tx_queues
>
> Sound right? Nice thing about this with correct configuration
> of tc with qcount = xps_queues it sort of works as at least
Yes !
for qcount = xps_queues which almost all drivers default
configurations goes this way, it works like charm, xps selects the
exact TC TX queue at the correct offset without any need for further
SKB hashing.
and even if by mistake XPS was also configured on TC TX queue then
this patch will detect that the xps hash is out of this TC
offset/qcount range and will re-hash. But i don't see why would user
or driver do such strange configuration.
> I expect it to. I think the question is are people OK with
> letting skb->queue_mapping take precedence. I am at least
> because it makes the skb edit queue_mapping action from tc
> easier to use.
>
skb->queue_mapping toke precedence also before this patch, the only
thing this patch came to change is how to compute the txq when
skb->queue_mapping is not present, so we don't need to worry about
this.
> And just a comment on the code why not just move get_xps_queue
> into skb_tx_hash at this point if its always being called as the
> "hint". Then we avoid calling it in the case queue_mapping is
> set.
>
Very good point, the only place that calls skb_tx_hash(dev, skb) other
than __netdev_pick_tx is mlx4 driver and they did it there just
because they wanted to bypass XPS configuration if TC QoS is
configured, with this fix we don't have to bypass XPS at all for when
TC is configured.
I will change it.
^ permalink raw reply
* Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
From: Fabio Estevam @ 2016-03-30 18:37 UTC (permalink / raw)
To: Greg Ungerer; +Cc: Troy Kisky, netdev@vger.kernel.org
In-Reply-To: <56FB46EA.7050401@uclinux.org>
Hi Greg,
On Wed, Mar 30, 2016 at 12:24 AM, Greg Ungerer <gerg@uclinux.org> wrote:
> Hi Troy,
>
> Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error
> messages') adds a write to a register that is not present in all
> implementations of the FEC hardware module. None of the ColdFire
> SoC parts with the FEC module have the FTRL (0x1b0) register.
>
> Does this need a quirk flag to key access to this register of?
> Or can you piggyback on the FEC_QUIRK_HAS_RACC flag?
Would the change below work on Coldfire?
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -943,8 +943,8 @@ fec_restart(struct net_device *ndev)
else
val &= ~FEC_RACC_OPTIONS;
writel(val, fep->hwp + FEC_RACC);
- }
writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
+ }
#endif
/*
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Jesse Brandeburg @ 2016-03-30 18:38 UTC (permalink / raw)
To: Alexander Duyck
Cc: Sowmini Varadhan, Alexander Duyck, Netdev, intel-wired-lan,
Jeff Kirsher, jesse.brandeburg
In-Reply-To: <CAKgT0UdTgaeamyLetGPK0mqMNS-80BTc8t-WdSGJuuLDfz4JOg@mail.gmail.com>
On Wed, 30 Mar 2016 10:12:51 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/29/16 23:44), Alexander Duyck wrote:
> >> This patch has been sanity checked only. I cannot yet guarantee it
> >> resolves the original issue that was reported. I'll try to get a
> >> reproduction environment setup tomorrow but I don't know how long that
> >> should take.
> >
> > I tried this out with rds-stress on my test-pair, unfortunately, I
> > still see the Tx hang.
> >
> > Setting up the test is quite easy- for reference, the instructions
> > are here:
> > https://sourceforge.net/p/e1000/mailman/message/34936766/
>
> Yeah. The patch was sort of a knee-jerk reaction to being told that
> the patch referenced caused a regression. From what I can tell that
Thanks for working so hard on the patch Alex, I need to apologize, as
the original test appears to fail as well with 1.3.46-k (a previous
driver to your patch) and I thought we had already tested that, but I
was wrong.
This is not a regression, but likely just an undetected "bug" that we
need to work out.
> is not the case as I am also seeing the Tx hangs when I run the test
> with the frames being linearized.
That doesn't make much sense unless it is something about how we are
setting up the offload. I troubleshoot by disabling the PFR from the
MDD code, then disabling tx timeout via debugfs, and using debugfs to
dump the descriptor ring after the MDD event fires.
> I'll do some research this morning to see if I can find a root cause.
> Unfortunately the malicious driver detection isn't very well
> documented so I can't be certain what is causing it to be triggered.
I'm still looking at this too and appreciate the help.
^ permalink raw reply
* Re: [PATCH-RFC] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for fiber
From: Daniel Walker @ 2016-03-30 19:34 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Shannon Nelson, Carolyn Wyborny,
Don Skidmore, Bruce Allan, John Ronciak, Mitch Williams
Cc: Steve Shih, danielwa, xe-kernel, intel-wired-lan, netdev,
linux-kernel
In-Reply-To: <1458943126-32258-1-git-send-email-danielwa@cisco.com>
So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and John)
I'm assuming no comments means this patch is acceptable , and I will
resubmit it without the RFC. Is that acceptable ?
On 03/25/2016 02:58 PM, Daniel Walker wrote:
> From: Steve Shih <sshih@cisco.com>
>
> This patch fixes the issues for disabling auto-negotiation and forcing
> speed and duplex settings for the fiber media.
>
> For fiber media, e1000_get_settings should return ETH_TP_MDI_INVALID for
> eth_tp_mdix_ctrl instead of ETH_TP_MDI_AUTO so subsequent e1000_set_settings
> call would not fail with -EOPNOTSUPP.
>
> e1000_set_spd_dplx should not automatically turn autoneg back on for forced
> 1000 Mbps full duplex settings.
>
> Cc: danielwa@fifo99.com
> Cc: xe-kernel@external.cisco.com
> Signed-off-by: Steve Shih <sshih@cisco.com>
> ---
> drivers/net/ethernet/intel/e1000e/ethtool.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 6cab1f3..cd03dcd 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> @@ -201,6 +201,9 @@ static int e1000_get_settings(struct net_device *netdev,
> else
> ecmd->eth_tp_mdix_ctrl = hw->phy.mdix;
>
> + if (hw->phy.media_type != e1000_media_type_copper)
> + ecmd->eth_tp_mdix_ctrl = ETH_TP_MDI_INVALID;
> +
> return 0;
> }
>
> @@ -236,8 +239,7 @@ static int e1000_set_spd_dplx(struct e1000_adapter *adapter, u32 spd, u8 dplx)
> mac->forced_speed_duplex = ADVERTISE_100_FULL;
> break;
> case SPEED_1000 + DUPLEX_FULL:
> - mac->autoneg = 1;
> - adapter->hw.phy.autoneg_advertised = ADVERTISE_1000_FULL;
> + mac->forced_speed_duplex = ADVERTISE_1000_FULL;
> break;
> case SPEED_1000 + DUPLEX_HALF: /* not supported */
> default:
^ permalink raw reply
* Re: [net-next] bond: output message before setting slave to inactive
From: David Miller @ 2016-03-30 19:37 UTC (permalink / raw)
To: zhangshengju; +Cc: j.vosburgh, vfalico, gospo, netdev
In-Reply-To: <1459233177-6394-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Tue, 29 Mar 2016 06:32:57 +0000
> This patch moves output message before setting slave to inactive, this will
> print the correct status of slave device.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
I think the message is in the appropriate spot wrt. state, so I will not
apply this, thanks.
^ permalink raw reply
* Re: [PATCH] bridge: Allow set bridge ageing time when switchdev disabled
From: David Miller @ 2016-03-30 19:40 UTC (permalink / raw)
To: yanhaishuang; +Cc: netdev, bridge, linux-kernel
In-Reply-To: <1459248488-25621-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Tue, 29 Mar 2016 18:48:08 +0800
> When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP,
> we should ignore this error code and continue to set the ageing time.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied and queued up for -stable, thanks.
> @@ -582,7 +582,7 @@ int br_set_ageing_time(struct net_bridge *br, u32 ageing_time)
> int err;
>
> err = switchdev_port_attr_set(br->dev, &attr);
> - if (err)
> + if (err && err != -EOPNOTSUPP)
> return err;
>
> br->ageing_time = t;
This is at least the 5th time I've had to apply a bug fix exactly like
this one.
If this doesn't convince everyone that this whole -EOPNOTSUPP
mechanism is extremely error prone, I don't know what will.
There should be only one or two strictly controlled locations that
reinterpret the return value from all of these routines that have this
special way of signalling lack of switchdev support via -EOPNOTSUPP.
It can't be spread all over the place like this, it simply does NOT work.
^ permalink raw reply
* Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
From: Jesse Brandeburg @ 2016-03-30 19:41 UTC (permalink / raw)
To: Alexander Duyck
Cc: Sowmini Varadhan, Alexander Duyck, Netdev, intel-wired-lan,
Jeff Kirsher, jesse.brandeburg
In-Reply-To: <CAKgT0Ufb-_X-DD2jYkVJQwLZ-JBfWD2Biuhi6YaxWBeNy9K2fQ@mail.gmail.com>
On Wed, 30 Mar 2016 10:35:55 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
> > On (03/30/16 10:12), Alexander Duyck wrote:
> >> Yeah. The patch was sort of a knee-jerk reaction to being told that
> >> the patch referenced caused a regression. From what I can tell that
> >> is not the case as I am also seeing the Tx hangs when I run the test
> >> with the frames being linearized.
> >
> > I'm not sure how important of a subtlety this is, but the actual
> > console log after the patch is the following:
> >
> > i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> > i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> > i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> > i40e 0000:82:00.0 eth2: adding 68:05:ca:30:dd:18 vid=0
> > i40e 0000:82:00.0: TX driver issue detected, PF reset issued
> >
> > Comparing with what I'd pasted in the sourceforge thread earlier,
> > I see that it does not say "Hung Tx queue etc." any more, though
> > it still resets.
> >
> > Not sure if that changed info is significant?
>
> It might be. Right now I am chasing down the Tx driver issue as that
> I what I am reproducing in my environment as well.
This gets "Even Uglier", I've turned off all offloads at my receiver,
enabled calling skb_linearize on *all* frames, which works fine for
scp, but the receiver shows > MSS sized frames on the wire for
rds-stress traffic.
This implies to me we have some issue with skb_linearize, possibly in
how the stack linearizes the data, or how the driver interprets the
linearized packets (which should always work)
Wheee......
^ permalink raw reply
* Re: [PATCH] sctp: really allow using GFP_KERNEL on sctp_packet_transmit
From: David Miller @ 2016-03-30 19:42 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <1459258863-21351-1-git-send-email-marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 29 Mar 2016 10:41:03 -0300
> Somehow my patch for commit cea8768f333e ("sctp: allow
> sctp_transmit_packet and others to use gfp") missed two important
> chunks, which are now added.
>
> Fixes: cea8768f333e ("sctp: allow sctp_transmit_packet and others to use gfp")
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH-RFC] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for fiber
From: Jeff Kirsher @ 2016-03-30 19:44 UTC (permalink / raw)
To: Daniel Walker, dima.ruinskiy
Cc: Steve Shih, danielwa, xe-kernel, intel-wired-lan, netdev
In-Reply-To: <56FC2A62.6040206@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Wed, 2016-03-30 at 12:34 -0700, Daniel Walker wrote:
>
> So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and
> John)
>
> I'm assuming no comments means this patch is acceptable , and I will
> resubmit it without the RFC. Is that acceptable ?
I personally do not see an issue with the patch, go ahead and submit it
as a non-RFC and I will make sure that the e1000e maintainer (Dima
Ruinskly) reviews it.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] sctp: flush if we can't fit another DATA chunk
From: David Miller @ 2016-03-30 19:46 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <1459258885-21502-1-git-send-email-marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 29 Mar 2016 10:41:25 -0300
> There is no point in delaying the packet if we can't fit a single byte
> of data on it anymore. So lets just reduce the threshold by the amount
> that a data chunk with 4 bytes (rounding) would use.
>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/output.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 97745351d58c2fb32b9f9b57d61831d7724d83b2..c518569123ce42a8f21f80754756306c39875013 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -705,7 +705,8 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
> /* Check whether this chunk and all the rest of pending data will fit
> * or delay in hopes of bundling a full sized packet.
> */
> - if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> + if (chunk->skb->len + q->out_qlen >
> + maxsize - packet->overhead - sizeof(sctp_data_chunk_t) - 4)
There is no maxsize in this function.
You must generate and test your patches against my networking tree.
Neil, how were you able to see where 'maxsize' is and how it's even
calculated before determining that this change is correct?
Please don't ACK patches you really didn't verify in any way at all,
thanks. It's better to have no reviews than bad reviews, because ACKs
are supposed to give me a reason to be more confident in the change.
Marcelo, I'm ignoring the rest of your SCTP changes, you have to get
your act together.
^ permalink raw reply
* Re: [net-next] bond: set mac address only if necessary
From: David Miller @ 2016-03-30 19:47 UTC (permalink / raw)
To: zhangshengju; +Cc: j.vosburgh, vfalico, gospo, netdev
In-Reply-To: <1459264457-19000-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Tue, 29 Mar 2016 15:14:17 +0000
> Bond device gets it's mac address from the first slave device, it's not
> necessary to set slave device's mac address to bond if equal.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
I don't think bond enslavement occurs often enough to justify this
optimization, sorry.
^ permalink raw reply
* Re: am335x: no multicast reception over VLAN
From: Peter Korsgaard @ 2016-03-30 19:47 UTC (permalink / raw)
To: Mugunthan V N
Cc: Yegor Yefremov, Grygorii Strashko, netdev,
linux-omap@vger.kernel.org, drivshin, ml
In-Reply-To: <56FC0431.5000106@ti.com>
>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
Hi,
> You had received these packets as tcpdump will enable promiscuous mode
> so that you receive all the packets from the wire.
FYI, you can use the -p option to tcpdump to not put the interface into
promiscuous mode.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] qed: initialize return rc to avoid returning garbage
From: David Miller @ 2016-03-30 19:48 UTC (permalink / raw)
To: colin.king
Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <1459270850-16177-1-git-send-email-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 29 Mar 2016 18:00:50 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> in the case where qed_slowpath_irq_req is not called, rc is not
> assigned and so qed_int_igu_enable will return a garbage value.
> Fix this by initializing rc to 0.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: flush if we can't fit another DATA chunk
From: marcelo.leitner @ 2016-03-30 19:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, vyasevich, linux-sctp
In-Reply-To: <20160330.154622.1322506750240048120.davem@davemloft.net>
On Wed, Mar 30, 2016 at 03:46:22PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Tue, 29 Mar 2016 10:41:25 -0300
>
> > There is no point in delaying the packet if we can't fit a single byte
> > of data on it anymore. So lets just reduce the threshold by the amount
> > that a data chunk with 4 bytes (rounding) would use.
> >
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > ---
> > net/sctp/output.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sctp/output.c b/net/sctp/output.c
> > index 97745351d58c2fb32b9f9b57d61831d7724d83b2..c518569123ce42a8f21f80754756306c39875013 100644
> > --- a/net/sctp/output.c
> > +++ b/net/sctp/output.c
> > @@ -705,7 +705,8 @@ static sctp_xmit_t sctp_packet_can_append_data(struct sctp_packet *packet,
> > /* Check whether this chunk and all the rest of pending data will fit
> > * or delay in hopes of bundling a full sized packet.
> > */
> > - if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
> > + if (chunk->skb->len + q->out_qlen >
> > + maxsize - packet->overhead - sizeof(sctp_data_chunk_t) - 4)
>
> There is no maxsize in this function.
>
> You must generate and test your patches against my networking tree.
>
> Neil, how were you able to see where 'maxsize' is and how it's even
> calculated before determining that this change is correct?
>
> Please don't ACK patches you really didn't verify in any way at all,
> thanks. It's better to have no reviews than bad reviews, because ACKs
> are supposed to give me a reason to be more confident in the change.
>
> Marcelo, I'm ignoring the rest of your SCTP changes, you have to get
> your act together.
Argh, indeed. Bad decision here to split up the patchset. Sorry for that.
Marcelo
^ permalink raw reply
* Re: [RFC] Add netdev all_adj_list refcnt propagation to fix panic
From: David Miller @ 2016-03-30 20:01 UTC (permalink / raw)
To: acollins; +Cc: netdev, mschiffer, vfalico
In-Reply-To: <1459272303-8851-1-git-send-email-acollins@cradlepoint.com>
From: Andrew Collins <acollins@cradlepoint.com>
Date: Tue, 29 Mar 2016 11:25:03 -0600
> This is an RFC patch to fix a relatively easily reproducible kernel
> panic related to the all_adj_list handling for netdevs in recent kernels.
>
> This is more to generate discussion than anything else. I don't
> particularly like this approach, I'm hoping someone has a better idea.
>
> The following sequence of commands will reproduce the issue:
>
> ip link add link eth0 name eth0.100 type vlan id 100
> ip link add link eth0 name eth0.200 type vlan id 200
> ip link add name testbr type bridge
> ip link set eth0.100 master testbr
> ip link set eth0.200 master testbr
> ip link add link testbr mac0 type macvlan
> ip link delete dev testbr
>
> This creates an upper/lower tree of (excuse the poor ASCII art):
>
> /---eth0.100-eth0
> mac0-testbr-
> \---eth0.200-eth0
>
> When testbr is deleted, the all_adj_lists are walked, and eth0 is deleted twice from
> the mac0 list. Unfortunately, during setup in __netdev_upper_dev_link, only one
> reference to eth0 is added, so this results in a panic.
>
> This change adds reference count propagation so things are handled properly.
>
> Matthias Schiffer reported a similar crash in batman-adv:
>
> https://github.com/freifunk-gluon/gluon/issues/680
> https://www.open-mesh.org/issues/247
>
> which this patch also seems to resolve.
Veaceslav, please look into this.
Thanks.
^ permalink raw reply
* Re: [net PATCH v2] gro: Allow tunnel stacking in the case of FOU/GUE
From: David Miller @ 2016-03-30 20:03 UTC (permalink / raw)
To: aduyck; +Cc: jesse, netdev, alexander.duyck, tom
In-Reply-To: <20160329215226.12478.3696.stgit@localhost.localdomain>
From: Alexander Duyck <aduyck@mirantis.com>
Date: Tue, 29 Mar 2016 14:55:22 -0700
> This patch should fix the issues seen with a recent fix to prevent
> tunnel-in-tunnel frames from being generated with GRO. The fix itself is
> correct for now as long as we do not add any devices that support
> NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the
> potential to mess things up due to the fact that the outer transport header
> points to the outer UDP header and not the GRE header as would be expected.
>
> Fixes: fac8e0f579695 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
> ---
>
> v2: Dropped switch statements per suggestion of Tom Herbert.
Applied, thanks Alex.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox