* Re: [PATCH 2/3] net/mlx5e: make VXLAN support conditional
From: Saeed Mahameed @ 2016-05-05 16:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Matan Barak, Leon Romanovsky, Saeed Mahameed, Linux Netdev List,
linux-rdma, linux-kernel, David S. Miller, Matthew Finlay,
Richard Cochran, Amir Vadai, Haggai Abramonvsky, Maor Gottlieb,
Or Gerlitz, Majd Dibbiny, Achiad Shochat, Tariq Toukan,
Gal Pressman
In-Reply-To: <1462365116-3856622-1-git-send-email-arnd@arndb.de>
On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> VXLAN can be disabled at compile-time or it can be a loadable
> module while mlx5 is built-in, which leads to a link error:
>
> drivers/net/built-in.o: In function `mlx5e_create_netdev':
> ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
>
> This avoids the link error and makes the vxlan code optional,
> like the other ethernet drivers do as well.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Link: https://patchwork.ozlabs.org/patch/589296/
> Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
> ---
> I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
> reply as saying that he'd fix it up himself. The new version
> should address the original comment.
> ---
Hi Arnd,
I didn't post a fix up since it is not needed anymore, see
b7aade15485a ('vxlan: break dependency with netdev drivers') in
net-next.
The new issue is introduced due to : "net/mlx5: Kconfig: Fix
MLX5_EN/VXLAN build issue" which was merged from net tree.
Dave shouldn't have merged it into net-next, I explicitly asked him
that in the cover letter. Maybe he missed it.
I just checked and It is sufficient to only take the revert patch:
[PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
to net-next.
Can you please confirm that with only the revert patch, you don't see
the issue ?
^ permalink raw reply
* Re: [PATCH net-next 14/14] ip4ip6: Support for GSO/GRO
From: Tom Herbert @ 2016-05-05 16:48 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Eric Dumazet, David Miller, Netdev, Kernel Team
In-Reply-To: <CAKgT0UciiUQMfPodReb3MyX-Y+X9do9vGmz5kwcttQtsLJVRRA@mail.gmail.com>
On Wed, May 4, 2016 at 8:26 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Wed, May 4, 2016 at 6:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Wed, 2016-05-04 at 18:02 -0700, Tom Herbert wrote:
>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>> ---
>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>> index 928b456..6a811fa 100644
>>> --- a/include/linux/skbuff.h
>>> +++ b/include/linux/skbuff.h
>>> @@ -484,6 +484,8 @@ enum {
>>> SKB_GSO_TUNNEL_REMCSUM = 1 << 14,
>>>
>>> SKB_GSO_IP6IP6 = 1 << 15,
>>> +
>>> + SKB_GSO_IP4IP6 = 1 << 16,
>>> };
>>>
>>
>> Houston, we have a problem.
>>
>> gso_type is 16bit (unsigned short), or maybe I missed something ?
>>
>> struct skb_shared_info {
>> unsigned char nr_frags;
>> __u8 tx_flags;
>> unsigned short gso_size;
>> unsigned short gso_segs;
>> unsigned short gso_type; <<-->>
>
> No, I am pretty sure you have it right. We are out of bits.
>
> Also it seems like we are generating a number of duplicate entries.
> What is the difference between IP6IP6 and SIT over IPv6? I'm not
> really seeing the difference.
>
> I'm wondering if maybe we shouldn't look at the possibly using the
> IPIP and SIT bits to instead indicate that the frame is encapsulated
> in an outer IPv4 or outer IPv6 header since we already have TCPV4 and
> TCPV6 to indicate if the inner network type is a V4 or V6. Then there
> is no need for this patch set to introduce any new tunnel types to be
> segmented since all cases should be covered. As far as I can tell
> SKB_GSO_IPIP/SIT were never really being tested against anyway so we
> might want to go the IPIPV4 IPIPV6 route instead as that is probably
> closer to what most device limitations would be.
>
My worry is that the current public interface means IPIP is IPv4 over
IPv4, and SIT means IPv6 over IPv4. There are some drivers advertising
offload support for these so I don't think we safely redefine
SKB_GSO_IPIP/SIT.
For finding more bits in gso_type there are some SKB_GOS_* that are
not really types at all but more flags. I'm going try to turn
SKB_GSO_DODGY into a skbuff for the purposes here. We'll still have
the problem of running out bits next time a new type is added (maybe
SKB_GSO_SCTP?) but can probably make room for one or two more. Longer
term I think the the solution is too eliminate gso_type altogether as
we are once again running into the problem of trying to indicate a
combinatorial set of constraints and complex layering in a just few
flag bits.
Tom
> - Alex
^ permalink raw reply
* Re: mlx5 core/en oops in 4.6-rc6+
From: Doug Ledford @ 2016-05-05 17:16 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: Linux Netdev List
In-Reply-To: <CALzJLG9_PLzU=Qwvv=_3aEd0KQr1c9rZyfcrfuLPo8wF=F_B0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5654 bytes --]
On 05/05/2016 12:42 PM, Saeed Mahameed wrote:
> On Thu, May 5, 2016 at 7:00 PM, Doug Ledford <dledford@redhat.com> wrote:
>> Just had this pop up during testing, happened very soon after bootup:
>>
[ snip oops ]
> Hi Doug,
>
> did you by change configure TC queues for the netdev ? i.e. dev->num_tc > 1
> if not i would be happy to get more info in you network configuration.
That depends on which interface actually generated the oops. If it was
the base interface, then I don't manually set any special params on it.
If it's one of the vlan interfaces, then there is a NetworkManager
dispatcher script that is intended to set the tc count on interface up:
[root@rdma-virt-03 ~]$ more /etc/NetworkManager/dispatcher.d/98-mlx5_roce.4*
::::::::::::::
/etc/NetworkManager/dispatcher.d/98-mlx5_roce.43-egress.conf
::::::::::::::
#!/bin/sh
interface=$1
status=$2
[ "$interface" = mlx5_roce.43 ] || exit 0
case $status in
up)
tc qdisc add dev mlx5_roce root mqprio num_tc 8 map 5 5 5 5 5 5 5 5 5 5
5 5 5 5 5 5
# tc_wrap.py -i mlx5_roce -u 5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
;;
esac
--More--(Next file:
/etc/NetworkManager/dispatcher.d/98-mlx5_roce.45-egress.conf::::::::::::::
/etc/NetworkManager/dispatcher.d/98-mlx5_roce.45-egress.conf
::::::::::::::
#!/bin/sh
interface=$1
status=$2
[ "$interface" = mlx5_roce.45 ] || exit 0
case $status in
up)
tc qdisc add dev mlx5_roce root mqprio num_tc 8 map 5 5 5 5 5 5 5 5 5 5
5 5 5 5 5 5
# tc_wrap.py -i mlx5_roce -u 5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
;;
esac
[root@rdma-virt-03 ~]$
However, I should note that this usage of tc is a bit out of date last I
checked and doesn't even work any more. Let me double check...
[root@rdma-virt-02 vlan]$ cd /proc/net/vlan/
[root@rdma-virt-02 vlan]$ ls
config mlx5_roce.43 mlx5_roce.45
[root@rdma-virt-02 vlan]$
[root@rdma-virt-02 vlan]$ for i in *; do echo "$i:"; cat $i; echo; done
config:
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
mlx5_roce.45 | 45 | mlx5_roce
mlx5_roce.43 | 43 | mlx5_roce
mlx5_roce.43:
mlx5_roce.43 VID: 43 REORDER_HDR: 1 dev->priv_flags: 1001
total frames received 57
total bytes received 5010
Broadcast/Multicast Rcvd 0
total frames transmitted 20
total bytes transmitted 2525
Device: mlx5_roce
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:3 1:3 2:3 3:3 4:3 5:3 6:3 7:3
mlx5_roce.45:
mlx5_roce.45 VID: 45 REORDER_HDR: 1 dev->priv_flags: 1001
total frames received 57
total bytes received 5010
Broadcast/Multicast Rcvd 0
total frames transmitted 21
total bytes transmitted 2603
Device: mlx5_roce
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5
OK, so the vlans have egress mappings, but they don't match what the
mlx5_roce.43 egress.conf file should have enabled. Digging a little
further on this machine:
[root@rdma-virt-03 vlan]$ more
/etc/sysconfig/network-scripts/ifcfg-mlx5_roce.4?
::::::::::::::
/etc/sysconfig/network-scripts/ifcfg-mlx5_roce.43
::::::::::::::
DEVICE=mlx5_roce.43
VLAN=yes
VLAN_ID=43
VLAN_EGRESS_PRIORITY_MAP=0:3,1:3,2:3,3:3,4:3,5:3,6:3,7:3
TYPE=Vlan
ONBOOT=yes
BOOTPROTO=dhcp
DEFROUTE=no
PEERDNS=no
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=no
IPV6_PEERDNS=no
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=mlx5_roce.43
::::::::::::::
/etc/sysconfig/network-scripts/ifcfg-mlx5_roce.45
::::::::::::::
DEVICE=mlx5_roce.45
VLAN=yes
VLAN_ID=45
VLAN_EGRESS_PRIORITY_MAP=0:5,1:5,2:5,3:5,4:5,5:5,6:5,7:5
TYPE=Vlan
ONBOOT=yes
BOOTPROTO=dhcp
DEFROUTE=no
PEERDNS=no
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=no
IPV6_PEERDNS=no
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=mlx5_roce.45
[root@rdma-virt-03 vlan]$
This is a Fedora rawhide machine, using NetworkManager to handle the
network interfaces. So, the egress priority mappings are being set by
NM. I don't know if they are overriding the egress mapping dispatchers
or if the egress mapping dispatchers are failing to work/run properly.
It might be the latter. Let me double check the command...
OK, re-reading the egress dispatchers above, they work on the base
interface, not on the vlan interface that triggers them. That's why
they both use the same command (mapping to egress 5) instead of being
like the ifcfg files, which map the 43 vlan to egress priority 3, and
the 45 vlan to egress priority 5. Running tc qdisc | grep mlx5_roce
shows that the egress mapping is being applied (although I'm not sure it
should be...I made that mapping many kernels ago when that was the right
thing to do, the modern mlx5 ethernet drivers create their own mappings
that are drastically different).
So, to answer your question, yes, num_tc > 1, num_tc == 8, and I
probably need to reconfigure that egress dispatcher to do what I want it
to do (which is merely to make sure that all packets from specific
interfaces are tagged with specific vlan priorities so per-priority flow
control between the card and switch works properly, the base interface
is supposed to have no priority tag, the 43 vlan is supposed to have
priority tag 3, and vlan 45 is supposed to have priority tag 5) on
modern kernels.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* [PATCH] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring
From: Wang YanQing @ 2016-05-05 17:19 UTC (permalink / raw)
To: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
Cc: chaoming_li-kXabqFNEczNtrwSWzY7KCg, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
We can't use kfree_skb in irq disable context, because spin_lock_irqsave
make sure we are always in irq disable context, use dev_kfree_skb_irq
instead of kfree_skb is better than dev_kfree_skb_any.
This patch fix below kernel warning:
[ 7612.095528] ------------[ cut here ]------------
[ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
[ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
[ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G W 4.4.0+ #4
[ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
[ 7612.095574] 00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
[ 7612.095584] 00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
[ 7612.095594] f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
[ 7612.095604] Call Trace:
[ 7612.095614] [<c12ce7c5>] dump_stack+0x41/0x5c
[ 7612.095620] [<c104cc59>] warn_slowpath_common+0x89/0xc0
[ 7612.095628] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095634] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
[ 7612.095640] [<c104ccad>] warn_slowpath_null+0x1d/0x20
[ 7612.095646] [<c10508a8>] __local_bh_enable_ip+0x58/0x80
[ 7612.095653] [<c16b7d34>] destroy_conntrack+0x64/0xa0
[ 7612.095660] [<c16b300f>] nf_conntrack_destroy+0xf/0x20
[ 7612.095665] [<c1677565>] skb_release_head_state+0x55/0xa0
[ 7612.095670] [<c16775bb>] skb_release_all+0xb/0x20
[ 7612.095674] [<c167760b>] __kfree_skb+0xb/0x60
[ 7612.095679] [<c16776f0>] kfree_skb+0x30/0x70
[ 7612.095686] [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095692] [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
[ 7612.095698] [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
[ 7612.095705] [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
[ 7612.095712] [<c17e3f16>] drv_start+0x36/0xc0
[ 7612.095717] [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
[ 7612.095725] [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
[ 7612.095730] [<c17f60bd>] ieee80211_open+0x4d/0x50
[ 7612.095736] [<c16891b3>] __dev_open+0xa3/0x130
[ 7612.095742] [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
[ 7612.095748] [<c1689499>] __dev_change_flags+0x89/0x140
[ 7612.095753] [<c127c70d>] ? selinux_capable+0xd/0x10
[ 7612.095759] [<c1689589>] dev_change_flags+0x29/0x60
[ 7612.095765] [<c1700b93>] devinet_ioctl+0x553/0x670
[ 7612.095772] [<c12db758>] ? _copy_to_user+0x28/0x40
[ 7612.095777] [<c17018b5>] inet_ioctl+0x85/0xb0
[ 7612.095783] [<c166e647>] sock_ioctl+0x67/0x260
[ 7612.095788] [<c166e5e0>] ? sock_fasync+0x80/0x80
[ 7612.095795] [<c115c99b>] do_vfs_ioctl+0x6b/0x550
[ 7612.095800] [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
[ 7612.095807] [<c10a8914>] ? timekeeping_suspend+0x294/0x320
[ 7612.095813] [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
[ 7612.095820] [<c1276e24>] ? security_file_ioctl+0x34/0x50
[ 7612.095827] [<c115cef0>] SyS_ioctl+0x70/0x80
[ 7612.095832] [<c1001804>] do_fast_syscall_32+0x84/0x120
[ 7612.095839] [<c183ff91>] sysenter_past_esp+0x36/0x55
[ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
Signed-off-by: Wang YanQing <udknight-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..99a3a03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
true,
HW_DESC_TXBUFF_ADDR),
skb->len, PCI_DMA_TODEVICE);
- kfree_skb(skb);
+ dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
ring->idx = 0;
--
1.8.5.6.2.g3d8a54e.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v9 net-next 3/7] openvswitch: add support to push and pop mpls for layer3 packets
From: pravin shelar @ 2016-05-05 17:35 UTC (permalink / raw)
To: Simon Horman; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <1462347393-22354-4-git-send-email-simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
On Wed, May 4, 2016 at 12:36 AM, Simon Horman
<simon.horman@netronome.com> wrote:
> Allow push and pop mpls actions to act on layer 3 packets by teaching
> them not to access non-existent L2 headers of such packets.
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
> v9
> * New Patch
> ---
> net/openvswitch/actions.c | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 879185fe183f..fe885a89f501 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -160,8 +160,10 @@ static int push_mpls(struct sk_buff *skb, struct sw_flow_key *key,
>
> skb_postpush_rcsum(skb, new_mpls_lse, MPLS_HLEN);
>
> - hdr = eth_hdr(skb);
> - hdr->h_proto = mpls->mpls_ethertype;
> + if (skb->mac_len) {
can you move hdr definition to this block?
> + hdr = eth_hdr(skb);
> + hdr->h_proto = mpls->mpls_ethertype;
> + }
>
We need to update skb checksum here. This bug is not related to your
patch. since you are changing this code can you also fix this?
> if (!skb->inner_protocol)
> skb_set_inner_protocol(skb, skb->protocol);
> @@ -174,7 +176,6 @@ static int push_mpls(struct sk_buff *skb, struct sw_flow_key *key,
> static int pop_mpls(struct sk_buff *skb, struct sw_flow_key *key,
> const __be16 ethertype)
> {
> - struct ethhdr *hdr;
> int err;
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support
From: pravin shelar @ 2016-05-05 17:37 UTC (permalink / raw)
To: Simon Horman; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <1462347393-22354-5-git-send-email-simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
On Wed, May 4, 2016 at 12:36 AM, Simon Horman
<simon.horman@netronome.com> wrote:
> From: Lorand Jakab <lojakab@cisco.com>
>
> Implementation of the pop_eth and push_eth actions in the kernel, and
> layer 3 flow support.
>
> This doesn't actually do anything yet as no layer 2 tunnel ports are
> supported yet. The original patch by Lorand was against the Open vSwtich
> tree which has L2 LISP tunnels but that is not supported in mainline Linux.
> I (Simon) plan to follow up with support for non-TEB GRE ports based on
> work by Thomas Morin.
>
> Cc: Thomas Morin <thomas.morin@orange.com>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
>
> ---
...
> diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
> index 0ea128eeeab2..6e174ea5f2bb 100644
> --- a/net/openvswitch/flow.c
> +++ b/net/openvswitch/flow.c
> @@ -468,28 +468,31 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
>
> skb_reset_mac_header(skb);
>
> - /* Link layer. We are guaranteed to have at least the 14 byte Ethernet
> - * header in the linear data area.
> - */
> - eth = eth_hdr(skb);
> - ether_addr_copy(key->eth.src, eth->h_source);
> - ether_addr_copy(key->eth.dst, eth->h_dest);
> + /* Link layer. */
> + if (key->phy.is_layer3) {
> + key->eth.tci = 0;
> + key->eth.type = skb->protocol;
> + } else {
> + eth = eth_hdr(skb);
> + ether_addr_copy(key->eth.src, eth->h_source);
> + ether_addr_copy(key->eth.dst, eth->h_dest);
>
> - __skb_pull(skb, 2 * ETH_ALEN);
> - /* We are going to push all headers that we pull, so no need to
> - * update skb->csum here.
> - */
> + __skb_pull(skb, 2 * ETH_ALEN);
> + /* We are going to push all headers that we pull, so no need to
> + * update skb->csum here.
> + */
>
> - key->eth.tci = 0;
> - if (skb_vlan_tag_present(skb))
> - key->eth.tci = htons(skb->vlan_tci);
> - else if (eth->h_proto == htons(ETH_P_8021Q))
> - if (unlikely(parse_vlan(skb, key)))
> - return -ENOMEM;
> + key->eth.tci = 0;
> + if (skb_vlan_tag_present(skb))
> + key->eth.tci = htons(skb->vlan_tci);
> + else if (eth->h_proto == htons(ETH_P_8021Q))
> + if (unlikely(parse_vlan(skb, key)))
> + return -ENOMEM;
>
> - key->eth.type = parse_ethertype(skb);
> - if (unlikely(key->eth.type == htons(0)))
> - return -ENOMEM;
> + key->eth.type = parse_ethertype(skb);
> + if (unlikely(key->eth.type == htons(0)))
> + return -ENOMEM;
> + }
>
> skb_reset_network_header(skb);
> skb_reset_mac_len(skb);
> @@ -696,11 +699,23 @@ int ovs_flow_key_update(struct sk_buff *skb, struct sw_flow_key *key)
> int ovs_flow_key_extract(const struct ip_tunnel_info *tun_info,
> struct sk_buff *skb, struct sw_flow_key *key)
> {
> + bool is_layer3 = false;
> + bool is_teb = false;
is_layer3 and is_teb are mutually exclusive, so can't we use single
boolean here?
> + int err;
> +
> /* Extract metadata from packet. */
> if (tun_info) {
> key->tun_proto = ip_tunnel_info_af(tun_info);
> memcpy(&key->tun_key, &tun_info->key, sizeof(key->tun_key));
>
> + if (OVS_CB(skb)->input_vport->dev->type != ARPHRD_ETHER) {
> + if (skb->protocol == htons(ETH_P_TEB))
> + is_teb = true;
> + else
> + is_layer3 = true;
> + }
> +
On transmit side you are using mac_len to detect l3 packet, why not do
same while extracting the key?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 3/3] net-next: mediatek: add RX delay support
From: John Crispin @ 2016-05-05 17:37 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linux-mediatek, David S. Miller, linux-kernel, nbd
In-Reply-To: <20160505121353.GE7972@lunn.ch>
On 05/05/2016 14:13, Andrew Lunn wrote:
> On Thu, May 05, 2016 at 11:17:36AM +0200, John Crispin wrote:
>> If an external Gigabit PHY is connected to either of the MACs we need to
>> tell the to use a RX delay. Not doing so will result in heavy packet loss
>> and/or data corruption of RX traffic.
>
> Hi John
>
> Is this comment correct? Reading the code, all this switch statement
> does is select between RGMII, MII and RMII. It has nothing to do with
> delay. I suspect the PHY is doing the delay, not the MAC, since you
> pass the phy mode to of_phy_connect().
>
> If my interpretation of the code is correct, you might also want to
> handle PHY_INTERFACE_MODE_RGMII_TXID and PHY_INTERFACE_MODE_RGMII_ID
> which are also RGMII modes.
>
> Andrew
Hi Andrew,
the comment is indeed incorrect and the PHY needs to handle the delay. i
will send a V2 and also add _TXID and _ID
John
^ permalink raw reply
* Re: [PATCH net-next 14/14] ip4ip6: Support for GSO/GRO
From: Alexander Duyck @ 2016-05-05 17:48 UTC (permalink / raw)
To: Tom Herbert; +Cc: Eric Dumazet, David Miller, Netdev, Kernel Team
In-Reply-To: <CALx6S37w8526zZNLbguatYkDv63iJaGyht2BYCfym=-XoPTxEw@mail.gmail.com>
On Thu, May 5, 2016 at 9:48 AM, Tom Herbert <tom@herbertland.com> wrote:
> On Wed, May 4, 2016 at 8:26 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Wed, May 4, 2016 at 6:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Wed, 2016-05-04 at 18:02 -0700, Tom Herbert wrote:
>>>> Signed-off-by: Tom Herbert <tom@herbertland.com>
>>>> ---
>>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>>> index 928b456..6a811fa 100644
>>>> --- a/include/linux/skbuff.h
>>>> +++ b/include/linux/skbuff.h
>>>> @@ -484,6 +484,8 @@ enum {
>>>> SKB_GSO_TUNNEL_REMCSUM = 1 << 14,
>>>>
>>>> SKB_GSO_IP6IP6 = 1 << 15,
>>>> +
>>>> + SKB_GSO_IP4IP6 = 1 << 16,
>>>> };
>>>>
>>>
>>> Houston, we have a problem.
>>>
>>> gso_type is 16bit (unsigned short), or maybe I missed something ?
>>>
>>> struct skb_shared_info {
>>> unsigned char nr_frags;
>>> __u8 tx_flags;
>>> unsigned short gso_size;
>>> unsigned short gso_segs;
>>> unsigned short gso_type; <<-->>
>>
>> No, I am pretty sure you have it right. We are out of bits.
>>
>> Also it seems like we are generating a number of duplicate entries.
>> What is the difference between IP6IP6 and SIT over IPv6? I'm not
>> really seeing the difference.
>>
>> I'm wondering if maybe we shouldn't look at the possibly using the
>> IPIP and SIT bits to instead indicate that the frame is encapsulated
>> in an outer IPv4 or outer IPv6 header since we already have TCPV4 and
>> TCPV6 to indicate if the inner network type is a V4 or V6. Then there
>> is no need for this patch set to introduce any new tunnel types to be
>> segmented since all cases should be covered. As far as I can tell
>> SKB_GSO_IPIP/SIT were never really being tested against anyway so we
>> might want to go the IPIPV4 IPIPV6 route instead as that is probably
>> closer to what most device limitations would be.
>>
> My worry is that the current public interface means IPIP is IPv4 over
> IPv4, and SIT means IPv6 over IPv4. There are some drivers advertising
> offload support for these so I don't think we safely redefine
> SKB_GSO_IPIP/SIT.
The group is pretty small, and they all advertise support for SIT and
IPIP. Even if they don't support an outer IPv6 tunnel it just means
we are essentially combining the 2 bits into 1.
In the case of the Intel drivers that advertise support for it they
could support the change without any issue since the use the header
pointers to set the offsets of the inner and outer headers and don't
care if they are v4 or v6.
> For finding more bits in gso_type there are some SKB_GOS_* that are
> not really types at all but more flags. I'm going try to turn
> SKB_GSO_DODGY into a skbuff for the purposes here. We'll still have
> the problem of running out bits next time a new type is added (maybe
> SKB_GSO_SCTP?) but can probably make room for one or two more. Longer
> term I think the the solution is too eliminate gso_type altogether as
> we are once again running into the problem of trying to indicate a
> combinatorial set of constraints and complex layering in a just few
> flag bits.
Still, I don't think there is much gain to be had by specifying the
inner network type twice, once in the outer tunnel segmentation type,
and then again in the inner TCP segmentation type. That is why I was
thinking it would be better to just specify an IPIPV4 and IPIPV6 since
then you can run v4 or v6 on the inside and let TSOV4 or TSOV6 in the
hw_enc_features take care of specifying if you can support inner IPV6
or not.
- Alex
^ permalink raw reply
* Re: [PATCH 2/3] net/mlx5e: make VXLAN support conditional
From: Arnd Bergmann @ 2016-05-05 18:09 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Matan Barak, Leon Romanovsky, Saeed Mahameed, Linux Netdev List,
linux-rdma, linux-kernel, David S. Miller, Matthew Finlay,
Richard Cochran, Amir Vadai, Haggai Abramonvsky, Maor Gottlieb,
Or Gerlitz, Majd Dibbiny, Achiad Shochat, Tariq Toukan,
Gal Pressman
In-Reply-To: <CALzJLG885q-Nm4xD3FobvY4A9RhLAV3jLwfAWdJwyDOid+tJ6g@mail.gmail.com>
On Thursday 05 May 2016 19:44:36 Saeed Mahameed wrote:
> On Wed, May 4, 2016 at 3:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > VXLAN can be disabled at compile-time or it can be a loadable
> > module while mlx5 is built-in, which leads to a link error:
> >
> > drivers/net/built-in.o: In function `mlx5e_create_netdev':
> > ntb_netdev.c:(.text+0x106de4): undefined reference to `vxlan_get_rx_port'
> >
> > This avoids the link error and makes the vxlan code optional,
> > like the other ethernet drivers do as well.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Link: https://patchwork.ozlabs.org/patch/589296/
> > Fixes: b3f63c3d5e2c ("net/mlx5e: Add netdev support for VXLAN tunneling")
> > ---
> > I sent it originally on Feb 26 2016, but misread Saeed Mahameed's
> > reply as saying that he'd fix it up himself. The new version
> > should address the original comment.
> > ---
>
> Hi Arnd,
>
> I didn't post a fix up since it is not needed anymore, see
> b7aade15485a ('vxlan: break dependency with netdev drivers') in
> net-next.
>
> The new issue is introduced due to : "net/mlx5: Kconfig: Fix
> MLX5_EN/VXLAN build issue" which was merged from net tree.
>
> Dave shouldn't have merged it into net-next, I explicitly asked him
> that in the cover letter. Maybe he missed it.
>
> I just checked and It is sufficient to only take the revert patch:
> [PATCH 1/3] Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
> to net-next.
>
> Can you please confirm that with only the revert patch, you don't see
> the issue ?
Yes, it works, but not it is different from all the other drivers
(MLX4, BENET, IXGBE, I40E, FM10K, QLCNIC, and QEDE). If the 'select
VXLAN' is not the preferred way to handle this, we should change
the other ones the same way, right?
For reference, I've tried it out on the MLX4 driver, and it does
seem nicer that way, see below.
Arnd
---
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
in case someone wants to pick up that patch and do the other
ones as well.
diff --git a/drivers/net/ethernet/mellanox/mlx4/Kconfig b/drivers/net/ethernet/mellanox/mlx4/Kconfig
index 9ca3734ebb6b..88fff4484200 100644
--- a/drivers/net/ethernet/mellanox/mlx4/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx4/Kconfig
@@ -6,6 +6,7 @@ config MLX4_EN
tristate "Mellanox Technologies 1/10/40Gbit Ethernet support"
depends on MAY_USE_DEVLINK
depends on PCI
+ select VXLAN
select MLX4_CORE
select PTP_1588_CLOCK
---help---
@@ -24,13 +25,6 @@ config MLX4_EN_DCB
If unsure, set to Y
-config MLX4_EN_VXLAN
- bool "VXLAN offloads Support"
- default y
- depends on MLX4_EN && VXLAN && !(MLX4_EN=y && VXLAN=m)
- ---help---
- Say Y here if you want to use VXLAN offloads in the driver.
-
config MLX4_CORE
tristate
depends on PCI
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 6f28ac58251c..ad887c425f2d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1691,10 +1691,8 @@ int mlx4_en_start_port(struct net_device *dev)
/* Schedule multicast task to populate multicast list */
queue_work(mdev->workqueue, &priv->rx_mode_task);
-#ifdef CONFIG_MLX4_EN_VXLAN
if (priv->mdev->dev->caps.tunnel_offload_mode == MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
vxlan_get_rx_port(dev);
-#endif
priv->port_up = true;
netif_tx_start_all_queues(dev);
netif_device_attach(dev);
@@ -2337,7 +2335,6 @@ static int mlx4_en_get_phys_port_id(struct net_device *dev,
return 0;
}
-#ifdef CONFIG_MLX4_EN_VXLAN
static void mlx4_en_add_vxlan_offloads(struct work_struct *work)
{
int ret;
@@ -2448,7 +2445,6 @@ static netdev_features_t mlx4_en_features_check(struct sk_buff *skb,
return features;
}
-#endif
static int mlx4_en_set_tx_maxrate(struct net_device *dev, int queue_index, u32 maxrate)
{
@@ -2501,11 +2497,9 @@ static const struct net_device_ops mlx4_netdev_ops = {
.ndo_rx_flow_steer = mlx4_en_filter_rfs,
#endif
.ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
-#ifdef CONFIG_MLX4_EN_VXLAN
.ndo_add_vxlan_port = mlx4_en_add_vxlan_port,
.ndo_del_vxlan_port = mlx4_en_del_vxlan_port,
.ndo_features_check = mlx4_en_features_check,
-#endif
.ndo_set_tx_maxrate = mlx4_en_set_tx_maxrate,
};
@@ -2539,11 +2533,9 @@ static const struct net_device_ops mlx4_netdev_ops_master = {
.ndo_rx_flow_steer = mlx4_en_filter_rfs,
#endif
.ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
-#ifdef CONFIG_MLX4_EN_VXLAN
.ndo_add_vxlan_port = mlx4_en_add_vxlan_port,
.ndo_del_vxlan_port = mlx4_en_del_vxlan_port,
.ndo_features_check = mlx4_en_features_check,
-#endif
.ndo_set_tx_maxrate = mlx4_en_set_tx_maxrate,
};
@@ -2834,10 +2826,8 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
INIT_WORK(&priv->linkstate_task, mlx4_en_linkstate);
INIT_DELAYED_WORK(&priv->stats_task, mlx4_en_do_get_stats);
INIT_DELAYED_WORK(&priv->service_task, mlx4_en_service_task);
-#ifdef CONFIG_MLX4_EN_VXLAN
INIT_WORK(&priv->vxlan_add_task, mlx4_en_add_vxlan_offloads);
INIT_WORK(&priv->vxlan_del_task, mlx4_en_del_vxlan_offloads);
-#endif
#ifdef CONFIG_RFS_ACCEL
INIT_LIST_HEAD(&priv->filters);
spin_lock_init(&priv->filters_lock);
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 63b1aeae2c03..cbab8741d60f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -546,10 +546,8 @@ struct mlx4_en_priv {
struct work_struct linkstate_task;
struct delayed_work stats_task;
struct delayed_work service_task;
-#ifdef CONFIG_MLX4_EN_VXLAN
struct work_struct vxlan_add_task;
struct work_struct vxlan_del_task;
-#endif
struct mlx4_en_perf_stats pstats;
struct mlx4_en_pkt_stats pkstats;
struct mlx4_en_counter_stats pf_stats;
^ permalink raw reply related
* Re: [PATCH] VSOCK: do not disconnect socket when peer has shutdown SEND only
From: Stefan Hajnoczi @ 2016-05-05 18:23 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David S. Miller, Claudio Imbrenda, Andy King,
Dmitry Torokhov, Jorgen Hansen, Adit Ranadive
In-Reply-To: <1462368113-5493-1-git-send-email-ian.campbell@docker.com>
[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]
On Wed, May 04, 2016 at 02:21:53PM +0100, Ian Campbell wrote:
> The peer may be expecting a reply having sent a request and then done a
> shutdown(SHUT_WR), so tearing down the whole socket at this point seems
> wrong and breaks for me with a client which does a SHUT_WR.
>
> Looking at other socket family's stream_recvmsg callbacks doing a shutdown
> here does not seem to be the norm and removing it does not seem to have
> had any adverse effects that I can see.
Seems fine to me.
> I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
> on the vmci transport.
>
> Signed-off-by: Ian Campbell <ian.campbell@docker.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
> Cc: Andy King <acking@vmware.com>
> Cc: Dmitry Torokhov <dtor@vmware.com>
> Cc: Jorgen Hansen <jhansen@vmware.com>
> Cc: Adit Ranadive <aditr@vmware.com>
> Cc: netdev@vger.kernel.org
> ---
> net/vmw_vsock/af_vsock.c | 21 +--------------------
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index 1e5f5ed..7a25150 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -1789,27 +1789,8 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
> else if (sk->sk_shutdown & RCV_SHUTDOWN)
> err = 0;
>
> - if (copied > 0) {
> - /* We only do these additional bookkeeping/notification steps
> - * if we actually copied something out of the queue pair
> - * instead of just peeking ahead.
> - */
> -
> - if (!(flags & MSG_PEEK)) {
> - /* If the other side has shutdown for sending and there
> - * is nothing more to read, then modify the socket
> - * state.
> - */
> - if (vsk->peer_shutdown & SEND_SHUTDOWN) {
> - if (vsock_stream_has_data(vsk) <= 0) {
> - sk->sk_state = SS_UNCONNECTED;
> - sock_set_flag(sk, SOCK_DONE);
> - sk->sk_state_change(sk);
> - }
> - }
> - }
> + if (copied > 0)
> err = copied;
> - }
>
> out:
> release_sock(sk);
> --
> 2.8.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring
From: Larry Finger @ 2016-05-05 19:25 UTC (permalink / raw)
To: Wang YanQing, chaoming_li-kXabqFNEczNtrwSWzY7KCg,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160505171904.GA16619@udknight>
On 05/05/2016 12:19 PM, Wang YanQing wrote:
> We can't use kfree_skb in irq disable context, because spin_lock_irqsave
> make sure we are always in irq disable context, use dev_kfree_skb_irq
> instead of kfree_skb is better than dev_kfree_skb_any.
>
> This patch fix below kernel warning:
> [ 7612.095528] ------------[ cut here ]------------
> [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
> [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
> [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G W 4.4.0+ #4
> [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
> [ 7612.095574] 00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
> [ 7612.095584] 00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
> [ 7612.095594] f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
> [ 7612.095604] Call Trace:
> [ 7612.095614] [<c12ce7c5>] dump_stack+0x41/0x5c
> [ 7612.095620] [<c104cc59>] warn_slowpath_common+0x89/0xc0
> [ 7612.095628] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
> [ 7612.095634] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
> [ 7612.095640] [<c104ccad>] warn_slowpath_null+0x1d/0x20
> [ 7612.095646] [<c10508a8>] __local_bh_enable_ip+0x58/0x80
> [ 7612.095653] [<c16b7d34>] destroy_conntrack+0x64/0xa0
> [ 7612.095660] [<c16b300f>] nf_conntrack_destroy+0xf/0x20
> [ 7612.095665] [<c1677565>] skb_release_head_state+0x55/0xa0
> [ 7612.095670] [<c16775bb>] skb_release_all+0xb/0x20
> [ 7612.095674] [<c167760b>] __kfree_skb+0xb/0x60
> [ 7612.095679] [<c16776f0>] kfree_skb+0x30/0x70
> [ 7612.095686] [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
> [ 7612.095692] [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
> [ 7612.095698] [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
> [ 7612.095705] [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
> [ 7612.095712] [<c17e3f16>] drv_start+0x36/0xc0
> [ 7612.095717] [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
> [ 7612.095725] [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
> [ 7612.095730] [<c17f60bd>] ieee80211_open+0x4d/0x50
> [ 7612.095736] [<c16891b3>] __dev_open+0xa3/0x130
> [ 7612.095742] [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
> [ 7612.095748] [<c1689499>] __dev_change_flags+0x89/0x140
> [ 7612.095753] [<c127c70d>] ? selinux_capable+0xd/0x10
> [ 7612.095759] [<c1689589>] dev_change_flags+0x29/0x60
> [ 7612.095765] [<c1700b93>] devinet_ioctl+0x553/0x670
> [ 7612.095772] [<c12db758>] ? _copy_to_user+0x28/0x40
> [ 7612.095777] [<c17018b5>] inet_ioctl+0x85/0xb0
> [ 7612.095783] [<c166e647>] sock_ioctl+0x67/0x260
> [ 7612.095788] [<c166e5e0>] ? sock_fasync+0x80/0x80
> [ 7612.095795] [<c115c99b>] do_vfs_ioctl+0x6b/0x550
> [ 7612.095800] [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
> [ 7612.095807] [<c10a8914>] ? timekeeping_suspend+0x294/0x320
> [ 7612.095813] [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
> [ 7612.095820] [<c1276e24>] ? security_file_ioctl+0x34/0x50
> [ 7612.095827] [<c115cef0>] SyS_ioctl+0x70/0x80
> [ 7612.095832] [<c1001804>] do_fast_syscall_32+0x84/0x120
> [ 7612.095839] [<c183ff91>] sysenter_past_esp+0x36/0x55
> [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
>
> Signed-off-by: Wang YanQing <udknight-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index 1ac41b8..99a3a03 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -1572,7 +1572,7 @@ int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw)
> true,
> HW_DESC_TXBUFF_ADDR),
> skb->len, PCI_DMA_TODEVICE);
> - kfree_skb(skb);
> + dev_kfree_skb_irq(skb);
> ring->idx = (ring->idx + 1) % ring->entries;
> }
> ring->idx = 0;
>
I am currently testing this patch. It looks OK, but during my first test, I got
a system crash that was not captured. As I was testing some other things, your
patch may not have been at fault and I am now testing with only that one change.
By the way, I have never seen the warning that you posted. I always use 64-bit
Linux, and that may be the difference.
Once I finish my testing, I will ack or nack.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE
From: Jiri Benc @ 2016-05-05 19:31 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo; +Cc: netdev, Simon Horman
In-Reply-To: <1462466204-3534-1-git-send-email-cascardo@redhat.com>
On Thu, 5 May 2016 13:36:44 -0300, Thadeu Lima de Souza Cascardo wrote:
> Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
> to allow GPE interfaces to be added as openvswitch ports.
What's wrong with ARPHRD_NONE? I don't think we need a separate type
for VXLAN-GPE. Just use ARPHRD_NONE in ovs and things should work, for
all ARPHRD_NONE interfaces as a bonus.
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
> Cc: Jiri Benc <jbenc@redhat.com>
> Cc: Simon Horman <simon.horman@netronome.com>
You did not CC me nor Simon :-)
Jiri
^ permalink raw reply
* [PATCH net-next 0/2] net: vrf: Fixup PKTINFO to return enslaved device index
From: David Ahern @ 2016-05-05 19:37 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
Applications such as OSPF and BFD need the original ingress device not
the VRF device; the latter can be derived from the former. To that end
move the packet intercept from an rx handler that is invoked by
__netif_receive_skb_core to the ipv4 and ipv6 receive processing.
IPv6 already saves the skb_iif to the control buffer in ipv6_rcv. Since
the skb->dev has not been switched the cb has the enslaved device. Make
the same happen for IPv4 by adding the skb_iif to inet_skb_parm and set
it in ipv4 code after clearing the skb control buffer similar to IPv6.
>From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB
cast.
David Ahern (2):
net: l3mdev: Add hook in ip and ipv6
net: original ingress device index in PKTINFO
drivers/net/vrf.c | 186 ++++++++++++++++++++++------------------------
include/linux/ipv6.h | 3 +-
include/linux/netdevice.h | 2 +
include/net/ip.h | 1 +
include/net/l3mdev.h | 43 +++++++++++
include/net/tcp.h | 3 +-
net/core/dev.c | 3 +-
net/ipv4/ip_input.c | 8 ++
net/ipv4/ip_sockglue.c | 7 +-
net/ipv6/ip6_input.c | 7 ++
10 files changed, 161 insertions(+), 102 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH net-next 1/2] net: l3mdev: Add hook in ip and ipv6
From: David Ahern @ 2016-05-05 19:37 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1462477063-21699-1-git-send-email-dsa@cumulusnetworks.com>
Currently the VRF driver uses the rx_handler to switch the skb device
to the VRF device. Switching the dev prior to the ip / ipv6 layer
means the VRF driver has to duplicate IP/IPv6 processing which adds
overhead and makes features such as retaining the ingress device index
more complicated than necessary.
This patch moves the hook to the L3 layer just after the first NF_HOOK
for PRE_ROUTING. This location makes exposing the original ingress device
trivial (next patch) and allows adding other NF_HOOKs to the VRF driver
in the future.
dev_queue_xmit_nit is exported so that the VRF driver can cycle the skb
with the switched device through the packet taps to maintain current
behavior (tcpdump can be used on either the vrf device or the enslaved
devices).
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
drivers/net/vrf.c | 186 ++++++++++++++++++++++------------------------
include/linux/ipv6.h | 3 +-
include/linux/netdevice.h | 2 +
include/net/l3mdev.h | 43 +++++++++++
include/net/tcp.h | 3 +-
net/core/dev.c | 3 +-
net/ipv4/ip_input.c | 7 ++
net/ipv6/ip6_input.c | 7 ++
8 files changed, 153 insertions(+), 101 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 8a8f1e58b415..08e06f1d227a 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -42,9 +42,6 @@
#define DRV_NAME "vrf"
#define DRV_VERSION "1.0"
-#define vrf_master_get_rcu(dev) \
- ((struct net_device *)rcu_dereference(dev->rx_handler_data))
-
struct net_vrf {
struct rtable *rth;
struct rt6_info *rt6;
@@ -60,90 +57,12 @@ struct pcpu_dstats {
struct u64_stats_sync syncp;
};
-/* neighbor handling is done with actual device; do not want
- * to flip skb->dev for those ndisc packets. This really fails
- * for multiple next protocols (e.g., NEXTHDR_HOP). But it is
- * a start.
- */
-#if IS_ENABLED(CONFIG_IPV6)
-static bool check_ipv6_frame(const struct sk_buff *skb)
-{
- const struct ipv6hdr *ipv6h;
- struct ipv6hdr _ipv6h;
- bool rc = true;
-
- ipv6h = skb_header_pointer(skb, 0, sizeof(_ipv6h), &_ipv6h);
- if (!ipv6h)
- goto out;
-
- if (ipv6h->nexthdr == NEXTHDR_ICMP) {
- const struct icmp6hdr *icmph;
- struct icmp6hdr _icmph;
-
- icmph = skb_header_pointer(skb, sizeof(_ipv6h),
- sizeof(_icmph), &_icmph);
- if (!icmph)
- goto out;
-
- switch (icmph->icmp6_type) {
- case NDISC_ROUTER_SOLICITATION:
- case NDISC_ROUTER_ADVERTISEMENT:
- case NDISC_NEIGHBOUR_SOLICITATION:
- case NDISC_NEIGHBOUR_ADVERTISEMENT:
- case NDISC_REDIRECT:
- rc = false;
- break;
- }
- }
-
-out:
- return rc;
-}
-#else
-static bool check_ipv6_frame(const struct sk_buff *skb)
-{
- return false;
-}
-#endif
-
-static bool is_ip_rx_frame(struct sk_buff *skb)
-{
- switch (skb->protocol) {
- case htons(ETH_P_IP):
- return true;
- case htons(ETH_P_IPV6):
- return check_ipv6_frame(skb);
- }
- return false;
-}
-
static void vrf_tx_error(struct net_device *vrf_dev, struct sk_buff *skb)
{
vrf_dev->stats.tx_errors++;
kfree_skb(skb);
}
-/* note: already called with rcu_read_lock */
-static rx_handler_result_t vrf_handle_frame(struct sk_buff **pskb)
-{
- struct sk_buff *skb = *pskb;
-
- if (is_ip_rx_frame(skb)) {
- struct net_device *dev = vrf_master_get_rcu(skb->dev);
- struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
-
- u64_stats_update_begin(&dstats->syncp);
- dstats->rx_pkts++;
- dstats->rx_bytes += skb->len;
- u64_stats_update_end(&dstats->syncp);
-
- skb->dev = dev;
-
- return RX_HANDLER_ANOTHER;
- }
- return RX_HANDLER_PASS;
-}
-
static struct rtnl_link_stats64 *vrf_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *stats)
{
@@ -497,28 +416,14 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
{
int ret;
- /* register the packet handler for slave ports */
- ret = netdev_rx_handler_register(port_dev, vrf_handle_frame, dev);
- if (ret) {
- netdev_err(port_dev,
- "Device %s failed to register rx_handler\n",
- port_dev->name);
- goto out_fail;
- }
-
ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
if (ret < 0)
- goto out_unregister;
+ return ret;
port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
cycle_netdev(port_dev);
return 0;
-
-out_unregister:
- netdev_rx_handler_unregister(port_dev);
-out_fail:
- return ret;
}
static int vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
@@ -535,8 +440,6 @@ static int do_vrf_del_slave(struct net_device *dev, struct net_device *port_dev)
netdev_upper_dev_unlink(port_dev, dev);
port_dev->priv_flags &= ~IFF_L3MDEV_SLAVE;
- netdev_rx_handler_unregister(port_dev);
-
cycle_netdev(port_dev);
return 0;
@@ -659,6 +562,92 @@ static int vrf_get_saddr(struct net_device *dev, struct flowi4 *fl4)
}
#if IS_ENABLED(CONFIG_IPV6)
+/* neighbor handling is done with actual device; do not want
+ * to flip skb->dev for those ndisc packets. This really fails
+ * for multiple next protocols (e.g., NEXTHDR_HOP). But it is
+ * a start.
+ */
+static bool ipv6_ndisc_frame(const struct sk_buff *skb)
+{
+ const struct ipv6hdr *ipv6h = (struct ipv6hdr *)skb->data;
+ size_t hlen = sizeof(*ipv6h);
+ bool rc = false;
+
+ if (ipv6h->nexthdr == NEXTHDR_ICMP) {
+ const struct icmp6hdr *icmph;
+
+ if (skb->len < hlen + sizeof(*icmph))
+ goto out;
+
+ icmph = (struct icmp6hdr *)(skb->data + sizeof(*ipv6h));
+ switch (icmph->icmp6_type) {
+ case NDISC_ROUTER_SOLICITATION:
+ case NDISC_ROUTER_ADVERTISEMENT:
+ case NDISC_NEIGHBOUR_SOLICITATION:
+ case NDISC_NEIGHBOUR_ADVERTISEMENT:
+ case NDISC_REDIRECT:
+ rc = true;
+ break;
+ }
+ }
+
+out:
+ return rc;
+}
+
+static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ /* if packet is NDISC keep the ingress interface */
+ if (!ipv6_ndisc_frame(skb)) {
+ skb->dev = vrf_dev;
+ skb->skb_iif = vrf_dev->ifindex;
+
+ skb_push(skb, skb->mac_len);
+ dev_queue_xmit_nit(skb, vrf_dev);
+ skb_pull(skb, skb->mac_len);
+ }
+
+ return skb;
+}
+
+#else
+static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ return skb;
+}
+#endif
+
+static struct sk_buff *vrf_ip_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb)
+{
+ skb->dev = vrf_dev;
+ skb->skb_iif = vrf_dev->ifindex;
+
+ skb_push(skb, skb->mac_len);
+ dev_queue_xmit_nit(skb, vrf_dev);
+ skb_pull(skb, skb->mac_len);
+
+ return skb;
+}
+
+/* called with rcu lock held */
+static struct sk_buff *vrf_l3_rcv(struct net_device *vrf_dev,
+ struct sk_buff *skb,
+ u16 proto)
+{
+ switch (proto) {
+ case AF_INET:
+ return vrf_ip_rcv(vrf_dev, skb);
+ case AF_INET6:
+ return vrf_ip6_rcv(vrf_dev, skb);
+ }
+
+ return skb;
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
static struct dst_entry *vrf_get_rt6_dst(const struct net_device *dev,
const struct flowi6 *fl6)
{
@@ -679,6 +668,7 @@ static const struct l3mdev_ops vrf_l3mdev_ops = {
.l3mdev_fib_table = vrf_fib_table,
.l3mdev_get_rtable = vrf_get_rtable,
.l3mdev_get_saddr = vrf_get_saddr,
+ .l3mdev_l3_rcv = vrf_l3_rcv,
#if IS_ENABLED(CONFIG_IPV6)
.l3mdev_get_rt6_dst = vrf_get_rt6_dst,
#endif
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 58d6e158755f..878608834f89 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -123,9 +123,10 @@ struct inet6_skb_parm {
#define IP6CB(skb) ((struct inet6_skb_parm*)((skb)->cb))
#define IP6CBMTU(skb) ((struct ip6_mtuinfo *)((skb)->cb))
+/* return last skb->dev index. For loopback return iif from cb */
static inline int inet6_iif(const struct sk_buff *skb)
{
- return IP6CB(skb)->iif;
+ return skb->skb_iif > 1 ? skb->skb_iif : IP6CB(skb)->iif;
}
struct tcp6_request_sock {
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 63580e6d0df4..c2f5112f08f7 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3258,6 +3258,8 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb);
bool is_skb_forwardable(const struct net_device *dev,
const struct sk_buff *skb);
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev);
+
extern int netdev_budget;
/* Called by rtnetlink.c:rtnl_unlock() */
diff --git a/include/net/l3mdev.h b/include/net/l3mdev.h
index c43a9c73de5e..19d8171d7cbb 100644
--- a/include/net/l3mdev.h
+++ b/include/net/l3mdev.h
@@ -25,6 +25,8 @@
struct l3mdev_ops {
u32 (*l3mdev_fib_table)(const struct net_device *dev);
+ struct sk_buff * (*l3mdev_l3_rcv)(struct net_device *dev,
+ struct sk_buff *skb, u16 proto);
/* IPv4 ops */
struct rtable * (*l3mdev_get_rtable)(const struct net_device *dev,
@@ -177,6 +179,35 @@ struct dst_entry *l3mdev_rt6_dst_by_oif(struct net *net,
return dst;
}
+static inline
+struct sk_buff *l3mdev_l3_rcv(struct sk_buff *skb, u16 proto)
+{
+ struct net_device *master = NULL;
+
+ if (netif_is_l3_slave(skb->dev))
+ master = netdev_master_upper_dev_get_rcu(skb->dev);
+
+ else if (netif_is_l3_master(skb->dev))
+ master = skb->dev;
+
+ if (master && master->l3mdev_ops->l3mdev_l3_rcv)
+ skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
+
+ return skb;
+}
+
+static inline
+struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb)
+{
+ return l3mdev_l3_rcv(skb, AF_INET);
+}
+
+static inline
+struct sk_buff *l3mdev_ip6_rcv(struct sk_buff *skb)
+{
+ return l3mdev_l3_rcv(skb, AF_INET6);
+}
+
#else
static inline int l3mdev_master_ifindex_rcu(const struct net_device *dev)
@@ -244,6 +275,18 @@ struct dst_entry *l3mdev_rt6_dst_by_oif(struct net *net,
{
return NULL;
}
+
+static inline
+struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb)
+{
+ return skb;
+}
+
+static inline
+struct sk_buff *l3mdev_ip6_rcv(struct sk_buff *skb)
+{
+ return skb;
+}
#endif
#endif /* _NET_L3MDEV_H_ */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 24ec80483805..a68f387ce310 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -781,7 +781,8 @@ struct tcp_skb_cb {
*/
static inline int tcp_v6_iif(const struct sk_buff *skb)
{
- return TCP_SKB_CB(skb)->header.h6.iif;
+ /* return last skb->dev index. For loopback return iif from cb */
+ return skb->skb_iif > 1 ? skb->skb_iif : TCP_SKB_CB(skb)->header.h6.iif;
}
#endif
diff --git a/net/core/dev.c b/net/core/dev.c
index e98ba63fe280..51a8bf28a3e0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1850,7 +1850,7 @@ static inline bool skb_loop_sk(struct packet_type *ptype, struct sk_buff *skb)
* taps currently in use.
*/
-static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
{
struct packet_type *ptype;
struct sk_buff *skb2 = NULL;
@@ -1907,6 +1907,7 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
rcu_read_unlock();
}
+EXPORT_SYMBOL_GPL(dev_queue_xmit_nit);
/**
* netif_setup_tc - Handle tc mappings on real_num_tx_queues change
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 751c0658e194..37375eedeef9 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -313,6 +313,13 @@ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
const struct iphdr *iph = ip_hdr(skb);
struct rtable *rt;
+ /* if ingress device is enslaved to an L3 master device pass the
+ * skb to its handler for processing
+ */
+ skb = l3mdev_ip_rcv(skb);
+ if (!skb)
+ return NET_RX_SUCCESS;
+
if (net->ipv4.sysctl_ip_early_demux &&
!skb_dst(skb) &&
!skb->sk &&
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 6ed56012005d..f185cbcda114 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -49,6 +49,13 @@
int ip6_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
{
+ /* if ingress device is enslaved to an L3 master device pass the
+ * skb to its handler for processing
+ */
+ skb = l3mdev_ip6_rcv(skb);
+ if (!skb)
+ return NET_RX_SUCCESS;
+
if (net->ipv4.sysctl_ip_early_demux && !skb_dst(skb) && skb->sk == NULL) {
const struct inet6_protocol *ipprot;
--
2.1.4
^ permalink raw reply related
* [PATCH net-next 2/2] net: original ingress device index in PKTINFO
From: David Ahern @ 2016-05-05 19:37 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
In-Reply-To: <1462477063-21699-1-git-send-email-dsa@cumulusnetworks.com>
Applications such as OSPF and BFD need the original ingress device not
the VRF device; the latter can be derived from the former. To that end
add the skb_iif to inet_skb_parm and set it in ipv4 code after clearing
the skb control buffer similar to IPv6. From there the pktinfo can just
pull it from cb with the PKTINFO_SKB_CB cast.
The previous patch moving the skb->dev change to L3 means nothing else
is needed for IPv6; it just works.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
Removed the change to ipv4_datagram_support_cmsg per Julian's comment
when the patch was a part of the larger set.
include/net/ip.h | 1 +
net/ipv4/ip_input.c | 1 +
net/ipv4/ip_sockglue.c | 7 ++++++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 247ac82e9cf2..37165fba3741 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -36,6 +36,7 @@
struct sock;
struct inet_skb_parm {
+ int iif;
struct ip_options opt; /* Compiled IP options */
unsigned char flags;
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 37375eedeef9..4b351af3e67b 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -478,6 +478,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
/* Remove any debris in the socket control block */
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ IPCB(skb)->iif = skb->skb_iif;
/* Must drop socket now because of tproxy. */
skb_orphan(skb);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index bdb222c0c6a2..5805762d7fc7 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1193,7 +1193,12 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
ipv6_sk_rxinfo(sk);
if (prepare && skb_rtable(skb)) {
- pktinfo->ipi_ifindex = inet_iif(skb);
+ /* skb->cb is overloaded: prior to this point it is IP{6}CB
+ * which has interface index (iif) as the first member of the
+ * underlying inet{6}_skb_parm struct. This code then overlays
+ * PKTINFO_SKB_CB and in_pktinfo also has iif as the first
+ * element so the iif is picked up from the prior IPCB
+ */
pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
} else {
pktinfo->ipi_ifindex = 0;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE
From: Thadeu Lima de Souza Cascardo @ 2016-05-05 19:56 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, Simon Horman
In-Reply-To: <20160505213141.7ad29ebd@griffin>
On Thu, May 05, 2016 at 09:31:41PM +0200, Jiri Benc wrote:
> On Thu, 5 May 2016 13:36:44 -0300, Thadeu Lima de Souza Cascardo wrote:
> > Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
> > to allow GPE interfaces to be added as openvswitch ports.
>
> What's wrong with ARPHRD_NONE? I don't think we need a separate type
> for VXLAN-GPE. Just use ARPHRD_NONE in ovs and things should work, for
> all ARPHRD_NONE interfaces as a bonus.
>
That's fine for me. I looked quickly at the few devices using ARPHRD_NONE in
upstream kernel, not sure if there are broken out-of-tree drivers out there. And
should we care?
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
> > Cc: Jiri Benc <jbenc@redhat.com>
> > Cc: Simon Horman <simon.horman@netronome.com>
>
> You did not CC me nor Simon :-)
>
I am using sendemail.suppresscc=all to prevent some accidents. I am adding
confirm=always so I can double check before really sending.
Thanks.
Cascardo.
> Jiri
^ permalink raw reply
* Re: [PATCH net-next 06/13] net: original ingress device index in PKTINFO
From: Julian Anastasov @ 2016-05-05 20:00 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <572B6012.60806@cumulusnetworks.com>
Hello,
On Thu, 5 May 2016, David Ahern wrote:
> On 5/5/16 2:41 AM, Julian Anastasov wrote:
> > > + IPCB(skb)->iif = skb->skb_iif;
> >
> > For loopback traffic (including looped back multicast)
> > this is now a zero :( Can inet_iif be moved to ip_rcv_finish
> > instead? Still, we spend cycles in fast path in case nobody
> > listens for such info.
>
> Why is that? skb_iif is set to skb->dev->index in __netif_receive_skb_core and
> ip_rcv is called it. Is there another path to it?
You are right, it is 0 only for the output path.
Regards
^ permalink raw reply
* Re: [PATCH nf-next 0/9] netfilter: remove per-netns conntrack tables, part 1
From: Brian Haley @ 2016-05-05 20:27 UTC (permalink / raw)
To: Florian Westphal, netfilter-devel; +Cc: netdev
In-Reply-To: <1461863628-23350-1-git-send-email-fw@strlen.de>
On 04/28/2016 01:13 PM, Florian Westphal wrote:
> [ CCing netdev so netns folks can have a look too ]
>
> This patch series removes the per-netns connection tracking tables.
> All conntrack objects are then stored in one global global table.
>
> This avoids the infamous 'vmalloc' when lots of namespaces are used:
> We no longer allocate a new conntrack table for each namespace (with 64k
> size this saves 512kb of memory per netns).
>
> - net namespace address is made part of conntrack hash, to spread
> conntracks over entire table even if netns has overlapping ip addresses.
> - lookup and iterators net_eq() to skip conntracks living in a different
> namespace.
Hi Florian,
Question on this series.
Openstack networking creates virtual routers using namespaces for isolation
between users. VETH pairs are used to connect the interfaces on these routers
to different networks, whether they are internal (private) or external (public).
In most cases NAT is done inside the namespace as packets move between the
networks.
I've seen cases where certain users are attacked, where the CT table is filled
such that we start seeing "nf_conntrack: table full, dropping packet" messages
(as expected). But other users continue to function normally, unaffected. Is
this still the case - each netns has some limit it can't exceed? I didn't see
it, but your comment in 9/9 seemed like something was there - "we would start
to 'over-subscribe' the affected/overlimit netns".
Thanks,
-Brian
^ permalink raw reply
* Re: mlx5 core/en oops in 4.6-rc6+
From: Saeed Mahameed @ 2016-05-05 20:51 UTC (permalink / raw)
To: Doug Ledford; +Cc: Linux Netdev List
In-Reply-To: <b4a8c4ca-74c5-b9b4-f9a5-4386cf6857fe@redhat.com>
On Thu, May 5, 2016 at 8:16 PM, Doug Ledford <dledford@redhat.com> wrote:
>
> That depends on which interface actually generated the oops. If it was
> the base interface, then I don't manually set any special params on it.
> If it's one of the vlan interfaces, then there is a NetworkManager
> dispatcher script that is intended to set the tc count on interface up:
>
> [root@rdma-virt-03 ~]$ more /etc/NetworkManager/dispatcher.d/98-mlx5_roce.4*
> ::::::::::::::
> /etc/NetworkManager/dispatcher.d/98-mlx5_roce.43-egress.conf
> ::::::::::::::
> #!/bin/sh
> interface=$1
> status=$2
> [ "$interface" = mlx5_roce.43 ] || exit 0
> case $status in
> up)
> tc qdisc add dev mlx5_roce root mqprio num_tc 8 map 5 5 5 5 5 5 5 5 5 5
> 5 5 5 5 5 5
Well, here you are configuring 8 TCs on the base mlx5 interface, so
the answer to my question is yes.
It appears that we have a bug in mlx5e_slelect_queue
int channel_ix = fallback(dev, skb);
return priv->channeltc_to_txq_map[channel_ix][tc];
When num_tc > 1 the fallback can return any value between [0..
num_channles * num_tc ]
while channeltc_to_txq_map is an array of the size num_channels.
so there is a good chance that channel_ix exceeds the array limits and
resulting OOPs.
> # tc_wrap.py -i mlx5_roce -u 5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
> ;;
> esac
> --More--(Next file:
> /etc/NetworkManager/dispatcher.d/98-mlx5_roce.45-egress.conf::::::::::::::
> /etc/NetworkManager/dispatcher.d/98-mlx5_roce.45-egress.conf
> ::::::::::::::
> #!/bin/sh
> interface=$1
> status=$2
> [ "$interface" = mlx5_roce.45 ] || exit 0
> case $status in
> up)
> tc qdisc add dev mlx5_roce root mqprio num_tc 8 map 5 5 5 5 5 5 5 5 5 5
> 5 5 5 5 5 5
will, here you map all user skb prios (skb->priority) to HW tc 5.
BTW skprio or user prio in this example is never the vlan prio it is
the ipv4 (ToS).
please see http://lartc.org/manpages/tc-prio.html
So to achieve a vlan prio to HW tc mapping, you will need to map the
skprios to vlan prios using vlan egress mapping
which i see you already do down below.
But, our select queue implementation will extract the vlan priority
and use the corresponding TC from our own
priv->channeltc_to_txq_map[channel_ix][up] mapping
where up is vlan user priority. but this only applies to kernel
traffic, i don't see why it is needed for RoCE.
Currently this code is buggy and I will need to dig more into how to
provide a full working solution that fits our hardware requirements
and complies with the kernel QoS APIs.
[...]
> [root@rdma-virt-02 vlan]$ for i in *; do echo "$i:"; cat $i; echo; done
> config:
> VLAN Dev name | VLAN ID
> Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
> mlx5_roce.45 | 45 | mlx5_roce
> mlx5_roce.43 | 43 | mlx5_roce
>
> mlx5_roce.43:
> mlx5_roce.43 VID: 43 REORDER_HDR: 1 dev->priv_flags: 1001
> total frames received 57
> total bytes received 5010
> Broadcast/Multicast Rcvd 0
>
> total frames transmitted 20
> total bytes transmitted 2525
> Device: mlx5_roce
> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
> EGRESS priority mappings: 0:3 1:3 2:3 3:3 4:3 5:3 6:3 7:3
>
Here you map every SKB prio (0..7) to vlan priorty 3.
>
> mlx5_roce.45:
> mlx5_roce.45 VID: 45 REORDER_HDR: 1 dev->priv_flags: 1001
> total frames received 57
> total bytes received 5010
> Broadcast/Multicast Rcvd 0
>
> total frames transmitted 21
> total bytes transmitted 2603
> Device: mlx5_roce
> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
> EGRESS priority mappings: 0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5
>
> OK, so the vlans have egress mappings, but they don't match what the
> mlx5_roce.43 egress.conf file should have enabled. Digging a little
> further on this machine:
>
> [root@rdma-virt-03 vlan]$ more
> /etc/sysconfig/network-scripts/ifcfg-mlx5_roce.4?
> ::::::::::::::
> /etc/sysconfig/network-scripts/ifcfg-mlx5_roce.43
> ::::::::::::::
> DEVICE=mlx5_roce.43
> VLAN=yes
> VLAN_ID=43
> VLAN_EGRESS_PRIORITY_MAP=0:3,1:3,2:3,3:3,4:3,5:3,6:3,7:3
> TYPE=Vlan
> ONBOOT=yes
> BOOTPROTO=dhcp
> DEFROUTE=no
> PEERDNS=no
> PEERROUTES=yes
> IPV4_FAILURE_FATAL=yes
> IPV6INIT=yes
> IPV6_AUTOCONF=yes
> IPV6_DEFROUTE=no
> IPV6_PEERDNS=no
> IPV6_PEERROUTES=yes
> IPV6_FAILURE_FATAL=no
> NAME=mlx5_roce.43
> ::::::::::::::
> /etc/sysconfig/network-scripts/ifcfg-mlx5_roce.45
> ::::::::::::::
> DEVICE=mlx5_roce.45
> VLAN=yes
> VLAN_ID=45
> VLAN_EGRESS_PRIORITY_MAP=0:5,1:5,2:5,3:5,4:5,5:5,6:5,7:5
> TYPE=Vlan
> ONBOOT=yes
> BOOTPROTO=dhcp
> DEFROUTE=no
> PEERDNS=no
> PEERROUTES=yes
> IPV4_FAILURE_FATAL=yes
> IPV6INIT=yes
> IPV6_AUTOCONF=yes
> IPV6_DEFROUTE=no
> IPV6_PEERDNS=no
> IPV6_PEERROUTES=yes
> IPV6_FAILURE_FATAL=no
> NAME=mlx5_roce.45
> [root@rdma-virt-03 vlan]$
>
> This is a Fedora rawhide machine, using NetworkManager to handle the
> network interfaces. So, the egress priority mappings are being set by
> NM. I don't know if they are overriding the egress mapping dispatchers
> or if the egress mapping dispatchers are failing to work/run properly.
> It might be the latter. Let me double check the command...
>
> OK, re-reading the egress dispatchers above, they work on the base
> interface, not on the vlan interface that triggers them. That's why
> they both use the same command (mapping to egress 5) instead of being
> like the ifcfg files, which map the 43 vlan to egress priority 3, and
> the 45 vlan to egress priority 5. Running tc qdisc | grep mlx5_roce
> shows that the egress mapping is being applied (although I'm not sure it
> should be...I made that mapping many kernels ago when that was the right
> thing to do, the modern mlx5 ethernet drivers create their own mappings
> that are drastically different).
>
> So, to answer your question, yes, num_tc > 1, num_tc == 8, and I
> probably need to reconfigure that egress dispatcher to do what I want it
> to do (which is merely to make sure that all packets from specific
> interfaces are tagged with specific vlan priorities so per-priority flow
> control between the card and switch works properly, the base interface
> is supposed to have no priority tag, the 43 vlan is supposed to have
> priority tag 3, and vlan 45 is supposed to have priority tag 5) on
> modern kernels.
>
As i said above configuring any num_tc > 1 might cause the panic you saw.
Regarding the proper mapping to do for 45 => priority 5, 43 => prio 3.
the egress mappings you already did above should be sufficient, the
question is, do you need the vlan priorities to be mapped to a
specific HW TC dispatchers ?
if not, then you don't need to configure "tc qdisc add dev mlx5_roce
root ..." at all.
^ permalink raw reply
* Re: [PATCH nf-next 0/9] netfilter: remove per-netns conntrack tables, part 1
From: Florian Westphal @ 2016-05-05 20:54 UTC (permalink / raw)
To: Brian Haley; +Cc: Florian Westphal, netfilter-devel, netdev
In-Reply-To: <572BACA3.6070303@hpe.com>
Brian Haley <brian.haley@hpe.com> wrote:
> Openstack networking creates virtual routers using namespaces for isolation
> between users. VETH pairs are used to connect the interfaces on these
> routers to different networks, whether they are internal (private) or
> external (public). In most cases NAT is done inside the namespace as
> packets move between the networks.
>
> I've seen cases where certain users are attacked, where the CT table is
> filled such that we start seeing "nf_conntrack: table full, dropping packet"
> messages (as expected). But other users continue to function normally,
> unaffected. Is this still the case - each netns has some limit it can't
> exceed?
The limit is global, the accounting per namespace.
If the bucket count (net.netfilter.nf_conntrack_buckets) is high enough
to accomodate the expected load and noone can create arbitrary number of
net namespaces things are fine.
I haven't changed the way this works yet because I did not have a better
idea so far.
^ permalink raw reply
* Re: [PATCH 0/3] net-next: mediatek: improve phy support
From: David Miller @ 2016-05-05 21:20 UTC (permalink / raw)
To: john; +Cc: nbd, netdev, linux-mediatek, linux-kernel
In-Reply-To: <1462439856-51788-1-git-send-email-john@phrozen.org>
Sorry, I'm not entertaining 3 seperate patch series for the same
driver at one time. I'm removing all of these mediatek patches
from my queue.
Submit one series at a time please, thanks.
^ permalink raw reply
* Re: [PATCH net-next v4] macvtap: add namespace support to the sysfs device class
From: David Miller @ 2016-05-05 21:23 UTC (permalink / raw)
To: marc; +Cc: netdev, ebiederm
In-Reply-To: <1462443266-3166-1-git-send-email-marc@arista.com>
From: Marc Angel <marc@arista.com>
Date: Thu, 5 May 2016 12:14:26 +0200
> When creating macvtaps that are expected to have the same ifindex
> in different network namespaces, only the first one will succeed.
> The others will fail with a sysfs_warn_dup warning due to them trying
> to create the following sysfs link (with 'NN' the ifindex of macvtapX):
>
> /sys/class/macvtap/tapNN -> /sys/devices/virtual/net/macvtapX/tapNN
>
> This is reproducible by running the following commands:
>
> ip netns add ns1
> ip netns add ns2
> ip link add veth0 type veth peer name veth1
> ip link set veth0 netns ns1
> ip link set veth1 netns ns2
> ip netns exec ns1 ip l add link veth0 macvtap0 type macvtap
> ip netns exec ns2 ip l add link veth1 macvtap1 type macvtap
>
> The last command will fail with "RTNETLINK answers: File exists" (along
> with the kernel warning) but retrying it will work because the ifindex
> was incremented.
>
> The 'net' device class is isolated between network namespaces so each
> one has its own hierarchy of net devices.
> This isn't the case for the 'macvtap' device class.
> The problem occurs half-way through the netdev registration, when
> `macvtap_device_event` is called-back to create the 'tapNN' macvtap
> class device under the 'macvtapX' net class device.
>
> This patch adds namespace support to the 'macvtap' device class so
> that /sys/class/macvtap is no longer shared between net namespaces.
>
> However, making the macvtap sysfs class namespace-aware has the side
> effect of changing /sys/devices/virtual/net/macvtapX/tapNN into
> /sys/devices/virtual/net/macvtapX/macvtap/tapNN.
>
> This is due to Commit 24b1442 ("Driver-core: Always create class
> directories for classses that support namespaces") and the fact that
> class devices supporting namespaces are really not supposed to be placed
> directly under other class devices.
>
> To avoid breaking userland, a tapNN symlink pointing to macvtap/tapNN is
> created inside the macvtapX directory.
>
> Signed-off-by: Marc Angel <marc@arista.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Or Gerlitz @ 2016-05-05 21:39 UTC (permalink / raw)
To: Alex Duyck
Cc: Or Gerlitz, Alexander Duyck, Tom Herbert, talal@mellanox.com,
Linux Netdev List, Michael Chan, David Miller, Gal Pressman,
Eran Ben Elisha
In-Reply-To: <CAMt9YRqCH8Ab5vefMoQj39gJ8b-gsg2w5nJanW1srqt13bUkSQ@mail.gmail.com>
On Wed, May 4, 2016 at 7:06 PM, Alex Duyck <aduyck@mirantis.com> wrote:
> On Wed, May 4, 2016 at 8:50 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>> On 5/3/2016 6:29 PM, Alexander Duyck wrote:
>>>
>>> We split the one that would be a different size off via GSO. So we
>>> end up sending up 2 frames to the device if there is going to be one
>>> piece that doesn't quite match. We split that one piece off via GSO.
>>> That is one of the reasons why I referred to it as partial GSO as all
>>> we are using the software segmentation code for is to make sure we
>>> have the GSO block consists of segments that are all the same size.
>>
>>
>> I see, so if somehow it happens a lot that the TCP stack sends down
>> something which once segmented ends up with the last segment being of
>> different size from the other ones we would have to call the NIC xmit
>> function twice (BTW can we use xmit_more here?) -- which could be effecting
>> performance, I guess.
>>
>> GSO_UDP_TUNNEL_CSUM (commit 0f4f4ffa7 "net: Add GSO support for UDP tunnels
>> with checksum") came to mark "that a device is capable of computing the UDP
>> checksum in the encapsulating header of a UDP tunnel" -- and the way we use
>> it here is that we do advertize that bit towards the stack for devices whose
>> HW can **not** do that, and things work b/c of LCO (this is my
>> understanding).
>>
>> I miss something in the bigger picture here, what does this buy us? e.g vs
>> just letting this (say) vxlan tunnel use zero checksum on the outer UDP
>> packet, is that has something to do with RCO?
>
> I think the piece you are missing is GSO_PARTIAL. Basically
> GSO_PARTIAL indicates that we can perform GSO as long as all segments
> are the same size and also allows for ignoring one level of headers.
> So in the case of ixgbe for instance we can support tunnel offloads as
> long as we allow for the inner IPv4 ID to be a fixed value which is
> identified by enabling TSO_MANGLEID. In the case of i40e, mlx4, and
> mlx5 the key bit is that we just have to have the frames the same size
> for all segments and then we can support tunnels with outer checksum
> because the checksum has been computed once and can be applied to all
> of the segmented frames.
Yep, I think to basically follow on the PARTIAL thing, which once
advertised by i40e, mlx4 and mlx5 allow them support udp (and GRE in
i40e case) tunnels with outer checksum.
My question was what this buy us for the UDP case vs. using zero
checksum for the tunnel (outer packet), I tried to figure out if it
has something to do with the remote side, e.g for RCO or alike.
Basically, under PARTIAL, on the worst case we could have ending up
with 2x packet xmitted to the NIC - e.g if each TCP message which is
to be encapsulated by the stack and later segmented by the NIC HW is
broken to two b/c otherwise the last segmented packet will not be of
equal size as of the all the preceding ones.
Or being a bit more positive... is there an expected performance gain
when you use MANGLEID and/or PARTIAL to enable supporting UDP tunnel
segmentation checksum offload towards the stack? what is the reason
for that gain?
As for GRE tunnel segmentation checksum offload, I saw in your i40e
patch that it made your testbed to go from 12Gbs to 20Gbs, is this b/c
the stack can not actually let the HW do the segmentation w.o checksum
offload? if not, can you help understand the source of the gain?
> Hope that helps.
yes, your notes are very helpful, thanks for sparing the time..
Or.
^ permalink raw reply
* Re: [PATCH v9 net-next 7/7] openvswitch: use ipgre tunnel rather than gretap tunnel
From: pravin shelar @ 2016-05-05 21:45 UTC (permalink / raw)
To: Simon Horman; +Cc: ovs dev, Linux Kernel Network Developers
In-Reply-To: <1462347393-22354-8-git-send-email-simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
On Wed, May 4, 2016 at 12:36 AM, Simon Horman
<simon.horman@netronome.com> wrote:
> This allows GRE tunnels to send and receive both
> layer 2 packets (packets with an ethernet header) and
> layer 3 packets (packets without an ethernet header).
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
> v9
> New Patch
> ---
> include/net/gre.h | 4 ++--
> net/ipv4/ip_gre.c | 8 ++++----
> net/openvswitch/vport-gre.c | 4 ++--
> net/openvswitch/vport-netdev.c | 12 +++++++++++-
> net/openvswitch/vport-netdev.h | 1 +
> 5 files changed, 20 insertions(+), 9 deletions(-)
>
...
...
> diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
> index f003225de994..b1aa02904ae4 100644
> --- a/net/openvswitch/vport-gre.c
> +++ b/net/openvswitch/vport-gre.c
> @@ -60,7 +60,7 @@ static struct vport *gre_tnl_create(const struct vport_parms *parms)
> return vport;
>
> rtnl_lock();
> - dev = gretap_fb_dev_create(net, parms->name, NET_NAME_USER);
> + dev = gre_fb_dev_create(net, parms->name, NET_NAME_USER);
> if (IS_ERR(dev)) {
> rtnl_unlock();
> ovs_vport_free(vport);
> @@ -87,7 +87,7 @@ static struct vport *gre_create(const struct vport_parms *parms)
> static struct vport_ops ovs_gre_vport_ops = {
> .type = OVS_VPORT_TYPE_GRE,
> .create = gre_create,
> - .send = ovs_netdev_send_tap,
> + .send = ovs_netdev_send_raw_tun,
> .destroy = ovs_netdev_tunnel_destroy,
> };
>
This trick of using vport-send only works in case of compat tunnel
device mode. But in normal case the LWT interface allows us to use net
devices for tunnel traffic. So you need some sort of mechanism to
handle l3 only packets on vport-netdev.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Alexander Duyck @ 2016-05-05 22:00 UTC (permalink / raw)
To: Or Gerlitz
Cc: Alex Duyck, Or Gerlitz, Tom Herbert, talal@mellanox.com,
Linux Netdev List, Michael Chan, David Miller, Gal Pressman,
Eran Ben Elisha
In-Reply-To: <CAJ3xEMj8z617kmoc2bLMBXf7B7KSBLzqr5tLTuuXYSOA--MYMw@mail.gmail.com>
On Thu, May 5, 2016 at 2:39 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Wed, May 4, 2016 at 7:06 PM, Alex Duyck <aduyck@mirantis.com> wrote:
>> On Wed, May 4, 2016 at 8:50 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>>> On 5/3/2016 6:29 PM, Alexander Duyck wrote:
>>>>
>>>> We split the one that would be a different size off via GSO. So we
>>>> end up sending up 2 frames to the device if there is going to be one
>>>> piece that doesn't quite match. We split that one piece off via GSO.
>>>> That is one of the reasons why I referred to it as partial GSO as all
>>>> we are using the software segmentation code for is to make sure we
>>>> have the GSO block consists of segments that are all the same size.
>>>
>>>
>>> I see, so if somehow it happens a lot that the TCP stack sends down
>>> something which once segmented ends up with the last segment being of
>>> different size from the other ones we would have to call the NIC xmit
>>> function twice (BTW can we use xmit_more here?) -- which could be effecting
>>> performance, I guess.
>>>
>>> GSO_UDP_TUNNEL_CSUM (commit 0f4f4ffa7 "net: Add GSO support for UDP tunnels
>>> with checksum") came to mark "that a device is capable of computing the UDP
>>> checksum in the encapsulating header of a UDP tunnel" -- and the way we use
>>> it here is that we do advertize that bit towards the stack for devices whose
>>> HW can **not** do that, and things work b/c of LCO (this is my
>>> understanding).
>>>
>>> I miss something in the bigger picture here, what does this buy us? e.g vs
>>> just letting this (say) vxlan tunnel use zero checksum on the outer UDP
>>> packet, is that has something to do with RCO?
>>
>> I think the piece you are missing is GSO_PARTIAL. Basically
>> GSO_PARTIAL indicates that we can perform GSO as long as all segments
>> are the same size and also allows for ignoring one level of headers.
>> So in the case of ixgbe for instance we can support tunnel offloads as
>> long as we allow for the inner IPv4 ID to be a fixed value which is
>> identified by enabling TSO_MANGLEID. In the case of i40e, mlx4, and
>> mlx5 the key bit is that we just have to have the frames the same size
>> for all segments and then we can support tunnels with outer checksum
>> because the checksum has been computed once and can be applied to all
>> of the segmented frames.
>
> Yep, I think to basically follow on the PARTIAL thing, which once
> advertised by i40e, mlx4 and mlx5 allow them support udp (and GRE in
> i40e case) tunnels with outer checksum.
>
> My question was what this buy us for the UDP case vs. using zero
> checksum for the tunnel (outer packet), I tried to figure out if it
> has something to do with the remote side, e.g for RCO or alike.
> Basically, under PARTIAL, on the worst case we could have ending up
> with 2x packet xmitted to the NIC - e.g if each TCP message which is
> to be encapsulated by the stack and later segmented by the NIC HW is
> broken to two b/c otherwise the last segmented packet will not be of
> equal size as of the all the preceding ones.
There ends up being a few pieces to this. In the case of i40e the Tx
gain seen is mostly for just transmitting the tunnel types with
checksums. This is because without that we have to use software
segmentation and that is expensive because it requires 40+ frames to
transmit a single 64K block of TCP data. In the case of GSO_PARTIAL
this data is usually all sent in a single packet because the TCP stack
tries to send MSS aligned blocks.
On the Rx side a gain can be seen if we exceed the number of ports
that can be used to support tunnels on the device. This is because
the hardware can still offload the outer UDP checksum and as a result
it can still go GRO on the frame thanks to the code Tom Herbert added
that converts validated outer UDP checksums to checksum complete.
Without the outer UDP checksum present we wouldn't be able to do GRO
and throughput drops to the 6 - 9Gb/s range.
> Or being a bit more positive... is there an expected performance gain
> when you use MANGLEID and/or PARTIAL to enable supporting UDP tunnel
> segmentation checksum offload towards the stack? what is the reason
> for that gain?
The TSO_MANGLEID bit is only really needed for igb and ixgbe. Those
drivers don't support tunnel offloads directly. Instead they can
support checksum offloads or a segmentation offload with an arbitrary
IP header size up to 511 bytes. So in order to do segmentation for
tunnels what we are doing is repeating everything from the outer
transport header through the inner network header for each frame. As
such we can only perform segmentation offloads for IPv4 in any type of
tunnel if we can repeat the IP ID for the inner header. If we are
allowed to do that then we can move packets between functions on the
same device at 15Gb/s which is the upper limits of non-encapsulated
traffic for VF to VF. Without that we are at 12Gb/s with outer
checksums and software segmentation, and only 6Gb/s with software
segmentation and outer checksum forced to 0.
> As for GRE tunnel segmentation checksum offload, I saw in your i40e
> patch that it made your testbed to go from 12Gbs to 20Gbs, is this b/c
> the stack can not actually let the HW do the segmentation w.o checksum
> offload? if not, can you help understand the source of the gain?
The device didn't advertise NETIF_F_GRE_CSUM so if there was a
checksum in the GRE header the packet had to be segmented in software.
By using the GSO_PARTIAL approach the speed is improved and comes up
to about 20Gb/s which is what the hardware does for standard GRE
tunnels. Basically the best software segmentation can do is 12Gb/s
for most NICs on a single flow. With hardware segment or GSO partial
we can push somewhere around 20Gb/s or more depending on the
configuration.
>> Hope that helps.
>
> yes, your notes are very helpful, thanks for sparing the time..
No problem.
- 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