* Re: [PATCH bpf-next] tools include uapi: Grab a copy of linux/erspan.h
From: Y Song @ 2018-04-30 15:45 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: William Tu, netdev, Yonghong Song
In-Reply-To: <be743a29-bbf2-1554-a961-0e71ee8ea030@iogearbox.net>
On Mon, Apr 30, 2018 at 7:33 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 04/30/2018 04:26 PM, William Tu wrote:
>> Bring the erspan uapi header file so BPF tunnel helpers can use it.
>>
>> Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
>> Reported-by: Yonghong Song <yhs@fb.com>
>> Signed-off-by: William Tu <u9012063@gmail.com>
>
> Thanks for the patch, William! I also Cc'ed Yonghong here, so he has a
> chance to try it out.
Just tried it out. It works. Thanks for fixing!
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH net-next] libcxgb,cxgb4: use __skb_put_zero to simplfy code
From: David Miller @ 2018-04-30 15:54 UTC (permalink / raw)
To: yuehaibing; +Cc: ganeshgr, johannes.berg, netdev, linux-kernel
In-Reply-To: <20180428043522.12408-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 28 Apr 2018 12:35:22 +0800
> use helper __skb_put_zero to replace the pattern of __skb_put() && memset()
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/2 v5] netns: uevent filtering
From: Eric W. Biederman @ 2018-04-30 15:55 UTC (permalink / raw)
To: Christian Brauner
Cc: davem, netdev, linux-kernel, avagin, ktkhai, serge, gregkh
In-Reply-To: <20180429104412.22445-1-christian.brauner@ubuntu.com>
Christian Brauner <christian.brauner@ubuntu.com> writes:
> Hey everyone,
>
> This is the new approach to uevent filtering as discussed (see the
> threads in [1], [2], and [3]). It only contains *non-functional
> changes*.
>
> This series deals with with fixing up uevent filtering logic:
> - uevent filtering logic is simplified
> - locking time on uevent_sock_list is minimized
> - tagged and untagged kobjects are handled in separate codepaths
> - permissions for userspace are fixed for network device uevents in
> network namespaces owned by non-initial user namespaces
> Udev is now able to see those events correctly which it wasn't before.
> For example, moving a physical device into a network namespace not
> owned by the initial user namespaces before gave:
>
> root@xen1:~# udevadm --debug monitor -k
> calling: monitor
> monitor will print the received events for:
> KERNEL - the kernel uevent
>
> sender uid=65534, message ignored
> sender uid=65534, message ignored
> sender uid=65534, message ignored
> sender uid=65534, message ignored
> sender uid=65534, message ignored
>
> and now after the discussion and solution in [3] correctly gives:
>
> root@xen1:~# udevadm --debug monitor -k
> calling: monitor
> monitor will print the received events for:
> KERNEL - the kernel uevent
>
> KERNEL[625.301042] add /devices/pci0000:00/0000:00:02.0/0000:01:00.1/net/enp1s0f1 (net)
> KERNEL[625.301109] move /devices/pci0000:00/0000:00:02.0/0000:01:00.1/net/enp1s0f1 (net)
> KERNEL[625.301138] move /devices/pci0000:00/0000:00:02.0/0000:01:00.1/net/eth1 (net)
> KERNEL[655.333272] remove /devices/pci0000:00/0000:00:02.0/0000:01:00.1/net/eth1 (net)
>
> Thanks!
> Christian
>
> [1]: https://lkml.org/lkml/2018/4/4/739
> [2]: https://lkml.org/lkml/2018/4/26/767
> [3]: https://lkml.org/lkml/2018/4/26/738
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Christian Brauner (2):
> uevent: add alloc_uevent_skb() helper
> netns: restrict uevents
>
> lib/kobject_uevent.c | 178 ++++++++++++++++++++++++++++++-------------
> 1 file changed, 126 insertions(+), 52 deletions(-)
Eric
^ permalink raw reply
* Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon read
From: David Miller @ 2018-04-30 15:56 UTC (permalink / raw)
To: eric.dumazet
Cc: soheil.kdev, netdev, ycheng, ncardwell, edumazet, willemb, soheil
In-Reply-To: <aec45003-3354-e49f-b032-5297e98722eb@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 30 Apr 2018 08:43:50 -0700
> I say sort of, because by the time we have any number, TCP might
> have received more packets anyway.
That's fine.
However, the number reported should have been true at least at some
finite point in time.
If you allow overlapping changes to either of the two variables during
the sampling, then you are reporting a number which was never true at
any point in time.
It is essentially garbage.
^ permalink raw reply
* Re: [PATCH] change the comment of vti6_ioctl
From: David Miller @ 2018-04-30 15:57 UTC (permalink / raw)
To: sunlw.fnst; +Cc: netdev, steffen.klassert, herbert
In-Reply-To: <20180429070552.2472-1-sunlw.fnst@cn.fujitsu.com>
From: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
Date: Sun, 29 Apr 2018 15:05:52 +0800
> The comment of vti6_ioctl() is wrong. which use vti6_tnl_ioctl
> instead of vti6_ioctl.
>
> Signed-off-by: Sun Lianwen <sunlw.fnst@cn.fujitsu.com>
Please CC: the IPSEC maintainers on future patch submissions to IPSEC
files, as per the top level MAINTAINERS file.
Steffen, please queue this up, thank you.
> ---
> net/ipv6/ip6_vti.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
> index c214ffec02f0..deadc4c3703b 100644
> --- a/net/ipv6/ip6_vti.c
> +++ b/net/ipv6/ip6_vti.c
> @@ -743,7 +743,7 @@ vti6_parm_to_user(struct ip6_tnl_parm2 *u, const struct __ip6_tnl_parm *p)
> }
>
> /**
> - * vti6_tnl_ioctl - configure vti6 tunnels from userspace
> + * vti6_ioctl - configure vti6 tunnels from userspace
> * @dev: virtual device associated with tunnel
> * @ifr: parameters passed from userspace
> * @cmd: command to be performed
> --
> 2.17.0
>
>
>
^ permalink raw reply
* Re: [PATCH bpf-next] tools include uapi: Grab a copy of linux/erspan.h
From: Daniel Borkmann @ 2018-04-30 15:57 UTC (permalink / raw)
To: Y Song; +Cc: William Tu, netdev, Yonghong Song
In-Reply-To: <CAH3MdRV6kR=4G0nqJxUWMP72SPE7hVaSHVebMOVML33O0c1A9w@mail.gmail.com>
On 04/30/2018 05:45 PM, Y Song wrote:
> On Mon, Apr 30, 2018 at 7:33 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 04/30/2018 04:26 PM, William Tu wrote:
>>> Bring the erspan uapi header file so BPF tunnel helpers can use it.
>>>
>>> Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
>>> Reported-by: Yonghong Song <yhs@fb.com>
>>> Signed-off-by: William Tu <u9012063@gmail.com>
>>
>> Thanks for the patch, William! I also Cc'ed Yonghong here, so he has a
>> chance to try it out.
>
> Just tried it out. It works. Thanks for fixing!
> Acked-by: Yonghong Song <yhs@fb.com>
Applied to bpf-next, thanks everyone!
^ permalink raw reply
* [PATCH bpf-next] bpf: relax constraints on formatting for eBPF helper documentation
From: Quentin Monnet @ 2018-04-30 15:59 UTC (permalink / raw)
To: daniel, ast; +Cc: dsahern, yhs, netdev, oss-drivers, quentin.monnet
The Python script used to parse and extract eBPF helpers documentation
from include/uapi/linux/bpf.h expects a very specific formatting for the
descriptions (single dots represent a space, '>' stands for a tab):
/*
...
*.int bpf_helper(list of arguments)
*.> Description
*.> > Start of description
*.> > Another line of description
*.> > And yet another line of description
*.> Return
*.> > 0 on success, or a negative error in case of failure
...
*/
This is too strict, and painful for developers who wants to add
documentation for new helpers. Worse, it is extremelly difficult to
check that the formatting is correct during reviews. Change the
format expected by the script and make it more flexible. The script now
works whether or not the initial space (right after the star) is
present, and accepts both tabs and white spaces (or a combination of
both) for indenting description sections and contents.
Concretely, something like the following would now be supported:
/*
...
*int bpf_helper(list of arguments)
*......Description
*.> > Start of description...
*> > Another line of description
*..............And yet another line of description
*> Return
*.> ........0 on success, or a negative error in case of failure
...
*/
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
scripts/bpf_helpers_doc.py | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/bpf_helpers_doc.py b/scripts/bpf_helpers_doc.py
index 30ba0fee36e4..717547e6f0a6 100755
--- a/scripts/bpf_helpers_doc.py
+++ b/scripts/bpf_helpers_doc.py
@@ -87,7 +87,7 @@ class HeaderParser(object):
# - Same as above, with "const" and/or "struct" in front of type
# - "..." (undefined number of arguments, for bpf_trace_printk())
# There is at least one term ("void"), and at most five arguments.
- p = re.compile('^ \* ((.+) \**\w+\((((const )?(struct )?(\w+|\.\.\.)( \**\w+)?)(, )?){1,5}\))$')
+ p = re.compile('^ \* ?((.+) \**\w+\((((const )?(struct )?(\w+|\.\.\.)( \**\w+)?)(, )?){1,5}\))$')
capture = p.match(self.line)
if not capture:
raise NoHelperFound
@@ -95,7 +95,7 @@ class HeaderParser(object):
return capture.group(1)
def parse_desc(self):
- p = re.compile('^ \* \tDescription$')
+ p = re.compile('^ \* ?(?:\t| {6,8})Description$')
capture = p.match(self.line)
if not capture:
# Helper can have empty description and we might be parsing another
@@ -109,7 +109,7 @@ class HeaderParser(object):
if self.line == ' *\n':
desc += '\n'
else:
- p = re.compile('^ \* \t\t(.*)')
+ p = re.compile('^ \* ?(?:\t| {6,8})(?:\t| {8})(.*)')
capture = p.match(self.line)
if capture:
desc += capture.group(1) + '\n'
@@ -118,7 +118,7 @@ class HeaderParser(object):
return desc
def parse_ret(self):
- p = re.compile('^ \* \tReturn$')
+ p = re.compile('^ \* ?(?:\t| {6,8})Return$')
capture = p.match(self.line)
if not capture:
# Helper can have empty retval and we might be parsing another
@@ -132,7 +132,7 @@ class HeaderParser(object):
if self.line == ' *\n':
ret += '\n'
else:
- p = re.compile('^ \* \t\t(.*)')
+ p = re.compile('^ \* ?(?:\t| {6,8})(?:\t| {8})(.*)')
capture = p.match(self.line)
if capture:
ret += capture.group(1) + '\n'
--
2.14.1
^ permalink raw reply related
* Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon read
From: Soheil Hassas Yeganeh @ 2018-04-30 15:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell, Eric Dumazet,
Willem de Bruijn
In-Reply-To: <aec45003-3354-e49f-b032-5297e98722eb@gmail.com>
On Mon, Apr 30, 2018 at 11:43 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 04/30/2018 08:38 AM, David Miller wrote:
>> From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
>> Date: Fri, 27 Apr 2018 14:57:32 -0400
>>
>>> Since the socket lock is not held when calculating the size of
>>> receive queue, TCP_INQ is a hint. For example, it can overestimate
>>> the queue size by one byte, if FIN is received.
>>
>> I think it is even worse than that.
>>
>> If another application comes in and does a recvmsg() in parallel with
>> these calculations, you could even report a negative value.
Thanks you David. In addition to Eric's point, for TCP specifically,
it is quite uncommon to have multiple threads calling recvmsg() for
the same socket in parallel, because the application is interested in
the streamed, in-sequence bytes. Except when the application just
wants to discard the incoming stream or has a predefined frame sizes,
this wouldn't be an issue. For such cases, the proposed INQ hint is
not going to be useful.
Could you please let me know whether you have any other example in mind?
Thanks!
Soheil
^ permalink raw reply
* Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon read
From: Eric Dumazet @ 2018-04-30 16:01 UTC (permalink / raw)
To: David Miller, eric.dumazet
Cc: soheil.kdev, netdev, ycheng, ncardwell, edumazet, willemb, soheil
In-Reply-To: <20180430.115605.1094351453502803017.davem@davemloft.net>
On 04/30/2018 08:56 AM, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 30 Apr 2018 08:43:50 -0700
>
>> I say sort of, because by the time we have any number, TCP might
>> have received more packets anyway.
>
> That's fine.
>
> However, the number reported should have been true at least at some
> finite point in time.
>
> If you allow overlapping changes to either of the two variables during
> the sampling, then you are reporting a number which was never true at
> any point in time.
>
> It is essentially garbage.
Correct.
TCP sockets are read by a single thread really (or synchronized threads),
or garbage is ensured, regardless of how the kernel ensures locking while reporting "queue length"
^ permalink raw reply
* Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon read
From: David Miller @ 2018-04-30 16:10 UTC (permalink / raw)
To: eric.dumazet
Cc: soheil.kdev, netdev, ycheng, ncardwell, edumazet, willemb, soheil
In-Reply-To: <c95883da-51ab-47aa-7ad1-a5bb85935e6b@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 30 Apr 2018 09:01:47 -0700
> TCP sockets are read by a single thread really (or synchronized
> threads), or garbage is ensured, regardless of how the kernel
> ensures locking while reporting "queue length"
Whatever applications "typically do", we should never return
garbage, and that is what this code allowing to happen.
Everything else in recvmsg() operates on state under the proper socket
lock, to ensure consistency.
The only reason we are releasing the socket lock first it to make sure
the backlog is processed and we have the most update information
available.
It seems like one is striving for correctness and better accuracy, no?
:-)
Look, this can be fixed really simply. And if you are worried about
unbounded loops if two apps maliciously do recvmsg() in parallel,
then don't even loop, just fallback to full socket locking and make
the "non-typical" application pay the price:
tmp1 = A;
tmp2 = B;
barrier();
tmp3 = A;
if (unlikely(tmp1 != tmp3)) {
lock_sock(sk);
tmp1 = A;
tmp2 = B;
release_sock(sk);
}
I'm seriously not applying the patch as-is, sorry. This issue
must be addressed somehow.
Thank you.
^ permalink raw reply
* Re: [net-next v2] ipv6: sr: extract the right key values for "seg6_make_flowlabel"
From: David Miller @ 2018-04-30 16:13 UTC (permalink / raw)
To: amsalam20; +Cc: dav.lebrun, netdev, linux-kernel
In-Reply-To: <1524910715-12097-1-git-send-email-amsalam20@gmail.com>
From: Ahmed Abdelsalam <amsalam20@gmail.com>
Date: Sat, 28 Apr 2018 12:18:35 +0200
> The seg6_make_flowlabel() is used by seg6_do_srh_encap() to compute the
> flowlabel from a given skb. It relies on skb_get_hash() which eventually
> calls __skb_flow_dissect() to extract the flow_keys struct values from
> the skb.
>
> In case of IPv4 traffic, calling seg6_make_flowlabel() after skb_push(),
> skb_reset_network_header(), and skb_mac_header_rebuild() will results in
> flow_keys struct of all key values set to zero.
>
> This patch calls seg6_make_flowlabel() before resetting the headers of skb
> to get the right key values.
>
> Extracted Key values are based on the type inner packet as follows:
> 1) IPv6 traffic: src_IP, dst_IP, L4 proto, and flowlabel of inner packet.
> 2) IPv4 traffic: src_IP, dst_IP, L4 proto, src_port, and dst_port
> 3) L2 traffic: depends on what kind of traffic carried into the L2
> frame. IPv6 and IPv4 traffic works as discussed 1) and 2)
>
> Here a hex_dump of struct flow_keys for IPv4 and IPv6 traffic
> 10.100.1.100: 47302 > 30.0.0.2: 5001
> 00000000: 14 00 02 00 00 00 00 00 08 00 11 00 00 00 00 00
> 00000010: 00 00 00 00 00 00 00 00 13 89 b8 c6 1e 00 00 02
> 00000020: 0a 64 01 64
>
> fc00:a1:a > b2::2
> 00000000: 28 00 03 00 00 00 00 00 86 dd 11 00 99 f9 02 00
> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 b2 00 00
> 00000020: 00 00 00 00 00 00 00 00 00 00 00 02 fc 00 00 a1
> 00000030: 00 00 00 00 00 00 00 00 00 00 00 0a
>
> Signed-off-by: Ahmed Abdelsalam <amsalam20@gmail.com>
Looks good, applied, thank you.
^ permalink raw reply
* Re: Performance regressions in TCP_STREAM tests in Linux 4.15 (and later)
From: Ben Greear @ 2018-04-30 16:14 UTC (permalink / raw)
To: Steven Rostedt, Michael Wenig
Cc: netdev@vger.kernel.org, eric.dumazet@gmail.com, Shilpi Agarwal,
Boon Ang, Darren Hart, Steven Rostedt, Abdul Anshad Azeez
In-Reply-To: <20180427231149.119db14c@vmware.local.home>
On 04/27/2018 08:11 PM, Steven Rostedt wrote:
>
> We'd like this email archived in netdev list, but since netdev is
> notorious for blocking outlook email as spam, it didn't go through. So
> I'm replying here to help get it into the archives.
>
> Thanks!
>
> -- Steve
>
>
> On Fri, 27 Apr 2018 23:05:46 +0000
> Michael Wenig <mwenig@vmware.com> wrote:
>
>> As part of VMware's performance testing with the Linux 4.15 kernel,
>> we identified CPU cost and throughput regressions when comparing to
>> the Linux 4.14 kernel. The impacted test cases are mostly TCP_STREAM
>> send tests when using small message sizes. The regressions are
>> significant (up 3x) and were tracked down to be a side effect of Eric
>> Dumazat's RB tree changes that went into the Linux 4.15 kernel.
>> Further investigation showed our use of the TCP_NODELAY flag in
>> conjunction with Eric's change caused the regressions to show and
>> simply disabling TCP_NODELAY brought performance back to normal.
>> Eric's change also resulted into significant improvements in our
>> TCP_RR test cases.
>>
>>
>>
>> Based on these results, our theory is that Eric's change made the
>> system overall faster (reduced latency) but as a side effect less
>> aggregation is happening (with TCP_NODELAY) and that results in lower
>> throughput. Previously even though TCP_NODELAY was set, system was
>> slower and we still got some benefit of aggregation. Aggregation
>> helps in better efficiency and higher throughput although it can
>> increase the latency. If you are seeing a regression in your
>> application throughput after this change, using TCP_NODELAY might
>> help bring performance back however that might increase latency.
I guess you mean _disabling_ TCP_NODELAY instead of _using_ TCP_NODELAY?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] net/mlx4: fix spelling mistake: "failedi" -> "failed"
From: Colin King @ 2018-04-30 16:29 UTC (permalink / raw)
To: Tariq Toukan, David S . Miller, netdev, linux-rdma
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake in mlx4_warn message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index bfef69235d71..211578ffc70d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -1317,7 +1317,7 @@ static int mlx4_mf_unbond(struct mlx4_dev *dev)
ret = mlx4_unbond_fs_rules(dev);
if (ret)
- mlx4_warn(dev, "multifunction unbond for flow rules failedi (%d)\n", ret);
+ mlx4_warn(dev, "multifunction unbond for flow rules failed (%d)\n", ret);
ret1 = mlx4_unbond_mac_table(dev);
if (ret1) {
mlx4_warn(dev, "multifunction unbond for MAC table failed (%d)\n", ret1);
--
2.17.0
^ permalink raw reply related
* Re: [RFC net-next 0/5] Support for PHY test modes
From: Florian Fainelli @ 2018-04-30 16:30 UTC (permalink / raw)
To: David Miller
Cc: netdev, andrew, rmk, linux-kernel, cphealy, nikita.yoush,
vivien.didelot, Nisar.Sayed, UNGLinuxDriver
In-Reply-To: <20180429.225554.2165914401649980919.davem@davemloft.net>
On 04/29/2018 07:55 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Fri, 27 Apr 2018 17:32:30 -0700
>
>> This patch series adds support for specifying PHY test modes through
>> ethtool and paves the ground for adding support for more complex
>> test modes that might require data to be exchanged between user and
>> kernel space.
>>
>> As an example, patches are included to add support for the IEEE
>> electrical test modes for 100BaseT2 and 1000BaseT. Those do not
>> require data to be passed back and forth.
>>
>> I believe the infrastructure to be usable enough to add support for
>> other things like:
>>
>> - cable diagnostics
>> - pattern generator/waveform generator with specific pattern being
>> indicated for instance
>>
>> Questions for Andrew, and others:
>>
>> - there could be room for adding additional ETH_TEST_FL_* values in order to
>> help determine how the test should be running
>> - some of these tests can be disruptive to connectivity, the minimum we could
>> do is stop the PHY state machine and restart it when "normal" is used to exit
>> those test modes
>>
>> Comments welcome!
>
> Generally, no objection to providing this in the general manner you
> have implemented it via ethtool.
Thanks for taking a look!
>
> I think in order to answer the disruptive question, you need to give
> some information about what kind of context this stuff would be
> used in, and if in those contexts what the user expectations are
> or might be.
>
> Are these test modes something that usually would be initiated with
> the interface down?
We expect that these commands/tests would likely be issued when the
interface is up (not necessarily with a carrier state ON though) because
we know for sure that drivers will have successfully connected to their
PHY and there is no power management (or there is, like runtime PM)
which will not prevent accesses to the MDIO interface from working.
Turning these tests on will typically result in the link partner
dropping the link with us, and the interface will be non-functional as
far as the data path is concerned (similar to an isolation mode). This
might warrant properly reporting that to user-space through e.g: a
private IFF_* value maybe?
--
Florian
^ permalink raw reply
* Re: Performance regressions in TCP_STREAM tests in Linux 4.15 (and later)
From: Steven Rostedt @ 2018-04-30 16:31 UTC (permalink / raw)
To: Ben Greear
Cc: Michael Wenig, netdev@vger.kernel.org, eric.dumazet@gmail.com,
Shilpi Agarwal, Boon Ang, Darren Hart, Abdul Anshad Azeez
In-Reply-To: <476bfc0f-eb2d-fe57-73d9-ec8a8392ad33@candelatech.com>
On Mon, 30 Apr 2018 09:14:04 -0700
Ben Greear <greearb@candelatech.com> wrote:
> >> As part of VMware's performance testing with the Linux 4.15 kernel,
> >> we identified CPU cost and throughput regressions when comparing to
> >> the Linux 4.14 kernel. The impacted test cases are mostly TCP_STREAM
> >> send tests when using small message sizes. The regressions are
> >> significant (up 3x) and were tracked down to be a side effect of Eric
> >> Dumazat's RB tree changes that went into the Linux 4.15 kernel.
> >> Further investigation showed our use of the TCP_NODELAY flag in
> >> conjunction with Eric's change caused the regressions to show and
> >> simply disabling TCP_NODELAY brought performance back to normal.
> >> Eric's change also resulted into significant improvements in our
> >> TCP_RR test cases.
> >>
> >>
> >>
> >> Based on these results, our theory is that Eric's change made the
> >> system overall faster (reduced latency) but as a side effect less
> >> aggregation is happening (with TCP_NODELAY) and that results in lower
> >> throughput. Previously even though TCP_NODELAY was set, system was
> >> slower and we still got some benefit of aggregation. Aggregation
> >> helps in better efficiency and higher throughput although it can
> >> increase the latency. If you are seeing a regression in your
> >> application throughput after this change, using TCP_NODELAY might
> >> help bring performance back however that might increase latency.
>
> I guess you mean _disabling_ TCP_NODELAY instead of _using_ TCP_NODELAY?
Yes, thank you for catching that.
-- Steve
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: relax constraints on formatting for eBPF helper documentation
From: Edward Cree @ 2018-04-30 16:33 UTC (permalink / raw)
To: Quentin Monnet, daniel, ast; +Cc: dsahern, yhs, netdev, oss-drivers
In-Reply-To: <20180430155938.1387-1-quentin.monnet@netronome.com>
On 30/04/18 16:59, Quentin Monnet wrote:
> The Python script used to parse and extract eBPF helpers documentation
> from include/uapi/linux/bpf.h expects a very specific formatting for the
> descriptions (single dots represent a space, '>' stands for a tab):
>
> /*
> ...
> *.int bpf_helper(list of arguments)
> *.> Description
> *.> > Start of description
> *.> > Another line of description
> *.> > And yet another line of description
> *.> Return
> *.> > 0 on success, or a negative error in case of failure
> ...
> */
>
> This is too strict, and painful for developers who wants to add
> documentation for new helpers. Worse, it is extremelly difficult to
> check that the formatting is correct during reviews. Change the
> format expected by the script and make it more flexible. The script now
> works whether or not the initial space (right after the star) is
> present, and accepts both tabs and white spaces (or a combination of
> both) for indenting description sections and contents.
>
> Concretely, something like the following would now be supported:
>
> /*
> ...
> *int bpf_helper(list of arguments)
> *......Description
> *.> > Start of description...
> *> > Another line of description
> *..............And yet another line of description
> *> Return
> *.> ........0 on success, or a negative error in case of failure
> ...
> */
>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> ---
> scripts/bpf_helpers_doc.py | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/scripts/bpf_helpers_doc.py b/scripts/bpf_helpers_doc.py
> index 30ba0fee36e4..717547e6f0a6 100755
> --- a/scripts/bpf_helpers_doc.py
> +++ b/scripts/bpf_helpers_doc.py
> @@ -87,7 +87,7 @@ class HeaderParser(object):
> # - Same as above, with "const" and/or "struct" in front of type
> # - "..." (undefined number of arguments, for bpf_trace_printk())
> # There is at least one term ("void"), and at most five arguments.
> - p = re.compile('^ \* ((.+) \**\w+\((((const )?(struct )?(\w+|\.\.\.)( \**\w+)?)(, )?){1,5}\))$')
> + p = re.compile('^ \* ?((.+) \**\w+\((((const )?(struct )?(\w+|\.\.\.)( \**\w+)?)(, )?){1,5}\))$')
The proper coding style for such things is to go straight to tabs after
the star and not have the space. So if we're going to make the script
flexible here (and leave coding style enforcement to other tools such
as checkpatch), maybe the regexen should just begin '^ \*\s+' and avoid
relying on counting indentation to delimit sections (e.g. scan for the
section headers like '^ \*\s+Description$' instead).
Btw, leading '^' is unnecessary as re.match() is already implicitly
anchored at start-of-string. (The trailing '$' are still needed.)
-Ed
^ permalink raw reply
* Re: Performance regressions in TCP_STREAM tests in Linux 4.15 (and later)
From: Eric Dumazet @ 2018-04-30 16:36 UTC (permalink / raw)
To: Ben Greear, Steven Rostedt, Michael Wenig
Cc: netdev@vger.kernel.org, Shilpi Agarwal, Boon Ang, Darren Hart,
Steven Rostedt, Abdul Anshad Azeez
In-Reply-To: <476bfc0f-eb2d-fe57-73d9-ec8a8392ad33@candelatech.com>
On 04/30/2018 09:14 AM, Ben Greear wrote:
> On 04/27/2018 08:11 PM, Steven Rostedt wrote:
>>
>> We'd like this email archived in netdev list, but since netdev is
>> notorious for blocking outlook email as spam, it didn't go through. So
>> I'm replying here to help get it into the archives.
>>
>> Thanks!
>>
>> -- Steve
>>
>>
>> On Fri, 27 Apr 2018 23:05:46 +0000
>> Michael Wenig <mwenig@vmware.com> wrote:
>>
>>> As part of VMware's performance testing with the Linux 4.15 kernel,
>>> we identified CPU cost and throughput regressions when comparing to
>>> the Linux 4.14 kernel. The impacted test cases are mostly TCP_STREAM
>>> send tests when using small message sizes. The regressions are
>>> significant (up 3x) and were tracked down to be a side effect of Eric
>>> Dumazat's RB tree changes that went into the Linux 4.15 kernel.
>>> Further investigation showed our use of the TCP_NODELAY flag in
>>> conjunction with Eric's change caused the regressions to show and
>>> simply disabling TCP_NODELAY brought performance back to normal.
>>> Eric's change also resulted into significant improvements in our
>>> TCP_RR test cases.
>>>
>>>
>>>
>>> Based on these results, our theory is that Eric's change made the
>>> system overall faster (reduced latency) but as a side effect less
>>> aggregation is happening (with TCP_NODELAY) and that results in lower
>>> throughput. Previously even though TCP_NODELAY was set, system was
>>> slower and we still got some benefit of aggregation. Aggregation
>>> helps in better efficiency and higher throughput although it can
>>> increase the latency. If you are seeing a regression in your
>>> application throughput after this change, using TCP_NODELAY might
>>> help bring performance back however that might increase latency.
>
> I guess you mean _disabling_ TCP_NODELAY instead of _using_ TCP_NODELAY?
>
Yeah, I guess auto-corking does not work as intended.
^ permalink raw reply
* Re: [RFC net-next 0/5] Support for PHY test modes
From: Andrew Lunn @ 2018-04-30 16:40 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, netdev, rmk, linux-kernel, cphealy, nikita.yoush,
vivien.didelot, Nisar.Sayed, UNGLinuxDriver
In-Reply-To: <eea70076-891c-5caa-a590-ef1b0421f3b2@gmail.com>
> Turning these tests on will typically result in the link partner
> dropping the link with us, and the interface will be non-functional as
> far as the data path is concerned (similar to an isolation mode). This
> might warrant properly reporting that to user-space through e.g: a
> private IFF_* value maybe?
Hi Florian
I've not looked at the code yet....
Is it also necessary to kick off auto-neg again after the test has
finished, in order to reestablish the link?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: core: Assert the size of netdev_featres_t
From: Stephen Hemminger @ 2018-04-30 16:42 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, edumazet
In-Reply-To: <20180427201114.28830-1-f.fainelli@gmail.com>
On Fri, 27 Apr 2018 13:11:14 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> We have about 53 netdev_features_t bits defined and counting, add a
> build time check to catch when an u64 type will not be enough and we
> will have to convert that to a bitmap. This is done in
> register_netdevice() for convenience.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> include/linux/netdevice.h | 6 ++++++
> net/core/dev.c | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 366c32891158..4326bc6b27d1 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -4121,6 +4121,12 @@ const char *netdev_drivername(const struct net_device *dev);
>
> void linkwatch_run_queue(void);
>
> +static inline void netdev_features_size_check(void)
> +{
> + BUILD_BUG_ON(sizeof(netdev_features_t) * BITS_PER_BYTE <
> + NETDEV_FEATURE_COUNT);
> +}
> +
> static inline netdev_features_t netdev_intersect_features(netdev_features_t f1,
> netdev_features_t f2)
> {
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0a2d46424069..23e6c1aa78c6 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7881,6 +7881,7 @@ int register_netdevice(struct net_device *dev)
> int ret;
> struct net *net = dev_net(dev);
>
> + netdev_features_size_check();
> BUG_ON(dev_boot_phase);
> ASSERT_RTNL();
>
You don't have do this kind of inline function stuff to get the check.
Why not just put BUILD_BUG_ON directly in net/core/dev.c Could be anywhere.
Rather than adding inline in the header file.
^ permalink raw reply
* Re: [PATCH net-next v3 0/6] mlxsw: SPAN: Support routes pointing at bridges
From: David Miller @ 2018-04-30 16:44 UTC (permalink / raw)
To: idosch; +Cc: mlxsw, nikolay, netdev, bridge, jiri, petrm
In-Reply-To: <20180429075613.10832-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Sun, 29 Apr 2018 10:56:07 +0300
> Petr says:
>
> When mirroring to a gretap or ip6gretap netdevice, the route that
> directs the encapsulated packets can reference a bridge. In that case,
> in the software model, the packet is switched.
>
> Thus when offloading mirroring like that, take into consideration FDB,
> STP, PVID configured at the bridge, and whether that VLAN ID should be
> tagged on egress.
>
> Patch #1 introduces functions to get bridge PVID, VLAN flags and to look
> up an FDB entry.
>
> Patches #2 and #3 refactor some existing code and introduce a new
> accessor function.
>
> With patches #4 and #5 mlxsw calls mlxsw_sp_span_respin() on switchdev
> events as well. There is no impact yet, because bridge as an underlay
> device is still not allowed.
>
> That is implemented in patch #6, which uses the new interfaces to figure
> out on which one port the mirroring should be configured, and whether
> the mirrored packets should be VLAN-tagged and how.
>
> Changes from v2 to v3:
>
> - Rename the suite of bridge accessor function to br_vlan_get_pvid(),
> br_vlan_get_info() and br_fdb_find_port(). The _get bit is to avoid
> clashing with an existing static function.
>
> Changes from v1 to v2:
>
> - Change the suite of bridge accessor functions to br_vlan_pvid_rtnl(),
> br_vlan_info_rtnl(), br_fdb_find_port_rtnl().
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] ethtool: fix a potential missing-check bug
From: Shannon Nelson @ 2018-04-30 16:46 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, David S. Miller, Florian Fainelli, Andrew Lunn,
Russell King, Edward Cree, Inbar Karmy, Eugenia Emantayev,
Al Viro, Yury Norov, Vidya Sagar Ravipati, Alan Brady,
Stephen Hemminger, open list:NETWORKING [GENERAL], open list
In-Reply-To: <1525051915-31944-1-git-send-email-wang6495@umn.edu>
On 4/29/2018 6:31 PM, Wenwen Wang wrote:
> In ethtool_get_rxnfc(), the object "info" is firstly copied from
> user-space. If the FLOW_RSS flag is set in the member field flow_type of
> "info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
> user-space because FLOW_RSS is newer and has new definition, as mentioned
> in the comment. However, given that the user data resides in user-space, a
> malicious user can race to change the data after the first copy. By doing
> so, the user can inject inconsistent data. For example, in the second
> copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
> In the following execution, "info" will be used in the function
> ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
> information leakage since ops->get_rxnfc() will prepare various types of
> data according to flow_type, and the prepared data will be eventually
> copied to user-space. This inconsistent data may also cause undefined
> behaviors based on how ops->get_rxnfc() is implemented.
>
> This patch re-verifies the flow_type field of "info" after the second copy.
> If the value is not as expected, an error code will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> net/core/ethtool.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 03416e6..a121034 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
> info_size = sizeof(info);
> if (copy_from_user(&info, useraddr, info_size))
> return -EFAULT;
You might add a comment here to explain why the second check; otherwise
someone might come along later and remove this check as redundant code.
sln
> + if (!(info.flow_type & FLOW_RSS))
> + return -EINVAL;
> }
>
> if (info.cmd == ETHTOOL_GRXCLSRLALL) {
>
^ permalink raw reply
* [net-next 4/9] i40e: Add advertising 10G LR mode
From: Jeff Kirsher @ 2018-04-30 17:00 UTC (permalink / raw)
To: davem; +Cc: Jakub Pawlak, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180430170059.13186-1-jeffrey.t.kirsher@intel.com>
From: Jakub Pawlak <jakub.pawlak@intel.com>
The advertising 10G LR mode should be possible to set
but in the function i40e_set_link_ksettings() check for this
is missed. This patch adds check for 10000baseLR_Full
flag for 10G modes.
Signed-off-by: Jakub Pawlak <jakub.pawlak@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index c1bbfb913e49..fc6a5eef141c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -953,7 +953,9 @@ static int i40e_set_link_ksettings(struct net_device *netdev,
ethtool_link_ksettings_test_link_mode(ks, advertising,
10000baseCR_Full) ||
ethtool_link_ksettings_test_link_mode(ks, advertising,
- 10000baseSR_Full))
+ 10000baseSR_Full) ||
+ ethtool_link_ksettings_test_link_mode(ks, advertising,
+ 10000baseLR_Full))
config.link_speed |= I40E_LINK_SPEED_10GB;
if (ethtool_link_ksettings_test_link_mode(ks, advertising,
20000baseKR2_Full))
--
2.14.3
^ permalink raw reply related
* [net-next 5/9] i40evf: Fix turning TSO, GSO and GRO on after
From: Jeff Kirsher @ 2018-04-30 17:00 UTC (permalink / raw)
To: davem
Cc: Paweł Jabłoński, netdev, nhorman, sassmann,
jogreene, Jeff Kirsher
In-Reply-To: <20180430170059.13186-1-jeffrey.t.kirsher@intel.com>
From: Paweł Jabłoński <pawel.jablonski@intel.com>
This patch fixes the problem where each MTU change turns TSO,
GSO and GRO on from off state.
Now when TSO, GSO or GRO is turned off, MTU change does not
turn them on.
Signed-off-by: Paweł Jabłoński <pawel.jablonski@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 28a8cc4a14cb..3f04a182903d 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -3357,6 +3357,24 @@ int i40evf_process_config(struct i40evf_adapter *adapter)
if (vfres->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN)
netdev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
+ /* Do not turn on offloads when they are requested to be turned off.
+ * TSO needs minimum 576 bytes to work correctly.
+ */
+ if (netdev->wanted_features) {
+ if (!(netdev->wanted_features & NETIF_F_TSO) ||
+ netdev->mtu < 576)
+ netdev->features &= ~NETIF_F_TSO;
+ if (!(netdev->wanted_features & NETIF_F_TSO6) ||
+ netdev->mtu < 576)
+ netdev->features &= ~NETIF_F_TSO6;
+ if (!(netdev->wanted_features & NETIF_F_TSO_ECN))
+ netdev->features &= ~NETIF_F_TSO_ECN;
+ if (!(netdev->wanted_features & NETIF_F_GRO))
+ netdev->features &= ~NETIF_F_GRO;
+ if (!(netdev->wanted_features & NETIF_F_GSO))
+ netdev->features &= ~NETIF_F_GSO;
+ }
+
adapter->vsi.id = adapter->vsi_res->vsi_id;
adapter->vsi.back = adapter;
--
2.14.3
^ permalink raw reply related
* [net-next 1/9] i40evf: Replace GFP_ATOMIC with GFP_KERNEL in i40evf_add_vlan
From: Jeff Kirsher @ 2018-04-30 17:00 UTC (permalink / raw)
To: davem; +Cc: Jia-Ju Bai, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180430170059.13186-1-jeffrey.t.kirsher@intel.com>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
i40evf_add_vlan() is never called in atomic context.
i40evf_add_vlan() is only called by i40evf_vlan_rx_add_vid(),
which is only set as ".ndo_vlan_rx_add_vid" in struct net_device_ops.
".ndo_vlan_rx_add_vid" is not called in atomic context.
Despite never getting called from atomic context,
i40evf_add_vlan() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 97cda4a8f8e0..8f775a82e2fa 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -681,7 +681,7 @@ i40evf_vlan_filter *i40evf_add_vlan(struct i40evf_adapter *adapter, u16 vlan)
f = i40evf_find_vlan(adapter, vlan);
if (!f) {
- f = kzalloc(sizeof(*f), GFP_ATOMIC);
+ f = kzalloc(sizeof(*f), GFP_KERNEL);
if (!f)
goto clearout;
--
2.14.3
^ permalink raw reply related
* [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2018-04-30
From: Jeff Kirsher @ 2018-04-30 17:00 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to i40e and i40evf only.
Jia-Ju Bai replaces an instance of GFP_ATOMIC to GFP_KERNEL, since
i40evf is not in atomic context when i40evf_add_vlan() is called.
Jake cleans up function header comments to ensure that the function
parameter comments actually match the function parameters. Fixed a
possible overflow error in the PTP clock code. Fixed warnings regarding
restricted __be32 type usage.
Mariusz fixes the reading of the LLDP configuration, which moves from
using relative values to calculating the absolute address.
Jakub adds a check for 10G LR mode for i40e.
Paweł fixes an issue, where changing the MTU would turn on TSO, GSO and
GRO.
Alex fixes a couple of issues with the UDP tunnel filter configuration.
First being that the tunnels did not have mutual exclusion in place to
prevent a race condition between a user request to add/remove a port and
an update. The second issue was we were deleting filters that were not
associated with the actual filter we wanted to delete.
Harshitha ensures that the queue map sent by the VF is taken into
account when enabling/disabling queues in the VF VSI.
The following are changes since commit 76c2a96d42ca3bdac12c463ff27fec3bb2982e3f:
liquidio: fix spelling mistake: "mac_tx_multi_collison" -> "mac_tx_multi_collision"
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Alexander Duyck (1):
i40e: Fix multiple issues with UDP tunnel offload filter configuration
Harshitha Ramamurthy (1):
i40e/i40evf: take into account queue map from vf when handling queues
Jacob Keller (3):
i40e/i40evf: cleanup incorrect function doxygen comments
i40e: avoid overflow in i40e_ptp_adjfreq()
i40e: use %pI4b instead of byte swapping before dev_err
Jakub Pawlak (1):
i40e: Add advertising 10G LR mode
Jia-Ju Bai (1):
i40evf: Replace GFP_ATOMIC with GFP_KERNEL in i40evf_add_vlan
Mariusz Stachura (1):
i40e: fix reading LLDP configuration
Paweł Jabłoński (1):
i40evf: Fix turning TSO, GSO and GRO on after
drivers/net/ethernet/intel/i40e/i40e.h | 7 +-
drivers/net/ethernet/intel/i40e/i40e_client.c | 6 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 37 +++---
drivers/net/ethernet/intel/i40e/i40e_dcb.c | 91 ++++++++++++--
drivers/net/ethernet/intel/i40e/i40e_dcb_nl.c | 11 +-
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 8 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 28 +++--
drivers/net/ethernet/intel/i40e/i40e_hmc.c | 1 -
drivers/net/ethernet/intel/i40e/i40e_main.c | 134 ++++++++++++++++-----
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 45 ++++---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 6 +-
drivers/net/ethernet/intel/i40e/i40e_type.h | 8 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 85 +++++++++++--
drivers/net/ethernet/intel/i40evf/i40e_common.c | 1 +
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 4 +-
drivers/net/ethernet/intel/i40evf/i40e_type.h | 10 +-
drivers/net/ethernet/intel/i40evf/i40evf_client.c | 4 +-
drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 7 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 25 +++-
.../net/ethernet/intel/i40evf/i40evf_virtchnl.c | 11 +-
21 files changed, 401 insertions(+), 129 deletions(-)
--
2.14.3
^ 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