在 2018-04-03二的 11:50 +0200，Maxime Ripard写道：
> On Tue, Apr 03, 2018 at 11:48:45AM +0200, Maxime Ripard wrote:
> > On Tue, Mar 20, 2018 at 03:15:02PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Mar 19, 2018 at 5:31 AM, Maxime Ripard
> > > wrote:
> > > > On Sat, Mar 17, 2018 at 05:28:47PM +0800, Chen-Yu
On 04/04/2018 01:36 AM, Eric Dumazet wrote:
On 04/03/2018 03:04 PM, Gustavo A. R. Silva wrote:
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add n
On 04/03/2018 03:04 PM, Gustavo A. R. Silva wrote:
> Add null check on kmalloc() return value in order to prevent
> a null pointer dereference.
>
> Addresses-Coverity-ID: 1467429 ("Dereference null return value")
> Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
> implementati
Wed, Apr 04, 2018 at 02:47:19AM CEST, dsah...@gmail.com wrote:
>On 4/3/18 9:30 AM, Jiri Pirko wrote:
>> Tue, Apr 03, 2018 at 04:33:11PM CEST, dsah...@gmail.com wrote:
>>> On 4/3/18 1:32 AM, Jiri Pirko wrote:
Fri, Mar 30, 2018 at 04:45:50PM CEST, dsah...@gmail.com wrote:
> On 3/29/18 2:33 P
Wed, Apr 04, 2018 at 03:04:26AM CEST, dsah...@gmail.com wrote:
>On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>>
>>> There are other use cases that want to hide a device from userspace. I
>>
>> What usecases do you have in mind?
>
>As mentioned in a previous response some kernel drivers create control
>ne
On Sun, 1 Apr 2018 20:47:28 -0400 Md. Islam" wrote:
> [...] More specifically, header parsing and fib
> lookup only takes around 82 ns. This shows that this could be used to
> implement linerate packet forwarding in kernel.
I cannot resist correcting you...
You didn't specify the link speed, b
On Tue, Apr 03, 2018 at 08:32:36AM -0500, Steve Wise wrote:
>
>
> > -Original Message-
> > From: Leon Romanovsky
> > Sent: Tuesday, April 3, 2018 2:29 AM
> > To: Stephen Hemminger
> > Cc: Leon Romanovsky ; netdev
> > ; RDMA mailing list > r...@vger.kernel.org>; David Ahern ; Steve Wise
>
On Tue, Apr 3, 2018 at 4:42 AM, Kirill Tkhai wrote:
> On 03.04.2018 14:25, Dmitry Vyukov wrote:
>> On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai wrote:
>>> sk_diag_dump_icons() dumps only sockets in TCP_LISTEN state.
>>> TCP_LISTEN state may be assigned in only place in net/unix/af_unix.c:
>>> it
On Tue, Apr 3, 2018 at 8:05 PM, Andrew Lunn wrote:
>> Suppose you want to create and assign a network interface to a KVM
>> virtual machine, you would do something like the following using
>> a user space tool like restool:
>>-create a new (empty) dprc object
>>-create a new dpni and assig
On Tue, Apr 3, 2018 at 9:16 PM, David Ahern wrote:
> On 4/1/18 6:47 PM, Md. Islam wrote:
>> This patch implements IPv4 forwarding on xdp_buff. I added a new
>> config option XDP_ROUTER. Kernel would forward packets through fast
>> path when this option is enabled. But it would require driver suppo
On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger wrote:
(...)
As the antenna selection code changes affected your first bisection, do you
have one of those HP laptops with only one antenna and the incorrect coding
in the FUSE?
Yes, that is wh
On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger wrote:
(...)
> As the antenna selection code changes affected your first bisection, do you
> have one of those HP laptops with only one antenna and the incorrect coding
> in the FUSE?
Yes, that is why I've been passing ant_sel=1 during my tests -- th
On 04/03/2018 08:51 PM, João Paulo Rechi Vita wrote:
Hello,
I've been trying to track a performance regression on the RTL8723BE
WiFi adapter, which mainly affects the upload bandwidth (although we
can see a decreased download performance as well, the effect on upload
is more drastic). This was f
>On Tue, Apr 03, 2018 at 12:29:47PM +, haibinzhang wrote:
>> >On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang wrote:
>> >> handle_tx will delay rx for a long time when tx busy polling udp packets
>> >> with small length(e.g. 1byte udp payload), because setting
>> >> VHOST_NET_WEIGHT
>>
Hello,
I've been trying to track a performance regression on the RTL8723BE
WiFi adapter, which mainly affects the upload bandwidth (although we
can see a decreased download performance as well, the effect on upload
is more drastic). This was first reported by users after upgrading
from our 4.11-ba
On 4/1/18 6:47 PM, Md. Islam wrote:
> This patch implements IPv4 forwarding on xdp_buff. I added a new
> config option XDP_ROUTER. Kernel would forward packets through fast
> path when this option is enabled. But it would require driver support.
> Currently it only works with veth. Here I have modi
On 4/3/18 11:37 AM, Alexei Starovoitov wrote:
> On Tue, Apr 03, 2018 at 11:14:00AM -0600, David Ahern wrote:
>> On 4/3/18 11:06 AM, Alexei Starovoitov wrote:
For 3 and 4 above I was referring to the route lookup part of it; sorry
for not being clear.
For example, eth1 is enslave
> Suppose you want to create and assign a network interface to a KVM
> virtual machine, you would do something like the following using
> a user space tool like restool:
>-create a new (empty) dprc object
>-create a new dpni and assign it to the dprc
>-create a new dpio and assign it to
On 4/3/18 9:42 AM, Jiri Pirko wrote:
>>
>> There are other use cases that want to hide a device from userspace. I
>
> What usecases do you have in mind?
As mentioned in a previous response some kernel drivers create control
netdevs. Just as in this case users should not be mucking with it, and
S/
On 4/3/18 9:30 AM, Jiri Pirko wrote:
> Tue, Apr 03, 2018 at 04:33:11PM CEST, dsah...@gmail.com wrote:
>> On 4/3/18 1:32 AM, Jiri Pirko wrote:
>>> Fri, Mar 30, 2018 at 04:45:50PM CEST, dsah...@gmail.com wrote:
On 3/29/18 2:33 PM, Ido Schimmel wrote:
> From: Jiri Pirko
>
> This reso
From: Dirk van der Merwe
The NSP default buffer is a piece of NFP memory where additional
command data can be placed. Its format has been copied from
host buffer, but the PCIe selection bits do not make sense in
this case. If those get masked out from a NFP address - writes
to random place in t
On 04/03/2018 05:14 PM, Jakub Kicinski wrote:
> Some popular NIC vendors are not adhering to
> netif_get_num_default_rss_queues() which leads to users being
> surprised and filing bugs :) Bump the number of default RX
> queues to something more reasonable for modern machines.
>
> Signed-off-by:
Some popular NIC vendors are not adhering to
netif_get_num_default_rss_queues() which leads to users being
surprised and filing bugs :) Bump the number of default RX
queues to something more reasonable for modern machines.
Signed-off-by: Jakub Kicinski
---
I'm mostly wondering what's the policy
On Wed, Mar 28, 2018 at 10:43 AM, Arnd Bergmann wrote:
> On Wed, Mar 28, 2018 at 4:27 PM, Ioana Ciornei wrote:
>> Hi,
>>
>>>
>>> Hi Ioana,
>>>
>>> So this driver is a direct passthrough to your hardware for passing fixed-
>>> length command/response pairs. Have you considered using a higher-level
On Tue, Apr 03, 2018 at 02:39:11PM +0100, Edward Cree wrote:
> On 03/04/18 02:08, Alexei Starovoitov wrote:
> > I like patch 3 and going to play with it.
> > How did you test it ?
> Just test_verifier and test_progs (the latter has a failure
> "test_bpf_obj_id:FAIL:get-prog-info(fd) err 0 errno 2
On Tue, 3 Apr 2018 17:55:25 -0400
Jon Rosen wrote:
> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> casues the ring to get corrupted by allowing multiple kernel threads
> to claim ownership of the same ring entry, Mark the ring entry as
> already being used within the spin
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
implementation for VF")
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2
When using wicked with a lan78xx device attached to the system, we
end up with ethtool commands issued on the device before an ifup
got issued. That lead to the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 039c
pgd = 800035b3
[039
Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
casues the ring to get corrupted by allowing multiple kernel threads
to claim ownership of the same ring entry, Mark the ring entry as
already being used within the spin_lock to prevent other kernel
threads from reusing the same en
On 04/03/2018 04:47 PM, Eric Dumazet wrote:
On 04/03/2018 02:29 PM, Gustavo A. R. Silva wrote:
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add n
On 04/03/2018 02:29 PM, Gustavo A. R. Silva wrote:
> Add null check on kmalloc() return value in order to prevent
> a null pointer dereference.
>
> Addresses-Coverity-ID: 1467429 ("Dereference null return value")
> Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
> implementati
Add null check on kmalloc() return value in order to prevent
a null pointer dereference.
Addresses-Coverity-ID: 1467429 ("Dereference null return value")
Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback
implementation for VF")
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/
This patch provides a basic function to allow a lower device to disable
macvlan offload if it was previously enabled on a given macvlan. The idea
here is to allow for recovery from failure should the lowerdev run out of
resources.
Signed-off-by: Alexander Duyck
---
include/linux/if_macvlan.h |
Drop the code for handling macvlan specific unicast lists. It isn't needed
since we don't take any efforts to maintain it when we bring the interface
up and it takes the slow path anyway.
Signed-off-by: Alexander Duyck
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 31
Both the ixgbe and fm10k drivers support destination filtering.
Instead of adding a ton of complexity to support either source or passthru
mode we can instead just avoid offloading them for now. Doing this we avoid
leaking packets into interfaces that aren't meant to receive them.
Signed-off-by:
It doesn't make sense to define macvlan_count_rx as a static inline and
then add a forward declaration after that as an extern. I am dropping the
extern declaration since it seems like it is something that likely got
missed when the function was made an inline.
Signed-off-by: Alexander Duyck
---
The original implementation for macvlan offload has us performing a full
port reset every time we added a new macvlan. This shouldn't be necessary
and can be avoided with a few behavior changes.
This patches updates the logic for the queues so that we have essentially 3
possible configurations for
This patch drops the real_adapter member from the fwd_adapter structure.
The general idea behind the change is that the real_adapter is carrying
unnecessary data since we could always just grab the adapter structure
from netdev_priv(macvlan->lowerdev) if we really needed to get at it.
Signed-off-b
This patch adds a function indicating if a given macvlan can fully supports
destination filtering, especially as it relates to unicast traffic. For
those macvlan interfaces that do not support destination filtering such
passthru or source mode filtering we should not be enabling offload
support.
S
This change makes it so that we use a software path for packets that are
going to be locally switched between two macvlan interfaces on the same
device. In addition we resort to software replication of broadcast and
multicast packets instead of offloading that to hardware.
The general idea is that
Drop dead code now that we shouldn't be receiving broadcast or multicast
frames on the queues associated to the macvlan netdev.
Signed-off-by: Alexander Duyck
---
drivers/net/ethernet/intel/fm10k/fm10k_main.c |7 +++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |7 +++
2 files c
This change renames the fwd_priv member to accel_priv as this more
accurately reflects the actual purpose of this value. In addition I am
adding an accessor which will allow us to further abstract this in the
future if needed.
Signed-off-by: Alexander Duyck
---
drivers/net/ethernet/intel/ixgbe/i
This patch set represents yet another phase of the macvlan cleanup I have
been working on.
The main goal of these changes is to make it so that we only support
offloading what we can actually offload and we don't break any existing
functionality. So for example we were claiming to advertise source
On 04/03/2018 09:45 AM, Al Viro wrote:
> On Tue, Apr 03, 2018 at 12:33:05PM -0400, David Miller wrote:
>
>> Yes Al, however the pattern choosen here is probably cheaper on little
>> endian:
>>
>> __beXX val = x;
>> switch (val) {
>> case htons(ETH_P_FOO):
>> ...
>> }
>>
Em Fri, Mar 30, 2018 at 11:26:33AM -0700, Martin KaFai Lau escreveu:
> This patch introduces BPF Type Format (BTF).
>
> BTF (BPF Type Format) is the meta data format which describes
> the data types of BPF program/map. Hence, it basically focus
> on the C programming language which the modern BPF
Signed-off-by: Roman Mashak
---
tc/m_skbedit.c | 53 +
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/tc/m_skbedit.c b/tc/m_skbedit.c
index db5c64caf2ba..070280cea29e 100644
--- a/tc/m_skbedit.c
+++ b/tc/m_skbedit.c
@@ -168,9 +1
On Tue, Apr 3, 2018 at 8:42 AM, Jiri Pirko wrote:
> Sun, Apr 01, 2018 at 06:11:29PM CEST, dsah...@gmail.com wrote:
>>On 4/1/18 3:13 AM, Si-Wei Liu wrote:
>>> Hidden netdevice is not visible to userspace such that
>>> typical network utilites e.g. ip, ifconfig and et al,
>>> cannot sense its existe
On Apr 3, 2018, at 11:27 AM, Michael S. Tsirkin wrote:
I'm not sure why you would need a feature bit. The capability is
controlled via PCI configuration space. If it is present the device
has the capability. If it is not then it does not.
Basically if the PCI configuration space is not present
On Tue, Apr 3, 2018 at 11:27 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 03, 2018 at 10:32:00AM -0700, Alexander Duyck wrote:
>> On Tue, Apr 3, 2018 at 6:12 AM, Michael S. Tsirkin wrote:
>> > On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote:
>> >> On Fri, Mar 16, 2018 at 9:34 AM, M
On Tue, Apr 03, 2018 at 10:32:00AM -0700, Alexander Duyck wrote:
> On Tue, Apr 3, 2018 at 6:12 AM, Michael S. Tsirkin wrote:
> > On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote:
> >> On Fri, Mar 16, 2018 at 9:34 AM, Michael S. Tsirkin
> >> wrote:
> >> > On Thu, Mar 15, 2018 at 11
On Tue, 2018-04-03 at 13:50 -0400, Sinan Kaya wrote:
> > > What do you think about this version? Did I miss any SMP
> > > barriers?
> >
> > I would say we should probably just drop the whole set and start
> > over.
> > If we don't need the wmb() we are going to need to go through and
> > clean up
On Tue, 3 Apr 2018 11:00:20 -0600 David Ahern wrote:
> On 4/3/18 10:41 AM, John Fastabend wrote:
> > On 04/03/2018 08:07 AM, David Ahern wrote:
> >> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
> >>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
> On 4/2/18 12:03 PM, J
On 4/3/2018 1:47 PM, Alexander Duyck wrote:
> On Mon, Apr 2, 2018 at 7:59 PM, Sinan Kaya wrote:
>> Alex,
>>
>> On 4/2/2018 3:06 PM, Sinan Kaya wrote:
>>> Code includes wmb() followed by writel() in multiple places. writel()
>>> already has a barrier on some architectures like arm64.
>>>
>>> This e
On Mon, Apr 2, 2018 at 7:59 PM, Sinan Kaya wrote:
> Alex,
>
> On 4/2/2018 3:06 PM, Sinan Kaya wrote:
>> Code includes wmb() followed by writel() in multiple places. writel()
>> already has a barrier on some architectures like arm64.
>>
>> This ends up CPU observing two barriers back to back before
On Tue, Apr 03, 2018 at 11:14:00AM -0600, David Ahern wrote:
> On 4/3/18 11:06 AM, Alexei Starovoitov wrote:
> >> For 3 and 4 above I was referring to the route lookup part of it; sorry
> >> for not being clear.
> >>
> >> For example, eth1 is enslaved to bond1 which is in VRF red. The lookup
> >> n
On Sun, 1 Apr 2018 05:13:09 -0400
Si-Wei Liu wrote:
> Hidden netdevice is not visible to userspace such that
> typical network utilites e.g. ip, ifconfig and et al,
> cannot sense its existence or configure it. Internally
> hidden netdev may associate with an upper level netdev
> that userspace
On Tue, Apr 3, 2018 at 6:12 AM, Michael S. Tsirkin wrote:
> On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote:
>> On Fri, Mar 16, 2018 at 9:34 AM, Michael S. Tsirkin wrote:
>> > On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote:
>> >> From: Alexander Duyck
>> >>
>> >>
On Tue, 2018-04-03 at 10:02 -0700, Florian Fainelli wrote:
> On 04/02/2018 07:18 PM, Sean Wang wrote:
> > On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote:
> >> We would be passing 0 instead of NULL as the rsp argument to
> >> mt7530_fdb_cmd(), fix that.
> >>
> >
> > Acked-by: Sean Wang
#syz dup: general protection fault in __list_del_entry_valid (3)
> -Original Message-
> From: syzbot
> [mailto:syzbot+4859fe19555ea87c4...@syzkaller.appspotmail.com]
> Sent: Monday, April 02, 2018 02:01
> To: da...@davemloft.net; Jon Maloy ; linux-
> ker...@vger.kernel.org; netdev@vger.ker
On 4/3/18 11:06 AM, Alexei Starovoitov wrote:
>> For 3 and 4 above I was referring to the route lookup part of it; sorry
>> for not being clear.
>>
>> For example, eth1 is enslaved to bond1 which is in VRF red. The lookup
>> needs to go to the table associated with the VRF. That is not known by
>>
When an item of struct tipc_subscription is created, we fail to
initialize the two lists aggregated into the struct. This has so far
never been a problem, since the items are just added to a root
object by list_add(), which does not require the addee list to be
pre-initialized. However, syzbot is p
On Tue, Apr 03, 2018 at 11:00:20AM -0600, David Ahern wrote:
> On 4/3/18 10:41 AM, John Fastabend wrote:
> > On 04/03/2018 08:07 AM, David Ahern wrote:
> >> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
> >>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
> On 4/2/18 12:03 PM, Jo
On Tue, Apr 3, 2018 at 9:23 AM, David Miller wrote:
> From: Jesper Dangaard Brouer
> Date: Tue, 3 Apr 2018 18:07:16 +0200
>
>> On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
>> David Miller wrote:
>>
>>> Don't worry, just resubmit when net-next opens back up.
>>
>> At that point in time, should I got
On 04/02/2018 07:18 PM, Sean Wang wrote:
> On Mon, 2018-04-02 at 16:24 -0700, Florian Fainelli wrote:
>> We would be passing 0 instead of NULL as the rsp argument to
>> mt7530_fdb_cmd(), fix that.
>>
>
> Acked-by: Sean Wang
>
> BTW, does the part of the commit message should be updated with "pas
On 4/3/18 10:41 AM, John Fastabend wrote:
> On 04/03/2018 08:07 AM, David Ahern wrote:
>> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
>>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
On 4/2/18 12:03 PM, John Fastabend wrote:
>
> Can the above be a normal BPF helper th
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Tuesday, April 03, 2018 7:06 AM
> To: Jacob Keller
> Cc: Tal Gilboa ; Tariq Toukan ;
> Keller, Jacob E ; Ariel Elior
> ;
> Ganesh Goudar ; Kirsher, Jeffrey T
> ; everest-linux...@cavium.com; intel-wired-
> l...
On Tue, Apr 03, 2018 at 12:33:05PM -0400, David Miller wrote:
> Yes Al, however the pattern choosen here is probably cheaper on little endian:
>
> __beXX val = x;
> switch (val) {
> case htons(ETH_P_FOO):
>...
> }
>
> This way only the compiler byte swaps the cons
From: John Fastabend
Date: Tue, 3 Apr 2018 09:41:08 -0700
> On 04/03/2018 08:07 AM, David Ahern wrote:
>> 4. What about other stacked devices - bonds and bridges - will those
>> just work with the bpf helper? VRF is already handled of course. ;-)
>
> So if we simply handle this like other stacke
On 04/03/2018 08:07 AM, David Ahern wrote:
> On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
>> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
>>> On 4/2/18 12:03 PM, John Fastabend wrote:
Can the above be a normal BPF helper that returns an
ifindex? Then something roughl
From: Al Viro
Date: Tue, 3 Apr 2018 17:29:33 +0100
> On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote:
>> skb->protocol is a __be16 which we would be calling htons() against,
>> while this is not wrong per-se as it correctly results in swapping the
>> value on LE hosts, this still
On Mon, Apr 02, 2018 at 03:58:55PM -0700, Florian Fainelli wrote:
> skb->protocol is a __be16 which we would be calling htons() against,
> while this is not wrong per-se as it correctly results in swapping the
> value on LE hosts, this still upsets sparse. Adopt a similar pattern to
> what other dr
From: Jesper Dangaard Brouer
Date: Tue, 3 Apr 2018 18:07:16 +0200
> On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
> David Miller wrote:
>
>> Don't worry, just resubmit when net-next opens back up.
>
> At that point in time, should I got back to posting it against the
> bpf-next git-tree again? Any
On Mon, Apr 02, 2018 at 03:58:56PM -0700, Florian Fainelli wrote:
> skb->protocol is a __be16 which we would be calling htons() against,
> while this is not wrong per-se as it correctly results in swapping the
> value on LE hosts, this still upsets sparse. Adopt a similar pattern to
> what other dr
On Tue, Apr 03, 2018 at 03:00:06PM +0300, Alexey Kodanev wrote:
> A new RTF_CACHE route can be created with the socket's dst cache
> update between the below calls in udpv6_sendmsg(), when datagram
> sending results to ICMPV6_PKT_TOOBIG error:
>
>dst = ip6_sk_dst_lookup_flow(...)
>...
> re
On Tue, 03 Apr 2018 10:54:27 -0400 (EDT)
David Miller wrote:
> From: Jesper Dangaard Brouer
> Date: Tue, 03 Apr 2018 13:07:36 +0200
>
> > This is V9, but it's worth mentioning that V8 was send against
> > net-next, because i40e got XDP_REDIRECT support in-between V6, and it
> > doesn't exist in
On Tue, Apr 3, 2018 at 11:19 AM Miroslav Lichvar wrote:
>
> I came across an interesting issue with error messages in sockets with
> enabled timestamping using the SOF_TIMESTAMPING_OPT_CMSG option. When
> the socket is connected and there is an error (e.g. due to destination
> unreachable ICMP), s
Sun, Apr 01, 2018 at 06:11:29PM CEST, dsah...@gmail.com wrote:
>On 4/1/18 3:13 AM, Si-Wei Liu wrote:
>> Hidden netdevice is not visible to userspace such that
>> typical network utilites e.g. ip, ifconfig and et al,
>> cannot sense its existence or configure it. Internally
>> hidden netdev may asso
Ignore options "peer-offset" and "offset" when creating sessions. Keep
them when dumping sessions in order to avoid breaking external scripts.
"peer-offset" has always been a noop in iproute2. "offset" is now
ignored in Linux 4.16 (and was broken before that).
Signed-off-by: Guillaume Nault
---
On Tue, Apr 3, 2018 at 5:18 PM, Robert Jarzmik wrote:
> Arnd Bergmann writes:
>
>>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
>>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
>>> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
>>
>> This one is
Tue, Apr 03, 2018 at 04:33:11PM CEST, dsah...@gmail.com wrote:
>On 4/3/18 1:32 AM, Jiri Pirko wrote:
>> Fri, Mar 30, 2018 at 04:45:50PM CEST, dsah...@gmail.com wrote:
>>> On 3/29/18 2:33 PM, Ido Schimmel wrote:
From: Jiri Pirko
This resolves race during initialization where the reso
I came across an interesting issue with error messages in sockets with
enabled timestamping using the SOF_TIMESTAMPING_OPT_CMSG option. When
the socket is connected and there is an error (e.g. due to destination
unreachable ICMP), select() indicates there is an exception on the
socket, but recvmsg(
Arnd Bergmann writes:
>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
>> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
>
> This one is interesting, as you are dealing with an off-chip device,
> and
On 2 April 2018 at 16:26, Robert Jarzmik wrote:
> Hi,
>
> This serie is aimed at removing the dmaengine slave compat use, and transfer
> knowledge of the DMA requestors into architecture code.
>
> This was discussed/advised by Arnd a couple of years back, it's almost time.
>
> The serie is divided
On 4/2/18 12:16 PM, Alexei Starovoitov wrote:
> On Mon, Apr 02, 2018 at 12:09:44PM -0600, David Ahern wrote:
>> On 4/2/18 12:03 PM, John Fastabend wrote:
>>>
>>> Can the above be a normal BPF helper that returns an
>>> ifindex? Then something roughly like this patter would
>>> work for all drivers
On Tue, Apr 03, 2018 at 03:13:19PM +0200, Andrew Lunn wrote:
> Have you tried implementing it using a phandle in the phy node,
> pointing to the time stamping device?
Not yet, but I'll take this up for V2, after the merge window...
Thinking about MII, it really is a 1:1 connection between the MAC
On 4/3/18 1:40 AM, Siwei Liu wrote:
>> There are other use cases that want to hide a device from userspace.
>
> Can you elaborate your case in more details? Looking at the links
> below I realize that the purpose of hiding devices in your case is
> quite different from the our migration case. Part
From: Jesper Dangaard Brouer
Date: Tue, 03 Apr 2018 13:07:36 +0200
> This is V9, but it's worth mentioning that V8 was send against
> net-next, because i40e got XDP_REDIRECT support in-between V6, and it
> doesn't exist in bpf-next yet. Most significant change in V8 was that
> page_pool only get
On 04/03/2018 07:25 AM, David Lebrun wrote:
>
> What about saving and restoring the IPv6 CB, similarly to what TCP does with
> tcp_v6_restore_cb() ?
Note that TCP only moves IPCB around in skb->cb[] for cache locality gains.
Now we switched to rb-tree for out-of-order queue, these gains might
On 4/3/18 1:32 AM, Jiri Pirko wrote:
> Fri, Mar 30, 2018 at 04:45:50PM CEST, dsah...@gmail.com wrote:
>> On 3/29/18 2:33 PM, Ido Schimmel wrote:
>>> From: Jiri Pirko
>>>
>>> This resolves race during initialization where the resources with
>>> ops are registered before driver and the structures us
Hallo Lieber, ich habe eine Spende von 4.600.000,00 Euro, die ich Ihnen geben
möchte, um den Armen und Waisen in Ihrer Gemeinde zu helfen ... Bitte antworten
Sie für weitere Details, um meine Spende zu erhalten
Grüße
Nelma Ruaan
Hi Anton, everyone,
On 04/01/18 15:31, Anton Gary Ceph wrote:
> As the Linux networking stack is growing, more and more protocols are
> added, increasing the complexity of stack itself.
> Modern processors, contrary to common belief, are very bad in branch
> prediction, so it's our task to give hi
On 04/03/2018 02:40 PM, David Lebrun wrote:
On 04/03/2018 12:16 PM, Mathieu Xhonneux wrote:
In patch 2 I was a bit concerned that:
+ struct seg6_bpf_srh_state *srh_state = (struct
seg6_bpf_srh_state *)
+ &skb->cb;
would not collide with othe
On Mon, Apr 02, 2018 at 05:30:54PM -0700, Jacob Keller wrote:
> On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas wrote:
> > +/* PCIe speed to Mb/s reduced by encoding overhead */
> > +#define PCIE_SPEED2MBS_ENC(speed) \
> > + ((speed) == PCIE_SPEED_16_0GT ? (16000*(128/130)) : \
> > +(s
On 04/03/2018 12:16 PM, Mathieu Xhonneux wrote:
In patch 2 I was a bit concerned that:
+ struct seg6_bpf_srh_state *srh_state = (struct seg6_bpf_srh_state *)
+ &skb->cb;
would not collide with other users of skb->cb, but it seems the way
the ho
On 03/04/18 02:08, Alexei Starovoitov wrote:
> I like patch 3 and going to play with it.
> How did you test it ?
Just test_verifier and test_progs (the latter has a failure
"test_bpf_obj_id:FAIL:get-prog-info(fd) err 0 errno 2 i 0 type 1(1) info_len
80(40) jit_enabled 0 jited_prog_len 0 xlated_pr
> -Original Message-
> From: Leon Romanovsky
> Sent: Tuesday, April 3, 2018 2:29 AM
> To: Stephen Hemminger
> Cc: Leon Romanovsky ; netdev
> ; RDMA mailing list r...@vger.kernel.org>; David Ahern ; Steve Wise
>
> Subject: [PATCH iproute2 rdma: Ignore unknown netlink attributes
>
> Fr
On Tue, Apr 03, 2018 at 12:29:47PM +, haibinzhang(张海斌) wrote:
>
> >On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang wrote:
> >> handle_tx will delay rx for a long time when tx busy polling udp packets
> >> with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT
> >> ta
> On Mon, Apr 02, 2018 at 08:55:27PM -0700, Richard Cochran wrote:
> On Sun, Mar 25, 2018 at 04:01:49PM -0700, Florian Fainelli wrote:
> > The best that I can think about and it still is a hack in some way, is
> > to you have your time stamping driver create a proxy mii_bus whose
> > purpose is jus
On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote:
> On Fri, Mar 16, 2018 at 9:34 AM, Michael S. Tsirkin wrote:
> > On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote:
> >> From: Alexander Duyck
> >>
> >> Hardware-realized virtio_pci devices can implement SR-IOV, so thi
On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
1 - 100 of 166 matches
Mail list logo
