Hi,
+ linux arm kernel
On Thu, 31 Mar 2016 14:36:30 +0800 Jisheng Zhang wrote:
> The rx descriptors are allocated using dma_alloc_coherent, so prefetch
> doesn't really happen at all.
This is for RFC, I'm sorry to send it without changing its title -- s/PATCH/RFC.
I'm not sure whether there's
Hi Jisheng,
2016-03-31 7:53 GMT+02:00 Jisheng Zhang :
> 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 add
The rx descriptors are allocated using dma_alloc_coherent, so prefetch
doesn't really happen at all.
Signed-off-by: Jisheng Zhang
---
drivers/net/ethernet/marvell/mvneta.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvn
On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>> "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 n
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 of mapped
> > buffer,
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
#include
#include
+#incl
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 m
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 was
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
#include
+#include
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 changed, 41 insertions(+), 2
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 b/include/net/busy_poll.h
index
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%/ +2
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
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 = rcu_derefer
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 fu
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:
> >
> > [ 52.765684
>> 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 E
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
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 support for enabling SO_TIMESTAMPING via cont
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 sure whenever ip6_datagram_send_ctl is calle
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 whenever ip_cmsg_send is called in udp, icmp,
>
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 accepts TX recording flags (i.e.,
> SOF_TIMESTAMP
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 sk_tsflags. This is
> implemented based on an implici
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 starting point to calculate
> relative IDs.
>
> T
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; linux-ker...@vger.kernel.org; Xia
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 not +last, " error messages
>>
>> Hi Greg,
>>
>> On Wed, Mar 30, 2016 a
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, Mar 30, 2016 at 12:24 AM, Greg Ungerer wrote:
> > Hi Troy,
> >
> > Comm
> 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 the message is in the appropriate spot wrt. state, so I
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!
>
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
>> implementations of the F
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.
> Can you share m
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!
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] rcu
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 than "256.10.166.1/24".
>
Yes, this fixes it for me too!
Tested-by: Sowmini Varadhan
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 tha
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 10:20 AM, Sowmini Varadhan
>>> wrote:
>>> > On (03/30/16 10:12), Alexander Duyck w
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
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
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 the test, so the curr
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 hole in the read-mostly
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 the test, so the curr
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 was setting up bad fil
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
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 address equals to FF:FF:FF
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
Signed-off-by: Jeff Kirsher
---
drivers/net/ethernet/intel/
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 : protocol ip prio 99 \
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 Fastabend
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
drivers/net/ether
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)
Signed-off-by: Sridhar Samudr
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 program both source and dest p
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 messages.
This is
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 via socket options fo
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.
Note that this commi
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 on a
passive TCP fast
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 from the loop that walks
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
overhead. With cmsg
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 sockcm_cookie` (added in the
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,
SOF_TIMESTAMPING_TX_SCHED, a
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 deletions(-)
diff --git a/Documentation/ne
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
th
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 that TI drivers are n
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), Alexander Duyck wrote:
>> >> Yeah. The patch was sort of a knee-jerk reaction to be
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 netns_ipv
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 are filterred by mc list
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 i
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
particularly like this appro
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 with
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 threshold by the amount
> > that a
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 the NewReno
>> RFC 2582 to reduce the potential
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 fra
From: David Miller
Date: Wed, 30 Mar 2016 16:01:50 -0400 (EDT)
> Veaceslav, please look into this.
Of course, his email now bounces :-/
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
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
> NETIF_F_GSO_GRE_CSUM.
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
> particularly like th
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 threshold by the amount
> > that a
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 to 0.
>
> Signed-off-by: Colin Ian King
Applied, t
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
I don't think bond enslavement occurs often enough to justify thi
> "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.
--
Bye, Peter Korsgaard
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.
>
> Signed-off-by: Marcelo
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 fixes the issues for d
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
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 sctp_transmit_packet and others to
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 that
> >> the patch referenced caused a regression. From w
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
Applied and queued up for -stable, thanks.
> @@ -582,7 +5
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 the message is in the appropriate spot wrt. state, so I will not
apply th
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 it
> >> resolves the original issue that was reported. I'
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
> SoC parts with the
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
> (3) skb->queue_mapping
>
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 ro
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 as I am also seeing the Tx hang
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 n
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 environment setup tomorrow but I don't
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 FT
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.
>
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 rds-st
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 collisions, so I am going to wor
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 Strashko
wrote:
>
y 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
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
Cc: Mike Sinkovsky
Cc
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
Cc: Mike Sinkovsky
Cc: Dav
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
drivers/net/ethernet/wiznet/Makefile| 1 +
drivers/net/eth
1 - 100 of 144 matches
Mail list logo
