Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform

Hi Gregory, On Wed, 30 Mar 2016 17:11:41 +0200 Gregory CLEMENT wrote: > Hi Jisheng, > > On mer., mars 30 2016, Jisheng Zhang wrote: > > > The mvneta BM can't work on 64bit platform, as the BM hardware expects > > buf virtual address to be placed in the first four bytes

[PATCH net-next 3/6] macvtap: socket rx busy polling support

Signed-off-by: Jason Wang --- drivers/net/macvtap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 95394ed..1891aff 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -20,6 +20,7 @@ #include

[PATCH net-next 0/6] net device rx busy polling support in vhost_net

Hi all: This series try to add net device rx busy polling support in vhost_net. This is done through: - adding socket rx busy polling support for tun/macvtap by marking napi_id. - vhost_net will try to find the net device through napi_id and do busy polling if possible. TCP_RR tests on two

[PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu

We use a union for napi_id and send_cpu, this is ok for most of the cases except when we want to support busy polling for tun which needs napi_id to be stored and passed to socket during tun_net_xmit(). In this case, napi_id was overridden with sender_cpu before tun_net_xmit() was called if XPS

[PATCH net-next 2/6] tuntap: socket rx busy polling support

Signed-off-by: Jason Wang --- drivers/net/tun.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index afdf950..950faf5 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -69,6 +69,7 @@ #include #include

[PATCH net-next 4/6] net: core: factor out core busy polling logic to sk_busy_loop_once()

This patch factors out core logic of busy polling to sk_busy_loop_once() in order to be reused by other modules. Signed-off-by: Jason Wang --- include/net/busy_poll.h | 7 ++ net/core/dev.c | 59 - 2 files

[PATCH net-next 5/6] net: export napi_by_id()

This patch exports napi_by_id() which will be used by vhost_net socket busy polling. Signed-off-by: Jason Wang --- include/net/busy_poll.h | 1 + net/core/dev.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/net/busy_poll.h

[PATCH net-next 6/6] vhost_net: net device rx busy polling support

This patch let vhost_net try rx busy polling of underlying net device when busy polling is enabled. Test shows some improvement on TCP_RR: smp=1 queue=1 size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ 1/ 1/ +4%/ +3%/ +3%/ +3%/ +22% 1/50/ +2%/ +2%/ +2%/

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On Thu, Mar 31, 2016 at 07:22:32AM +0200, Michal Kubecek wrote: > On Wed, Mar 30, 2016 at 10:08:10PM -0700, Alexei Starovoitov wrote: > > On Thu, Mar 31, 2016 at 07:01:15AM +0200, Michal Kubecek wrote: > > > On Wed, Mar 30, 2016 at 06:18:42PM -0700, Alexei Starovoitov wrote: > > > > > > > > kinda

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On Wed, Mar 30, 2016 at 10:08:10PM -0700, Alexei Starovoitov wrote: > On Thu, Mar 31, 2016 at 07:01:15AM +0200, Michal Kubecek wrote: > > On Wed, Mar 30, 2016 at 06:18:42PM -0700, Alexei Starovoitov wrote: > > > > > > kinda heavy patch to shut up lockdep. > > > Can we do > > > old_fp =

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On Thu, Mar 31, 2016 at 07:01:15AM +0200, Michal Kubecek wrote: > On Wed, Mar 30, 2016 at 06:18:42PM -0700, Alexei Starovoitov wrote: > > On Thu, Mar 31, 2016 at 02:13:18AM +0200, Daniel Borkmann wrote: > > > Sasha Levin reported a suspicious rcu_dereference_protected() warning > > > found while

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On Wed, Mar 30, 2016 at 06:18:42PM -0700, Alexei Starovoitov wrote: > On Thu, Mar 31, 2016 at 02:13:18AM +0200, Daniel Borkmann wrote: > > Sasha Levin reported a suspicious rcu_dereference_protected() warning > > found while fuzzing with trinity that is similar to this one: > > > > [

Re: [PATCH net-next 0/8] add TX timestamping via cmsg

>> Nice patches! This does not yet solve the append issue that your MSG_EOR patch addresses, of course. The straightforward jump to new_segment that I proposed as simplification is more properly a "start-of-record" than "end-of-record" signal. It is probably preferable to indeed be able to pass

Re: [PATCH net-next 8/8] sock: document timestamping via cmsg in Documentation

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > Update docs and add code snippet for using cmsg for timestamping. > > Signed-off-by: Soheil Hassas Yeganeh Acked-by: Willem de Bruijn

Re: [PATCH net-next 7/8] sock: enable timestamping using control messages

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > Currently, SOL_TIMESTAMPING can only be enabled using setsockopt. > This is very costly when users want to sample writes to gather > tx timestamps. > > Add

Re: [PATCH net-next 6/8] ipv6: process socket-level control messages in IPv6

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > Process socket-level control messages by invoking > __sock_cmsg_send in ip6_datagram_send_ctl for control messages on > the SOL_SOCKET layer. > > This makes

Re: [PATCH net-next 5/8] ipv4: process socket-level control messages in IPv4

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > Process socket-level control messages by invoking > __sock_cmsg_send in ip_cmsg_send for control messages on > the SOL_SOCKET layer. > > This makes sure

Re: [PATCH net-next 4/8] sock: accept SO_TIMESTAMPING flags in socket cmsg

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > Accept SO_TIMESTAMPING in control messages of the SOL_SOCKET level > as a basis to accept timestamping requests per write. > > This implementation only

Re: [PATCH net-next 3/8] tcp: use one bit in TCP_SKB_CB to mark ACK timestamps

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > Currently, to avoid a cache line miss for accessing skb_shinfo, > tcp_ack_tstamp skips socket that do not have > SOF_TIMESTAMPING_TX_ACK bit set in

Re: [PATCH net-next 2/8] tcp: accept SOF_TIMESTAMPING_OPT_ID for passive TFO

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh wrote: > From: Soheil Hassas Yeganeh > > SOF_TIMESTAMPING_OPT_ID is set to get data-independent IDs > to associate timestamps with send calls. For TCP connections, > tp->snd_una is used as the

RE: [PATCH 4/5] fsl/qe: Add QE TDM lib

On Wed, 2016-03-30 at 07:50PM, Joakim Tjernlund wrote: > -Original Message- > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com] > Sent: Wednesday, March 30, 2016 7:50 PM > To: da...@davemloft.net; Qiang Zhao > Cc: linuxppc-...@lists.ozlabs.org;

Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages

Hi Andy, On 31/03/16 11:41, Fugang Duan wrote: > From: Fabio Estevam Sent: Thursday, March 31, 2016 2:37 > AM >> To: Greg Ungerer >> Cc: Troy Kisky ; netdev@vger.kernel.org >> Subject: Re: [PATCH] net: fec: stop the "rcv is

RE: [PATCH] net: fec: stop the "rcv is not +last, " error messages

From: Fabio Estevam Sent: Thursday, March 31, 2016 2:37 AM > To: Greg Ungerer > Cc: Troy Kisky ; netdev@vger.kernel.org > Subject: Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages > > Hi Greg, > > On Wed,

Re: [net-next] bond: output message before setting slave to inactive

> From: Zhang Shengju > Date: Tue, 29 Mar 2016 06:32:57 + > > > This patch moves output message before setting slave to inactive, this > > will print the correct status of slave device. > > > > Signed-off-by: Zhang Shengju

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On Thu, Mar 31, 2016 at 02:13:18AM +0200, Daniel Borkmann wrote: > Sasha Levin reported a suspicious rcu_dereference_protected() warning > found while fuzzing with trinity that is similar to this one: > > [ 52.765684] net/core/filter.c:2262 suspicious > rcu_dereference_protected() usage! >

Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages

Hi Fabio, On 31/03/16 04:37, Fabio Estevam wrote: > Hi Greg, > > On Wed, Mar 30, 2016 at 12:24 AM, Greg Ungerer wrote: >> Hi Troy, >> >> Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error >> messages') adds a write to a register that is not present in all >>

Re: [PATCH net-next 0/8] add TX timestamping via cmsg

On Wed, Mar 30, 2016 at 8:38 PM, Martin KaFai Lau wrote: > On Wed, Mar 30, 2016 at 06:37:20PM -0400, Soheil Hassas Yeganeh wrote: >> I will follow up with another patch to enable timestamping for >> active TFO (client-side TCP Fast Open) and also setting packet >> mark via cmsgs. >

Re: [PATCH net-next 0/8] add TX timestamping via cmsg

On Wed, Mar 30, 2016 at 06:37:20PM -0400, Soheil Hassas Yeganeh wrote: > I will follow up with another patch to enable timestamping for > active TFO (client-side TCP Fast Open) and also setting packet > mark via cmsgs. Can you share more details on what 'setting packet mark' does? Nice patches!

[PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

Sasha Levin reported a suspicious rcu_dereference_protected() warning found while fuzzing with trinity that is similar to this one: [ 52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage! [ 52.765688] other info that might help us debug this: [ 52.765695]

Re: [PATCH iproute2 v1 1/1] lib/utils: fix get_addr() and get_prefix() error messages

On Tue, 22 Mar 2016 13:02:02 + "Varlese, Marco" wrote: > An attempt to add invalid address to interface would print "???" string > instead of the address family name. > > For example: > $ ip address add 256.10.166.1/24 dev ens8 > Error: ??? prefix is expected rather

Re: [net PATCH v2] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

Yes, this fixes it for me too! Tested-by: Sowmini Varadhan

[net PATCH v2] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

This patch addresses a bug introduced based on my interpretation of the XL710 datasheet. Specifically section 8.4.1 states that "A single transmit packet may span up to 8 buffers (up to 8 data descriptors per packet including both the header and payload buffers)." It then later goes on to say

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, Mar 30, 2016 at 2:20 PM, Alexander Duyck wrote: > On Wed, Mar 30, 2016 at 12:41 PM, Jesse Brandeburg > wrote: >> On Wed, 30 Mar 2016 10:35:55 -0700 >> Alexander Duyck wrote: >> >>> On Wed, Mar 30, 2016 at

[net 04/11] ixgbe: Use udelay to avoid sleeping while atomic

From: Mark Rustad Use udelay instead of usleep_range because this can be called while a lock is held. Signed-off-by: Mark Rustad Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher ---

[net 06/11] ixgbevf: call ndo_stop() instead of dev_close() when running offline selftest

From: Stefan Assmann Calling dev_close() causes IFF_UP to be cleared which will remove the interfaces routes and some addresses. That's probably not what the user intended when running the offline selftest. Besides this does not happen if the interface is brought down before

[net 02/11] ixgbe: Store VXLAN port number in network order

From: Alexander Duyck The VXLAN port number should be stored in network order instead of in host order as it is accessed from the hot-path in ATR. This way we can avoid having to do any byte swaps in order to validate the port number. I moved the vxlan_port value into a

[net 05/11] ixgbe: call ndo_stop() instead of dev_close() when running offline selftest

From: Stefan Assmann Calling dev_close() causes IFF_UP to be cleared which will remove the interfaces routes and some addresses. That's probably not what the user intended when running the offline selftest. Besides this does not happen if the interface is brought down before

[net 03/11] ixgbe: Fix ATR so that it correctly handles IPv6 extension headers

From: Alexander Duyck The ATR code was assuming that it would be able to use tcp_hdr for every TCP frame that came through. However this isn't the case as it is possible for a frame to arrive that is TCP but sent through something like a raw socket. As a result the driver

[net 00/11][pull request] Intel Wired LAN Driver Updates 2016-03-29

This series contains fixes to ixgbe and ixgbevf. Tushar fixes an issue which was introduced with an earlier commit, where hardware register RAR0 default MAC address does not get set properly. Alex fixes two issues, first being the VXLAN port number should be stored in network order instead of in

[net 01/11] ixgbe: Fix for RAR0 not being set to default MAC addr

From: Tushar Dave commit c9f53e63c208 ("ixgbe: Refactor MAC address configuration code") introduced code that doesn't set HW register RAR0 to default mac address but FF:FF:FF:FF:FF:FF. Due to this, ixgbe HW discards all incoming packets that doesn't have destination mac

[net 07/11] ixgbevf: fix error code path when setting MAC address

From: Emil Tantilov Return error when a MAC address change is rejected by the PF. This will prevent the user from modifying the MAC address when that operation is not permitted. Signed-off-by: Emil Tantilov Tested-by: Andrew Bowers

[net 10/11] ixgbe: Fix cls_u32 offload support for fields with masks

From: Sridhar Samudrala Remove the incorrect check for mask in ixgbe_configure_clsu32 and drop the 'mask' field that is not required in struct ixgbe_mat_field Verified with the following filters: #tc qdisc add dev p4p1 ingress #tc filter add dev p4p1 parent :

[net 08/11] ixgbe: make __ixgbe_setup_tc static

From: Emil Tantilov This function is only used in ixgbe_main.c Resolves a "missing prototype" warning when building the driver with W=1 Reported-by: Phil Schmitt Signed-off-by: Emil Tantilov Acked-by: John

[net 09/11] ixgbe: fix error handling in TC cls_u32 offload routines

From: Sridhar Samudrala Check for handle ids when adding/deleting hash nodes OR adding/deleting filter entries and limit them to max number of links or header nodes supported(IXGBE_MAX_LINK_HANDLE). Start from bit 0 when setting hash table bit-map.(adapter->tables)

[net 11/11] ixgbe: Fix cls_u32 offload support for L4 ports

From: Sridhar Samudrala Fix support for 16 bit source/dest port matches in ixgbe model. u32 uses a single 32-bit key value for both source and destination ports starting at offset 0. So replace the 2 functions with a single function that takes this key value/mask to

[PATCH net-next 6/8] ipv6: process socket-level control messages in IPv6

From: Soheil Hassas Yeganeh Process socket-level control messages by invoking __sock_cmsg_send in ip6_datagram_send_ctl for control messages on the SOL_SOCKET layer. This makes sure whenever ip6_datagram_send_ctl is called for udp and raw, we also process socket-level control

[PATCH net-next 2/8] tcp: accept SOF_TIMESTAMPING_OPT_ID for passive TFO

From: Soheil Hassas Yeganeh SOF_TIMESTAMPING_OPT_ID is set to get data-independent IDs to associate timestamps with send calls. For TCP connections, tp->snd_una is used as the starting point to calculate relative IDs. This socket option will fail if set before the handshake

[PATCH net-next 3/8] tcp: use one bit in TCP_SKB_CB to mark ACK timestamps

From: Soheil Hassas Yeganeh Currently, to avoid a cache line miss for accessing skb_shinfo, tcp_ack_tstamp skips socket that do not have SOF_TIMESTAMPING_TX_ACK bit set in sk_tsflags. This is implemented based on an implicit assumption that the SOF_TIMESTAMPING_TX_ACK is set

[PATCH net-next 5/8] ipv4: process socket-level control messages in IPv4

From: Soheil Hassas Yeganeh Process socket-level control messages by invoking __sock_cmsg_send in ip_cmsg_send for control messages on the SOL_SOCKET layer. This makes sure whenever ip_cmsg_send is called in udp, icmp, and raw, we also process socket-level control messages.

[PATCH net-next 1/8] sock: break up sock_cmsg_snd into __sock_cmsg_snd and loop

From: Willem de Bruijn To process cmsg's of the SOL_SOCKET level in addition to cmsgs of another level, protocols can call sock_cmsg_send(). This causes a double walk on the cmsghdr list, one for SOL_SOCKET and one for the other level. Extract the inner demultiplex logic

[PATCH net-next 0/8] add TX timestamping via cmsg

From: Soheil Hassas Yeganeh This patch series aim at enabling TX timestamping via cmsg. Currently, to occasionally sample TX timestamping on a socket, applications need to call setsockopt twice: first for enabling timestamps and then for disabling them. This is an unnecessary

[PATCH net-next 7/8] sock: enable timestamping using control messages

From: Soheil Hassas Yeganeh Currently, SOL_TIMESTAMPING can only be enabled using setsockopt. This is very costly when users want to sample writes to gather tx timestamps. Add support for enabling SO_TIMESTAMPING via control messages by using tsflags added in `struct

[PATCH net-next 4/8] sock: accept SO_TIMESTAMPING flags in socket cmsg

From: Soheil Hassas Yeganeh Accept SO_TIMESTAMPING in control messages of the SOL_SOCKET level as a basis to accept timestamping requests per write. This implementation only accepts TX recording flags (i.e., SOF_TIMESTAMPING_TX_HARDWARE, SOF_TIMESTAMPING_TX_SOFTWARE,

[PATCH net-next 8/8] sock: document timestamping via cmsg in Documentation

From: Soheil Hassas Yeganeh Update docs and add code snippet for using cmsg for timestamping. Signed-off-by: Soheil Hassas Yeganeh --- Documentation/networking/timestamping.txt | 48 +-- 1 file changed, 45 insertions(+), 3

[PATCH v2 net-next] tcp: remove cwnd moderation after recovery

For non-SACK connections, cwnd is lowered to inflight plus 3 packets when the recovery ends. This is an optional feature in the NewReno RFC 2582 to reduce the potential burst when cwnd is "re-opened" after recovery and inflight is low. This feature is questionably effective because of PRR: when

Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style

On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote: > Joe Perches writes: > > Using the normal kernel logging mechanisms makes this code > > a bit more like other wireless drivers. > Personally I don't see the point but I don't have any strong opinions. A > bigger problem is

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, Mar 30, 2016 at 12:41 PM, Jesse Brandeburg wrote: > On Wed, 30 Mar 2016 10:35:55 -0700 > Alexander Duyck wrote: > >> On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan >> wrote: >> > On (03/30/16 10:12),

Re: possible bug in latest network tree

On Wed, 2016-03-30 at 21:05 +, Light, John J wrote: > David, > > I see a recent change in inet_connection_sock.c that uses > sysctl_tcp_synack_retries suspiciously. > > Previously, sysctl_tcp_synack_retries was a global variable, and now > it has been moved into the fragment (really

Re: [PATCHv2 net] team: team should sync the port's uc/mc addrs when add a port

From: Xin Long Date: Wed, 30 Mar 2016 10:58:39 +0800 > There is an issue when we use mavtap over team: > When we replug nic links from team0, the real nics's mc list will not > include the maddr for macvtap any more. then we can't receive pkts to > macvtap device, as they

RE: possible bug in latest network tree

David, I see a recent change in inet_connection_sock.c that uses sysctl_tcp_synack_retries suspiciously. Previously, sysctl_tcp_synack_retries was a global variable, and now it has been moved into the fragment (really netns_ipv4). In reqsk_timer_handler (inet_connection_sock.c) near line 563

Re: [RFC] Add netdev all_adj_list refcnt propagation to fix panic

From: Andrew Collins Date: Tue, 29 Mar 2016 11:25:03 -0600 This is an RFC patch to fix a relatively easily reproducible kernel panic related to the all_adj_list handling for netdevs in recent kernels. This is more to generate discussion than anything else. I don't

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On (03/30/16 13:15), Eric Dumazet wrote: > You might try netperf -t TCP_SENDFILE -- -m 150 > > to let netperf use sendfile() on small frags. that still did not reproduce it but let me try beating on that approach with more permutations. BTW, another data-point that may help debug this: even

Re: [PATCH] sctp: flush if we can't fit another DATA chunk

On Wed, Mar 30, 2016 at 03:46:22PM -0400, David Miller wrote: > From: Marcelo Ricardo Leitner > Date: Tue, 29 Mar 2016 10:41:25 -0300 > > > There is no point in delaying the packet if we can't fit a single byte > > of data on it anymore. So lets just reduce the

Re: [PATCH net-next] tcp: remove cwnd moderation after recovery

On Tue, Mar 29, 2016 at 5:35 PM, Stephen Hemminger wrote: > On Tue, 29 Mar 2016 17:15:52 -0700 > Yuchung Cheng wrote: > >> For non-SACK connections, cwnd is lowered to inflight plus 3 packets >> when the recovery ends. This is an optional feature in

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, 2016-03-30 at 16:09 -0400, Sowmini Varadhan wrote: > On (03/30/16 12:41), Jesse Brandeburg wrote: > > This gets "Even Uglier", I've turned off all offloads at my receiver, > > enabled calling skb_linearize on *all* frames, which works fine for > > scp, but the receiver shows > MSS sized

Re: [RFC] Add netdev all_adj_list refcnt propagation to fix panic

From: David Miller Date: Wed, 30 Mar 2016 16:01:50 -0400 (EDT) > Veaceslav, please look into this. Of course, his email now bounces :-/

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On (03/30/16 12:41), Jesse Brandeburg wrote: > This gets "Even Uglier", I've turned off all offloads at my receiver, > enabled calling skb_linearize on *all* frames, which works fine for > scp, but the receiver shows > MSS sized frames on the wire for > rds-stress traffic. fwiw, I was not able to

Re: [net PATCH v2] gro: Allow tunnel stacking in the case of FOU/GUE

From: Alexander Duyck Date: Tue, 29 Mar 2016 14:55:22 -0700 > This patch should fix the issues seen with a recent fix to prevent > tunnel-in-tunnel frames from being generated with GRO. The fix itself is > correct for now as long as we do not add any devices that support >

Re: [RFC] Add netdev all_adj_list refcnt propagation to fix panic

From: Andrew Collins Date: Tue, 29 Mar 2016 11:25:03 -0600 > This is an RFC patch to fix a relatively easily reproducible kernel > panic related to the all_adj_list handling for netdevs in recent kernels. > > This is more to generate discussion than anything else. I

Re: [PATCH] sctp: flush if we can't fit another DATA chunk

On Wed, Mar 30, 2016 at 03:46:22PM -0400, David Miller wrote: > From: Marcelo Ricardo Leitner > Date: Tue, 29 Mar 2016 10:41:25 -0300 > > > There is no point in delaying the packet if we can't fit a single byte > > of data on it anymore. So lets just reduce the

Re: [PATCH] qed: initialize return rc to avoid returning garbage

From: Colin King Date: Tue, 29 Mar 2016 18:00:50 +0100 > From: Colin Ian King > > in the case where qed_slowpath_irq_req is not called, rc is not > assigned and so qed_int_igu_enable will return a garbage value. > Fix this by initializing rc

Re: [net-next] bond: set mac address only if necessary

From: Zhang Shengju Date: Tue, 29 Mar 2016 15:14:17 + > Bond device gets it's mac address from the first slave device, it's not > necessary to set slave device's mac address to bond if equal. > > Signed-off-by: Zhang Shengju

Re: am335x: no multicast reception over VLAN

> "Mugunthan" == Mugunthan V N writes: Hi, > You had received these packets as tcpdump will enable promiscuous mode > so that you receive all the packets from the wire. FYI, you can use the -p option to tcpdump to not put the interface into promiscuous mode. --

Re: [PATCH] sctp: flush if we can't fit another DATA chunk

From: Marcelo Ricardo Leitner Date: Tue, 29 Mar 2016 10:41:25 -0300 > There is no point in delaying the packet if we can't fit a single byte > of data on it anymore. So lets just reduce the threshold by the amount > that a data chunk with 4 bytes (rounding) would use.

Re: [PATCH-RFC] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for fiber

So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and John) I'm assuming no comments means this patch is acceptable , and I will resubmit it without the RFC. Is that acceptable ? On 03/25/2016 02:58 PM, Daniel Walker wrote: From: Steve Shih This patch

Re: [PATCH-RFC] drivers: net: ethernet: intel: e1000e: fix ethtool autoneg off for fiber

On Wed, 2016-03-30 at 12:34 -0700, Daniel Walker wrote: > > So Intel maintainers (Jeff, Jesse, Shannon, Carolyn, Don, Bruce, and > John) > > I'm assuming no comments means this patch is acceptable , and I will  > resubmit it without the RFC. Is that acceptable ? I personally do not see an issue

Re: [PATCH] sctp: really allow using GFP_KERNEL on sctp_packet_transmit

From: Marcelo Ricardo Leitner Date: Tue, 29 Mar 2016 10:41:03 -0300 > Somehow my patch for commit cea8768f333e ("sctp: allow > sctp_transmit_packet and others to use gfp") missed two important > chunks, which are now added. > > Fixes: cea8768f333e ("sctp: allow

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, 30 Mar 2016 10:35:55 -0700 Alexander Duyck wrote: > On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan > wrote: > > On (03/30/16 10:12), Alexander Duyck wrote: > >> Yeah. The patch was sort of a knee-jerk reaction to being told

Re: [PATCH] bridge: Allow set bridge ageing time when switchdev disabled

From: Haishuang Yan Date: Tue, 29 Mar 2016 18:48:08 +0800 > When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP, > we should ignore this error code and continue to set the ageing time. > > Signed-off-by: Haishuang Yan

Re: [net-next] bond: output message before setting slave to inactive

From: Zhang Shengju Date: Tue, 29 Mar 2016 06:32:57 + > This patch moves output message before setting slave to inactive, this will > print the correct status of slave device. > > Signed-off-by: Zhang Shengju I think

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, 30 Mar 2016 10:12:51 -0700 Alexander Duyck wrote: > On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan > wrote: > > On (03/29/16 23:44), Alexander Duyck wrote: > >> This patch has been sanity checked only. I cannot yet guarantee

Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages

Hi Greg, On Wed, Mar 30, 2016 at 12:24 AM, Greg Ungerer wrote: > Hi Troy, > > Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error > messages') adds a write to a register that is not present in all > implementations of the FEC hardware module. None of the ColdFire >

Re: [PATCH RFC net-next] net: core: Pass XPS select queue decision to skb_tx_hash

On Wed, Mar 30, 2016 at 8:04 PM, John Fastabend wrote: > > OK, so let me see if I get this right now. This was the precedence > before the patch in the normal no select queue case, > > (1) socket mapping sk_tx_queue_mapping iff !ooo_okay > (2) xps >

Re: [PATCH] stmmac: Fix phy without MDIO subnode

I have applied this to my Rock2 - Kernel 4.6-rc1 - and eth0 is present, now, but no network traffic gets through: To rock2: $ ping rgrock2 PING rgrock2 (192.168.0.xx) 56(84) bytes of data. ^C --- rgrock2 ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 7999ms >From

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, Mar 30, 2016 at 10:20 AM, Sowmini Varadhan wrote: > On (03/30/16 10:12), Alexander Duyck wrote: >> Yeah. The patch was sort of a knee-jerk reaction to being told that >> the patch referenced caused a regression. From what I can tell that >> is not the case

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On (03/30/16 10:12), Alexander Duyck wrote: > Yeah. The patch was sort of a knee-jerk reaction to being told that > the patch referenced caused a regression. From what I can tell that > is not the case as I am also seeing the Tx hangs when I run the test > with the frames being linearized. I'm

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On Wed, Mar 30, 2016 at 10:00 AM, Sowmini Varadhan wrote: > On (03/29/16 23:44), Alexander Duyck wrote: >> This patch has been sanity checked only. I cannot yet guarantee it >> resolves the original issue that was reported. I'll try to get a >> reproduction

Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages

On 3/29/2016 8:24 PM, Greg Ungerer wrote: > Hi Troy, > > Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error > messages') adds a write to a register that is not present in all > implementations of the FEC hardware module. None of the ColdFire > SoC parts with the FEC module have the

Re: [PATCH RFC net-next] net: core: Pass XPS select queue decision to skb_tx_hash

On 16-03-30 06:23 AM, Saeed Mahameed wrote: > > > On 3/30/2016 3:18 AM, John Fastabend wrote: >> I would prefer to not have another strange quirk users have to >> remember in order to do tx classification. So with this change >> depending on the driver the queue selection precedence changes. >

Re: [net PATCH] i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet

On (03/29/16 23:44), Alexander Duyck wrote: > This patch has been sanity checked only. I cannot yet guarantee it > resolves the original issue that was reported. I'll try to get a > reproduction environment setup tomorrow but I don't know how long that > should take. I tried this out with

Re: Question on rhashtable in worst-case scenario.

On 03/30/2016 09:38 AM, David Miller wrote: From: Johannes Berg Date: Wed, 30 Mar 2016 11:14:12 +0200 On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: Looks like rhashtable has too much policy in it to properly deal with cases where there are too many hash

Re: am335x: no multicast reception over VLAN

On Wednesday 30 March 2016 02:05 PM, Yegor Yefremov wrote: > On Wed, Mar 30, 2016 at 7:33 AM, Mugunthan V N wrote: >> On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote: >>> On 03/29/2016 03:35 PM, Yegor Yefremov wrote: On Tue, Mar 29, 2016 at 1:05 PM, Grygorii

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

th HW capability register and w/o Enhanced > descriptors. > Are you still working on a fix for: [1.196110] libphy: PHY stmmac-0: not found [1.200972] eth0: Could not attach to PHY [1.204991] stmmac_open: Cannot attach to PHY (error: -19) I see the error still there as of linux-next 20160330. Dinh

[PATCH 1/4] net: w5100: move mmiowb into register access callbacks

Instead of sprinkle mmiowb over the driver code, move it into primary register write callbacks. (w5100_write, w5100_write16, w5100_writebuf) This is a preparation for supporting SPI interface which doesn't use MMIO for accessing w5100 registers. Signed-off-by: Akinobu Mita

[PATCH 3/4] net: w5100: enable to support sleepable register access interface

SPI transfer routines are callable only from contexts that can sleep. This adds ability to tell the core driver that the interface mode cannot access w5100 register on atomic contexts. In this case, workqueue and threaded irq are required. Signed-off-by: Akinobu Mita

[PATCH 4/4] net: w5100: support SPI interface mode

This adds new w5100-spi driver which shares the bus interface independent code with existing w5100 driver. Signed-off-by: Akinobu Mita Cc: Mike Sinkovsky Cc: David S. Miller --- drivers/net/ethernet/wiznet/Kconfig | 14

[PATCH 2/4] net: w5100: add ability to support other bus interface

The w5100 driver currently only supports direct and indirect bus interface mode which use MMIO space for accessing w5100 registers. In order to support SPI interface mode which is supported by W5100 chip, this makes the bus interface abstraction layer more generic so that separated w5100-spi

Re: Question on rhashtable in worst-case scenario.

From: Johannes Berg Date: Wed, 30 Mar 2016 11:14:12 +0200 > On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: >> Looks like rhashtable has too much policy in it to properly deal with >> cases where there are too many hash collisions, so I am going to work >> on

Re: [PATCH net-next v3 1/2] net: dsa: mv88e6xxx: Introduce _mv88e6xxx_phy_page_{read,write}

Hi, Could this patch and the patch 2/2 v3 "net: dsa: mv88e6xxx: Clear the PDOWN bit on setup" be put on net, since this fixes a bug with the clearfog, which was introduced in v4.5? Thanks, Patrick On Wed, Mar 30, 2016 at 1:39 AM, Patrick Uiterwijk wrote: > Add versions

Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform

Hi Jisheng, On mer., mars 30 2016, Jisheng Zhang wrote: > The mvneta BM can't work on 64bit platform, as the BM hardware expects > buf virtual address to be placed in the first four bytes of mapped > buffer, but obviously the virtual address on 64bit platform can't be >

  1   2   >