This patch:
1. Prevent next_skb from coalescing to the prev_skb if
TCP_SKB_CB(prev_skb)->eor is set
2. Update the TCP_SKB_CB(prev_skb)->eor if coalescing is
allowed
Signed-off-by: Martin KaFai Lau
Cc: Eric Dumazet
Cc: Neal Cardwell
Cc: Soheil Hassas Yeganeh
Cc: Willem de Bruijn
Cc: Yuch
v3:
~ Separate EOR marking from the SKBTX_ANY_TSTAMP logic.
~ Move the eor bit test back to the loop in tcp_sendmsg and
tcp_sendpage because there could be >1 threads doing
sendmsg.
~ Thanks to Eric Dumazet's suggestions on v2.
~ The TCP timestamp bug fixes are separated into other threads.
v2
When fragmenting a skb, the next_skb should carry
the eor from prev_skb. The eor of prev_skb should
also be reset.
Signed-off-by: Martin KaFai Lau
Cc: Eric Dumazet
Cc: Neal Cardwell
Cc: Soheil Hassas Yeganeh
Cc: Willem de Bruijn
Cc: Yuchung Cheng
---
net/ipv4/tcp_output.c | 9 +
1
This patch adds an eor bit to the TCP_SKB_CB. When MSG_EOR
is passed to tcp_sendmsg/tcp_sendpage, the eor bit will
be set at the skb containing the last byte of the userland's
msg. The eor bit will prevent data from appending to that
skb in the future.
This patch handles the tcp_sendmsg and tcp_
On Tue, 2016-04-19 at 19:17 -0700, K. Y. Srinivasan wrote:
> On Hyper-V, the VF/PF communication is a via software mediated path
> as opposed to the hardware mailbox. Make the necessary
> adjustments to support Hyper-V.
>
> Signed-off-by: K. Y. Srinivasan
> ---
> V2: Addressed most of the
When a tcp skb is sliced into two smaller skbs (e.g. in
tcp_fragment() and tso_fragment()), it does not carry
the txstamp_ack bit to the newly created skb if it is needed.
The end result is a timestamping event (SCM_TSTAMP_ACK) will
be missing from the sk->sk_error_queue.
This patch carries this
When collapsing skbs, txstamp_ack also needs to be merged.
Retrans Collapse Test:
~~
0.200 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
0.200 write(4, ..., 730) = 730
+0 setsockopt(4, SOL_SOCKET, 37, [2688], 4) = 0
0.200 write(4, ..., 730) = 730
+0 setsockopt(4,
This patchset is to handle the txstamp-ack bit when
fragmenting/coalescing skbs.
The second patch depends on the recently posted series
for the net branch:
"tcp: Merge timestamp info when coalescing skbs"
A BPF prog is used to kprobe to sock_queue_err_skb()
and print out the value of serr->ee.ee_
If two skbs are merged/collapsed during retransmission, the current
logic does not merge the tx_flags and tskey. The end result is
the SCM_TSTAMP_ACK timestamp could be missing for a packet.
The patch:
1. Merge the tx_flags
2. Overwrite the prev_skb's tskey with the next_skb's tskey
BPF Output B
This series is separated from the RFC series related to
tcp_sendmsg(MSG_EOR) and it is targeting for the net branch.
This patchset is focusing on fixing cases where TCP
timestamp could be lost after coalescing skbs.
A BPF prog is used to kprobe to sock_queue_err_skb()
and print out the value of se
After receiving sacks, tcp_shifted_skb() will collapse
skbs if possible. tx_flags and tskey also have to be
merged.
This patch reuses the tcp_skb_collapse_tstamp() to handle
them.
BPF Output Before:
~
BPF Output After:
~
<...>-2024 [007] d.s.88.644374: : ee_data:14599
Packetdrill
> >> The third option I see is to completely ditch this, stating that
> >> although We obviously CAN set the non-volatile memory we CAN'T do it
> >> with the regular API, and to move into doing this via some
> >> proprietary API such as debugfs.
>
> > Why go to debugfs rather than gracefully exten
On 20/04/2016 12:22AM, Christophe Leroy wrote
> -Original Message-
> From: Christophe Leroy [mailto:christophe.le...@c-s.fr]
> Sent: Wednesday, April 20, 2016 12:22 AM
> To: Qiang Zhao ; da...@davemloft.net
> Cc: gre...@linuxfoundation.org; Xiaobo Xie ; linux-
> ker...@vger.kernel.org; o..
On 4/19/16, 4:50 PM, David Miller wrote:
> From: Nicolas Dichtel
> Date: Tue, 19 Apr 2016 21:08:21 +0200
>
>> Le 19/04/2016 20:47, Eric Dumazet a écrit :
>>> Since we want to use this in other places, we could define a helper.
>>>
>>> nla_align_64bit(skb, attribute) or something.
>> Yes, with the
On 4/19/16, 3:49 PM, David Miller wrote:
> From: Roopa Prabhu
> Date: Tue, 19 Apr 2016 12:05:00 -0700
>
>> ok, will do. one thing though, for GETSTATS, if I need a pad
>> attribute like IFLA_PAD, I will need to add a new stats attribute
>> IFLA_STATS_PAD and burn a bit for it in filter_mask too.
From: Marco Angaroni
When using OPS mode in conjunction with SIP persistent-engine, packets
originating from the same ip-address/port could be balanced to different
real servers, and (to properly handle SIP responses) OPS connections
are created in the in-out direction too, where ip_vs_update_con
From: Marco Angaroni
One-packet-scheduling is the most expensive mode in IPVS from
performance point of view: for each packet to be processed a new
connection data structure is created and, after packet is sent,
deleted by starting a new timer set to expire immediately.
SIP persistent-engine nee
From: Marco Angaroni
When using LVS-NAT and SIP persistence-egine over UDP, the following
limitations are present with current implementation:
1) To actually have load-balancing based on Call-ID header, you need to
use one-packet-scheduling mode. But with one-packet-scheduling the
co
Hi Pablo,
please consider these enhancements to the IPVS. They allow SIP connections
originating from real-servers to be load balanced by the SIP psersitence
engine as is already implemented in the other direction. And for better one
packet scheduling (OPS) performance.
The following changes sinc
formed by the stmmac core.
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187
> __of_reset_control_get+0x218/0x270
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
>
On 4/19/16 1:41 PM, Johannes Berg wrote:
On Tue, 2016-04-19 at 14:23 -0400, David Miller wrote:
I like this nlattr flag idea, it's opt-in and any tool can be updated
to use the new facility.
Right.
I'd be willing the backport the nlattr flag bit change to all stable
releases as well.
I'm
On 20.04.2016 03:11, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Wed, 20 Apr 2016 03:06:13 +0200
>
>> On Wed, Apr 20, 2016, at 02:27, David Miller wrote:
>>> From: Hannes Frederic Sowa
>>> Date: Mon, 18 Apr 2016 21:19:41 +0200
>>>
This patchset removes the dependency of network
On Mon, Apr 18, 2016 at 2:33 PM, Eric W. Biederman
wrote:
>
> But please see if you can get macvlan_init to do the necessary work.
> That should simplify everything, and make clever games unnecessary.
Using macvlan_init seems to work. I will test it a couple of days and
then resubmit.
Thanks,
Fr
From: Hannes Frederic Sowa
Date: Wed, 20 Apr 2016 03:06:13 +0200
> On Wed, Apr 20, 2016, at 02:27, David Miller wrote:
>> From: Hannes Frederic Sowa
>> Date: Mon, 18 Apr 2016 21:19:41 +0200
>>
>> > This patchset removes the dependency of network drivers on vxlan or
>> > geneve, so those don't g
From: Eric Dumazet
Date: Tue, 19 Apr 2016 17:49:50 -0700
> On Tue, 2016-04-19 at 20:36 -0400, David Miller wrote:
>> From: Eric Dumazet
>> Date: Mon, 18 Apr 2016 13:56:12 -0700
>>
>> > 1 % packet losses are common today, and at 100Gbit speeds, this
>> > translates to ~80,000 losses per second.
On Wed, Apr 20, 2016, at 02:27, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Mon, 18 Apr 2016 21:19:41 +0200
>
> > This patchset removes the dependency of network drivers on vxlan or
> > geneve, so those don't get autoloaded when the nic driver is loaded.
> >
> > Also audited the cod
On Tue, 2016-04-19 at 20:36 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 18 Apr 2016 13:56:12 -0700
>
> > 1 % packet losses are common today, and at 100Gbit speeds, this
> > translates to ~80,000 losses per second. If we are unlucky and
> > first MSS of a 45-MSS TSO is lost, we ar
From: Jorgen Hansen
Date: Mon, 18 Apr 2016 23:58:52 -0700
> If skb_recv_datagram returns an skb, we should ignore the err
> value returned. Otherwise, datagram receives will return EAGAIN
> when they have to wait for a datagram.
>
> Acked-by: Adit Ranadive
> Signed-off-by: Jorgen Hansen
Appli
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
V2: Addressed most of the comments from
Alexander Duyck
and Rustad, Mark
Intel SR-IOV cards present different ID when running on Hyper-V.
Add the device IDs presented while running on Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
V5: No change from V1
drivers/net/ethernet/intel/ixgbevf/defines.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
Make adjustments to the Intel 10G VF driver to support
running on Hyper-V hosts.
K. Y. Srinivasan (2):
ethernet: intel: Add the device ID's presented while running on
Hyper-V
intel: ixgbevf: Support Windows hosts (Hyper-V)
drivers/net/ethernet/intel/ixgbevf/defines.h |5 +
drive
From: Eric Dumazet
Date: Mon, 18 Apr 2016 13:56:12 -0700
> 1 % packet losses are common today, and at 100Gbit speeds, this
> translates to ~80,000 losses per second. If we are unlucky and
> first MSS of a 45-MSS TSO is lost, we are cooking 44 MSS segments
> at rtx instead of a single 44-MSS TSO p
From: Vivien Didelot
Date: Mon, 18 Apr 2016 16:10:24 -0400
> The dsa_slave_priv structure does not need a pointer to its net_device.
> Kill it.
>
> Signed-off-by: Vivien Didelot
Applied.
From: Hannes Frederic Sowa
Date: Mon, 18 Apr 2016 21:19:41 +0200
> This patchset removes the dependency of network drivers on vxlan or
> geneve, so those don't get autoloaded when the nic driver is loaded.
>
> Also audited the code such that vxlan_get_rx_port and geneve_get_rx_port
> are not cal
From: Daniel Borkmann
Date: Mon, 18 Apr 2016 21:01:22 +0200
> This minor set adds a new helper bpf_event_output() for eBPF cls/act
> program types which allows to pass events to user space applications.
> For details, please see individual patches.
...
> v1 -> v2:
> - Address kbuild bot found
From: Manish Chopra
Date: Mon, 18 Apr 2016 13:06:04 -0400
> Please note that I have intentionally targeted this for "net-next"
> to avoid merge conflicts when net-next changes gets merged to net
>
> Please consider applying this series to "net-next"
I do not understand what you are saying here.
From: Julia Lawall
Date: Mon, 18 Apr 2016 16:55:35 +0200
> Add __init attribute on a function that is only called from other __init
> functions and that is not inlined, at least with gcc version 4.8.4 on an
> x86 machine with allyesconfig. Currently, the function is put in the
> .text.unlikely s
From: Andrew Goodbody
Date: Mon, 18 Apr 2016 14:53:25 +0100
> This is a fix for a NULL pointer dereference from cpsw which is triggered
> by having two slave PHYs attached to a cpsw network device. The problem is
> due to only maintaining a single reference to a PHY node in the prive data
> which
From: Konstantin Khlebnikov
Date: Mon, 18 Apr 2016 14:41:10 +0300
> Struct ctl_table_header holds pointer to sysctl table which could be used
> for freeing it after unregistration. IPv4 sysctls already use that.
> Remove redundant NULL assignment: ndev allocated using kzalloc.
>
> This also save
From: Konstantin Khlebnikov
Date: Mon, 18 Apr 2016 14:41:17 +0300
> Separated from previous patch for readability.
>
> Signed-off-by: Konstantin Khlebnikov
Applied.
From: Konstantin Khlebnikov
Date: Mon, 18 Apr 2016 14:37:10 +0300
> skb->sk could point to timewait or request socket which has no sk_classid.
> Detected as "BUG: KASAN: slab-out-of-bounds in cls_cgroup_classify".
>
> Signed-off-by: Konstantin Khlebnikov
Applied, thank you.
From: Konstantin Khlebnikov
Date: Mon, 18 Apr 2016 14:33:54 +0300
> High order pages are optional here since commit 51151a16a60f ("mlx4: allow
> order-0 memory allocations in RX path"), so here is no reason for depleting
> reserves. Generic __netdev_alloc_frag() implements the same logic.
>
> Si
From: Konstantin Khlebnikov
Date: Mon, 18 Apr 2016 14:34:05 +0300
> This patch fixes couple error paths after allocation failures.
> Atomic set of page reference counter is safe only if it is zero,
> otherwise set can race with any speculative get_page_unless_zero.
>
> Signed-off-by: Konstantin
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
Hardware name: Altera SOCFPGA
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x94/0xa8)
[] (dump_stack) from [] (__warn+0xec/0x104)
[] (__warn) f
formed by the stmmac core.
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187
> __of_reset_control_get+0x218/0x270
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
>
From: Tom Herbert
Date: Fri, 15 Apr 2016 13:34:10 -0700
> + if (!ila_is_ila_addr(iaddr)) {
This doesn't compile.
From: Nicolas Dichtel
Date: Tue, 19 Apr 2016 21:08:21 +0200
> Le 19/04/2016 20:47, Eric Dumazet a écrit :
>> Since we want to use this in other places, we could define a helper.
>>
>> nla_align_64bit(skb, attribute) or something.
> Yes, with the corresponding nla_total_size_64bit()
Good, idea,
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
Hardware name: Altera SOCFPGA
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x94/0xa8)
[] (dump_stack) from [] (__warn+0xec/0x104)
[] (__warn) f
On Tue, 19 Apr 2016 18:43:39 -0400 (EDT)
David Miller wrote:
> From: Grygorii Strashko
> Date: Tue, 19 Apr 2016 21:44:09 +0300
>
> > May be you can send revert + your patch 1 (only fix for this issue).
> >
> > Dave, Does that sound good to you?
>
> Sure.
OK, I will hopefully have that read
From: Roopa Prabhu
Date: Tue, 19 Apr 2016 12:05:00 -0700
> ok, will do. one thing though, for GETSTATS, if I need a pad
> attribute like IFLA_PAD, I will need to add a new stats attribute
> IFLA_STATS_PAD and burn a bit for it in filter_mask too. In which
> case, I am wondering if we should live
From: Grygorii Strashko
Date: Tue, 19 Apr 2016 21:44:09 +0300
> May be you can send revert + your patch 1 (only fix for this issue).
>
> Dave, Does that sound good to you?
Sure.
On Tue, 2016-04-19 at 14:34 +0200, Denys Vlasenko wrote:
> "incvalue" variable holds a result of "er32(TIMINCA) &
> E1000_TIMINCA_INCVALUE_MASK"
> and used in "do_div(temp, incvalue)" as a divisor.
>
> Thus, "u64 incvalue" declaration is probably a mistake.
> Even though it seems to be a harmless
On 4/19/16, 12:55 PM, Paul Moore wrote:
> On Tue, Apr 19, 2016 at 4:26 AM, Nicolas Dichtel
> wrote:
>> + selinux maintainers
>>
>> Le 18/04/2016 23:10, Roopa Prabhu a écrit :
>> [snip]
>>> diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
>>> index 8495b93..1714633 100644
>>>
2016-04-19, 13:45:47 -0400, Lance Richardson wrote:
> - Original Message -
> > From: "Sabrina Dubroca"
> > To: netdev@vger.kernel.org
> > Cc: "Hannes Frederic Sowa" , "Johannes Berg"
> > , "Dan Carpenter"
> > , "Sabrina Dubroca"
> > Sent: Tuesday, April 19, 2016 1:36:38 PM
> > Subject: [
Is there a way to disable the lldp daemon running in the firmware?
On Tue, Apr 19, 2016 at 2:31 PM, Parikh, Neerav wrote:
>
>
>> -Original Message-
>> From: Jeremy Ashton [mailto:jeremy.ash...@shopify.com]
>> Sent: Tuesday, April 19, 2016 11:10 AM
>> To: Parikh, Neerav
>> Cc: netdev@vger
Hi,
after upgrading our firewall from 4.1.17 to 4.4.0, we've noticed quite a
performance
drop.. Slight network load seems to cause high CPU load..
running perf of almost idle system shows:
samples pcnt functionDSO
___ _
On Tue, Apr 19, 2016 at 4:26 AM, Nicolas Dichtel
wrote:
> + selinux maintainers
>
> Le 18/04/2016 23:10, Roopa Prabhu a écrit :
> [snip]
>>
>> diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
>> index 8495b93..1714633 100644
>> --- a/security/selinux/nlmsgtab.c
>> +++ b/secur
On Tue, 2016-04-19 at 14:23 -0400, David Miller wrote:
>
> I like this nlattr flag idea, it's opt-in and any tool can be updated
> to use the new facility.
Right.
> I'd be willing the backport the nlattr flag bit change to all stable
> releases as well.
I'm not really convinced that helps much
On Tue, Apr 19, 2016 at 1:12 PM, K. Y. Srinivasan wrote:
> On Hyper-V, the VF/PF communication is a via software mediated path
> as opposed to the hardware mailbox. Make the necessary
> adjustments to support Hyper-V.
>
> Signed-off-by: K. Y. Srinivasan
> ---
> V2: Addressed most of the c
On Tue, 19 Apr 2016 14:33:02 +0100
Edward Cree wrote:
> Earlier discussions on this list[1] suggested that having multiple packets
> traverse the network stack together (rather than calling the stack for each
> packet singly) could improve performance through better cache locality.
> This patch s
Le 19/04/2016 20:47, Eric Dumazet a écrit :
On Tue, 2016-04-19 at 14:31 -0400, David Miller wrote:
+#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
+ /* IF necessary, add a zero length NOP attribute so that the
+* nla_data() of the IFLA_STATS64 will be 64-bit aligned.
+*
+
This patch assumes that the fm10k hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP headers.
I have no means of testing this as I do not have any mlx5 hardware but
thought I would submit it as an RFC to see if anyone
This patch set is meant to extend tunnel offload support for devices that
already support UDP or GRE tunnels to include support for those type of
tunnels with an outer checksum. To do this I am enabling GSO partial
support for these types of tunnels which should work assuming the devices
supported
This patch assumes that the mlx4 hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP headers.
I have no means of testing this as I do not have any mlx4 hardware but
thought I would submit it as an RFC to see if anyone
This patch assumes that the bnxt hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP and GRE headers.
I have no means of testing this as I do not have any bnx2x hardware but
thought I would submit it as an RFC to see i
This patch assumes that the mlx5 hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP headers.
I have no means of testing this as I do not have any mlx5 hardware but
thought I would submit it as an RFC to see if anyone
This patch assumes that the bnx2x hardware will ignore existing IPv4/v6
header fields for length and checksum as well as the length and checksum
fields for outer UDP and GRE headers.
I have no means of testing this as I do not have any bnx2x hardware but
thought I would submit it as an RFC to see
On 4/19/16, 11:31 AM, David Miller wrote:
[snip]
>
> Here is the final patch I'm about to push out, thanks a lot Eric.
>
> Roopa, please adjust your GETSTATS patch as needed (I think you need
> to adjust the SELinux table entry as well) and we can integrate that
> too.
ok, will do. one thing thoug
On Tue, 2016-04-19 at 14:31 -0400, David Miller wrote:
> +#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
> + /* IF necessary, add a zero length NOP attribute so that the
> + * nla_data() of the IFLA_STATS64 will be 64-bit aligned.
> + *
> + * The nlattr header is 4 bytes in size, that'
On Tue, Apr 19, 2016 at 06:04:49PM +, Reizer, Eyal wrote:
> Thanks! Glad the illustration helped.
> I will try it out again as if i recall cotrectly, i did try that l, and it
> didnt produce the correct waveform, but perhaps i didnt understand the usage
> of .cs_change correctly.
> Will doub
On Tue, 2016-04-19 at 14:31 -0400, David Miller wrote:
>
> Here is the final patch I'm about to push out, thanks a lot Eric.
>
> Roopa, please adjust your GETSTATS patch as needed (I think you need
> to adjust the SELinux table entry as well) and we can integrate that
> too.
>
> ===
On 04/19/2016 08:14 PM, David Rivshin (Allworx) wrote:
On Tue, 19 Apr 2016 18:44:41 +0300
Grygorii Strashko wrote:
On 04/19/2016 06:01 PM, David Rivshin (Allworx) wrote:
On Tue, 19 Apr 2016 17:41:07 +0300
Grygorii Strashko wrote:
Hi,
On 04/19/2016 04:56 PM, Andrew Goodbody wrote:
Adding
On Tue, Apr 19, 2016 at 10:12 AM, Edward Cree wrote:
> On 19/04/16 16:46, Tom Herbert wrote:
>> On Tue, Apr 19, 2016 at 7:50 AM, Eric Dumazet wrote:
>>> We have hard time to deal with latencies already, and maintaining some
>>> sanity in the stack(s)
>> Right, this is significant complexity for a
On 4/19/2016 2:22 PM, Christoph Hellwig wrote:
> What I think we need is something like the patch below. In the long
> ru nwe should also kill the mlx4_buf structure which now is pretty
> pointless.
Maybe; this could be the correct approach if we can guarantee that the
architecture can allocate
Intel SR-IOV cards present different ID when running on Hyper-V.
Add the device IDs presented while running on Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
V4: No change from V1
drivers/net/ethernet/intel/ixgbevf/defines.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
V2: Addressed most of the comments from
Alexander Duyck
and Rustad, Mark
Make adjustments to the Intel 10G VF driver to support
running on Hyper-V hosts.
K. Y. Srinivasan (2):
ethernet: intel: Add the device ID's presented while running on
Hyper-V
intel: ixgbevf: Support Windows hosts (Hyper-V)
drivers/net/ethernet/intel/ixgbevf/defines.h |5 +
drive
> -Original Message-
> From: Jeremy Ashton [mailto:jeremy.ash...@shopify.com]
> Sent: Tuesday, April 19, 2016 11:10 AM
> To: Parikh, Neerav
> Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] i40e error handling LLDP messages from Arista
> swit
From: David Miller
Date: Tue, 19 Apr 2016 01:03:16 -0400 (EDT)
> From: Eric Dumazet
> Date: Mon, 18 Apr 2016 21:32:04 -0700
>
>> On Mon, 2016-04-18 at 23:41 -0400, David Miller wrote:
>>>
>>> + /* Add a zero length NOP attribute so that the nla_data()
>>> +* of the IFLA_STATS64 will be
On Tue, Apr 19, 2016 at 7:25 PM, Jesper Dangaard Brouer
wrote:
> On Mon, 18 Apr 2016 07:17:13 -0700
> Eric Dumazet wrote:
>
>> Another idea would be to have a way to control max number of order-5
>> pages that a port would be using.
>>
>> Since driver always own a ref on a order-5 pages, idea wou
On Tue, Apr 19, 2016 at 2:18 PM, Martin KaFai Lau wrote:
> On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
>> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau wrote:
>>
>> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
>> > of redundant but I have not
Kalle Valo writes:
> Jes Sorensen writes:
>
>> Arnd Bergmann writes:
>>> The references to some arrays in the rtl8xxxu driver were moved inside
>>> of an #ifdef, but the symbols remain outside, resulting in build warnings:
>>>
>>> rtl8xxxu/rtl8xxxu.c:1506:33: error:
>>> 'rtl8188ru_radioa_1t_high
From: Johannes Berg
Date: Tue, 19 Apr 2016 12:09:03 +0200
> At netconf, we talked about how awkward it can be that one doesn't know
> if an attribute was accepted by the kernel or simply ignored because
> it's not supported (older kernel version).
>
> I considered (and Emmanuel has started to co
What I think we need is something like the patch below. In the long
ru nwe should also kill the mlx4_buf structure which now is pretty
pointless.
---
>From a493881d2a6c90152d3daabb7b6b3afd1d254d78 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 19 Apr 2016 14:12:14 -0400
Subject: mlx
On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau wrote:
>
> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
> > of redundant but I have not look into the details yet, so not completely
> > sure. It wwou
So, what commands exactly are you looking to have run? Would packet
capture of the lldp traffic help?
On Tue, Apr 19, 2016 at 1:53 PM, Parikh, Neerav wrote:
> Resending as the original email was sent in HTLM format and hence my reply
> went in that format
> as well; which got rejected by netdev
The cpsw_ndo_open() could try to access CPSW registers before
calling pm_runtime_get_sync(). This will trigger L3 error:
WARNING: CPU: 0 PID: 21 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x220/0x34c()
4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_FAST (Idle): Data
Acce
On Tue, 2016-04-19 at 17:50 +0100, Edward Cree wrote:
> On 19/04/16 15:50, Eric Dumazet wrote:
> > The main problem in UDP stack today is having to lock the socket because
> > of the dumb forward allocation problem.
> I'm not quite sure what you're referring to here, care to educate me?
This was
This patch adds support for the checksum enabled versions of UDP and GRE
tunnels. With this change we should be able to send and receive GSO frames
of these types over the veth pair without needing to segment the packets.
Signed-off-by: Alexander Duyck
---
drivers/net/veth.c |7 +++
1 f
This patch folds NETIF_F_ALL_TSO into the bitmask for NETIF_F_GSO_SOFTWARE.
The idea is to avoid duplication of defines since the only difference
between the two was the GSO_UDP bit.
Signed-off-by: Alexander Duyck
---
include/linux/netdev_features.h |8 +++-
1 file changed, 3 insertions(
On Tue, 2016-04-19 at 18:42 +0100, Edward Cree wrote:
> Well, I don't know how to achieve that, but it sounds like you do, so why
> not go ahead and show us ;)
> If you submitted a patch series to make UDP twice as fast, I think people
> would "really care" about an improvement of that magnitude.
On Tue, Apr 19, 2016 at 7:30 AM, Dan Carpenter wrote:
> We intended to test "err" and not "skb".
>
> Fixes: aed069df099c ('ip_tunnel_core: iptunnel_handle_offloads returns int
> and doesn't free skb')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> i
On Tue, Apr 19, 2016 at 05:38:02PM +, Reizer, Eyal wrote:
> Hi Mark,
>
> Hope you can see the attached picture that illustrates what need to sent for
> sucesfull SPI init.
I think what the picture shows is that you just need to send at least
one byte at the end of the transfer *after* deasse
On Tue, 2016-04-19 at 18:12 +0100, Edward Cree wrote:
> I think if we pushed bundled RX all the way up to the TCP layer, it might
> potentially also be faster than GRO, because it avoids the work of
> coalescing superframes; plus going through the GRO callbacks for each
> packet could end up blowi
Resending as the original email was sent in HTLM format and hence my reply went
in that format
as well; which got rejected by netdev mailer.
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Parikh, Neerav
> Sent: Tuesday, April
On 19/04/16 10:14, David Rivshin (Allworx) wrote:
>> Ah Ok. There are no user of cpsw_platform_data outside of net/ethernet/ti/,
>> so yes, looks like your patch 1 does exactly what's needed.
>
> Given that the v1 of Andrew's patch is already in Dave's net tree, and
> would obviously have many co
- Original Message -
> From: "Sabrina Dubroca"
> To: netdev@vger.kernel.org
> Cc: "Hannes Frederic Sowa" , "Johannes Berg"
> , "Dan Carpenter"
> , "Sabrina Dubroca"
> Sent: Tuesday, April 19, 2016 1:36:38 PM
> Subject: [PATCH net 1/5] macsec: add missing NULL check after kmalloc
>
> Fix
On Tue, Apr 19, 2016 at 1:39 PM, Martin KaFai Lau wrote:
> On Tue, Apr 19, 2016 at 01:21:04AM -0400, Soheil Hassas Yeganeh wrote:
>> Could you please submit the timestamping patches separately as non RFCs?
>> Thanks!
> Agree. I will re-spin.
Great, thank you very much!
On Tue, Apr 19, 2016 at 1:28 PM, Martin KaFai Lau wrote:
> On Tue, Apr 19, 2016 at 01:32:14AM -0400, Soheil Hassas Yeganeh wrote:
>> > + TCP_SKB_CB(skb)->txstamp_ack =
>> > + !!(shinfo->tx_flags & SKBTX_ACK_TSTAMP);
>>
>> Maybe we can skip a conditional jump her
On Tue, Apr 19, 2016 at 01:21:04AM -0400, Soheil Hassas Yeganeh wrote:
> Could you please submit the timestamping patches separately as non RFCs?
> Thanks!
Agree. I will re-spin.
1 - 100 of 208 matches
Mail list logo
