Hello Eric,
On Mon, Oct 21, 2019 at 9:02 PM Eric Dumazet wrote:
> Reporting tsval/tsecr values were not well defined and seemed quite
> experimental to me.
>
> TCP fastopen would use 2 unused bits, not real extra cost here.
>
> This is persistent information after the connect(), while your tsval
Hello Jason,
On Sat, Oct 19, 2019 at 11:10 AM Jason Baron wrote:
> The TCPI_OPT_SYN_DATA bit as part of tcpi_options currently reports whether
> or not data-in-SYN was ack'd on both the client and server side. We'd like
> to gather more information on the client-side in the failure case in order
On Thu, Oct 3, 2019 at 1:14 AM Eric Dumazet wrote:
> I would rather use a new getsockopt() to fetch this specific data,
> instead of making TCP_INFO bigger for everyone :/
>
> ss command can dump millions of sockets in busy hosts, we need to be
> careful of TCP_INFO size.
Thanks Eric for your adv
Hello Eric,
On Thu, Oct 3, 2019 at 12:33 AM Eric Dumazet wrote:
> On 10/2/19 3:10 PM, William Dauchy wrote:
> Reporting the last recorded values is really not good,
> a packet capture will give you all this information in a non
> racy way.
Thank you for your quick answer.
In my us
tsval and tsecr are useful in some cases to diagnose TCP issues from the
sender point of view where unexplained RTT values are seen. Getting the
the timestamps from both ends will help understand those issues more
easily.
Signed-off-by: William Dauchy
---
include/uapi/linux/tcp.h | 3 +++
net
Hello Hello Don,
Thank you for your help.
On Fri, May 6, 2016 at 6:26 PM, Skidmore, Donald C
wrote:
> My validation hasn't be able to recreate the dereference on v4.1.x, v4.5.x or
> net_next. Where exactly did you place the two line script in your rc
> scripts. Our validation was able to run
Hello Don,
Thank you for your reply.
On Mon, May 2, 2016 at 11:33 PM, Skidmore, Donald C
wrote:
> Thanks for reporting the dereference. Could you provide a little more detail
> on how you created this issue? Are you just running the two commands (ip,
> sriov_numvfs) in some rc script and if
Hello,
I am getting a NULL dereference on v4.1.x while enabling VF on a ixgbe
( Intel Corporation 82599ES 10-Gigabit) card during boot.
It seems to be related to a race since I don't have the issue if I
test it a few seconds after boot. I had the same issue while testing
on v4.5.x
What can I do to
Hi Jeff,
Any chance to get an opinion on that?
Thanks,
On Nov27 11:05, William Dauchy wrote:
> Hello Jeff,
>
> I faced the problem described in commit 7e3f5c8:
> ixgbe: fix bounds checking in ixgbe_setup_tc for 82598
>
> This patch resolves an issue where users were not a
Hello Jeff,
I faced the problem described in commit 7e3f5c8:
ixgbe: fix bounds checking in ixgbe_setup_tc for 82598
This patch resolves an issue where users were not able to dynamically
set number of queues for 82598 via ethtool -L
I backported it for my v4.1.x build but I was wondering if this
Hello Jeff,
There is also the equivalent patch for ixgbevf
http://patchwork.ozlabs.org/patch/539065/
On Mon, Nov 23, 2015 at 8:36 PM, Jeff Kirsher
wrote:
> From: Alexander Duyck
>
> This patch corrects an issue in which the polling routine would increase
> the budget for Rx to at least 1 per q
Hello,
I'm seeing some kmemleak reports while I'm using nfsv3/4 as a client on
linux v4.1.13;
unreferenced object 0x880c22a97ad0 (size 16):
comm "softirq", pid 0, jiffies 4294896089 (age 43927.436s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 45 1e 24 06 88 ff ff .E
On Nov11 22:13, Rustad, Mark D wrote:
> Just so you know, there are patches in queue that will improve this situation
> in two ways:
> 1) When the I2C probe times out, the code assumes that the cage is empty and
> does not retry the access until the next probe.
> 2) The driver will use its own pr
On Nov11 20:33, Tantilov, Emil S wrote:
> If the diff above is the patch you are referring to then you will break the
> SFP+ detection in the case where the driver was loaded while there were no
> SFP+ modules present in the cages.
understood, I was surprised of the modification of behavior.
--
Hello,
I upgraded a machine from 3.14.x to v4.1.x and noted that I now have two
kworker very often on D state, just after boot while I am not doing
anything special. This issue remains indefinitely.
This machine has four network interfaces:
01:00.0 Ethernet controller: Intel Corporation 82576 G
On Tue, Sep 29, 2015 at 6:12 PM, Anand Gurram
wrote:
> Any additional ideas and suggestions on debugging in above scenario?
You may give a try with the recent patch:
packet: race condition in packet_bind
http://www.spinics.net/lists/netdev/msg351337.html
--
William
--
To unsubscribe from this l
Hi Francesco,
On Thu, Nov 5, 2015 at 5:16 PM, Francesco Ruggeri
wrote:
> There is a race conditions between packet_notifier and packet_bind{_spkt}.
>
> It happens if packet_notifier(NETDEV_UNREGISTER) executes between the
> time packet_bind{_spkt} takes a reference on the new netdevice and the
>
Hello David,
On Oct29 16:26, William Dauchy wrote:
> I faced the problem described in commit 7e3f5c8:
> ixgbe: fix bounds checking in ixgbe_setup_tc for 82598
>
> This patch resolves an issue where users were not able to dynamically
> set number of queues for 82598 via et
This is the same patch as for ixgbe but applied differently according to
busy polling.
see commit "ixgbe: Fix handling of napi budget when multiple queues are
enabled per vector"
Signed-off-by: William Dauchy
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 ++
1 file
get was 0 which
> is meant to indicate that no Rx can be handled.
We may logically have the same issue with VF, right?
>From 4521374ae746543a925982d59a8ba73b6aaee59c Mon Sep 17 00:00:00 2001
From: William Dauchy
Date: Fri, 30 Oct 2015 15:48:43 +0100
Subject: [PATCH] ixgbevf: Fix handling of n
Hello David,
I faced the problem described in commit 7e3f5c8:
ixgbe: fix bounds checking in ixgbe_setup_tc for 82598
This patch resolves an issue where users were not able to dynamically
set number of queues for 82598 via ethtool -L
I backported it for my v4.1.x build but I was wondering if thi
21 matches
Mail list logo
