On Sat, 2018-09-29 at 11:44 -0700, David Miller wrote:
> From: Yifeng Sun
> Date: Wed, 26 Sep 2018 11:40:14 -0700
>
> > This patch fixes the bug that all datapath and vport ops are returning
> > wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
> >
> > Signed-off-by: Yifeng Sun
On Sun, 2017-10-22 at 21:31 -0700, Eric Dumazet wrote:
> On Mon, 2017-10-23 at 13:28 +0900, Koichiro Den wrote:
>
> > Indeed, meaning that tcp_clean_rtx_queue implementation never takes.
> > But for me it seems that there is some possibility RACK algorithm will take
> >
On Sun, 2017-10-22 at 20:40 -0700, Eric Dumazet wrote:
> On Mon, 2017-10-23 at 12:26 +0900, Koichiro Den wrote:
>
> > Now I wonder this is more of a theoretical one rather than a patch to fix
> > one
> > specific bug.
>
>
> Note that I said that your patch wa
On Sun, 2017-10-22 at 10:11 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 09:49 -0700, Eric Dumazet wrote:
>
> > Here is the test I cooked.
> >
> > Note that it actually passes just fine, do I am wondering if your patch
> > is needed after all..
> >
>
> Oh this is because tcp_mstamp_refres
On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > > > When retransmission on TSQ
avy.
So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
ensures the accuracy of algorithms relying on it.
Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
Signed-off-by: Koichiro Den
Reviewed-by: Eric Dumazet
---
net/ipv4/tcp_output.c | 4 ++
On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > When retransmission on TSQ handler was introduced in the commit
> > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> > skbs&
avy.
So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
ensures the accuracy of algorithms relying on it.
Signed-off-by: Koichiro Den
---
net/ipv4/tcp_output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_out
On Sat, 2017-10-14 at 08:46 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Combining actual collapsing with reasoning for deciding the starting
> > point, we can apply its logic in a consistent manner such that we can
> > avoid costl
On Sat, 2017-10-14 at 08:43 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Since 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
> > applied, we no longer need to continue to search for the starting
> > point onc
On Sat, 2017-10-14 at 08:42 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > On the starting point chosen, it could be possible that just one skb
> > remains in between the range provided, leading to copying and re-insertion
> > of rb n
This patch series removes possible useless copying and collapsing while
not missing the chance when it is worth the effort. Also reorganizes it
and do some cleanups.
Koichiro Den (3):
tcp: avoid useless copying and collapsing of just one skb
tcp: do not tcp_collapse once SYN or FIN found
have been queued up.
Signed-off-by: Koichiro Den
---
net/ipv4/tcp_input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d0682ce2a5d6..1d785b5bf62d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4807,7
#x27;tail' argument.
Signed-off-by: Koichiro Den
---
net/ipv4/tcp_input.c | 197 +++
1 file changed, 90 insertions(+), 107 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1a74457db0f3..5fb90cc0ae95 100644
--- a/net/ipv
d help us with error message when actual receiving.
Signed-off-by: Koichiro Den
---
net/ipv4/tcp_input.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1d785b5bf62d..1a74457db0f3 100644
--- a/net/ipv4/tcp_in
On Wed, 2017-08-23 at 23:28 +0900, Koichiro Den wrote:
> On Tue, 2017-08-22 at 20:55 +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 22, 2017 at 10:50:41AM +0800, Jason Wang wrote:
> > > > Perhaps the descriptor pool should also be
> > > > revised to allow out of
On Tue, 2017-08-22 at 20:55 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 22, 2017 at 10:50:41AM +0800, Jason Wang wrote:
> > > Perhaps the descriptor pool should also be
> > > revised to allow out of order completions. Then there is no need to
> > > copy zerocopy packets whenever they may experie
On Tue, 2017-08-22 at 13:19 -0400, Willem de Bruijn wrote:
> > > > > /* Don't wait up for transmitted skbs to be freed. */
> > > > > if (!use_napi) {
> > > > > + if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
> > > > > + struct ubuf_info *u
On Tue, 2017-08-22 at 13:16 -0400, Willem de Bruijn wrote:
> > > > An issue of the referenced patch is that sndbuf could be smaller than
> > > > low
> > > > watermark.
> >
> > We cannot determine the low watermark properly because of not only sndbuf
> > size
> > issue but also the fact that the up
ut let's not waste cpu cycles.
>
> Reported-by: Koichiro Den
> Signed-off-by: Michael S. Tsirkin
> ---
>
> Lightly tested, would appreciate an ack from reporter.
>
> drivers/vhost/vhost.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
On Mon, 2017-08-21 at 22:45 +0300, Michael S. Tsirkin wrote:
> On Sat, Aug 19, 2017 at 03:41:14PM +0900, Koichiro Den wrote:
> > Signed-off-by: Koichiro Den
> > ---
> > drivers/vhost/vhost.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> &g
On Tue, 2017-08-22 at 08:11 -0400, Willem de Bruijn wrote:
> On Sun, Aug 20, 2017 at 4:49 PM, Willem de Bruijn
> wrote:
> > On Sat, Aug 19, 2017 at 2:38 AM, Koichiro Den wrote:
> > > Facing the possible unbounded delay relying on freeing on xmit path,
> > > we also
On Mon, 2017-08-21 at 23:10 -0400, Willem de Bruijn wrote:
> > > > Interesting, deadlock could be treated as a a radical case of the
> > > > discussion
> > > > here https://patchwork.kernel.org/patch/3787671/.
> > > >
> > > > git grep tells more similar skb_orphan() cases. Do we need to change
> >
On Mon, 2017-08-21 at 20:40 +0800, Jason Wang wrote:
>
> On 2017年08月21日 11:06, Jason Wang wrote:
> >
> >
> > On 2017年08月19日 14:41, Koichiro Den wrote:
> > > To depend on vq.num and the usage of VHOST_MAX_PEND is not succinct
> > > and in some case
On Mon, 2017-08-21 at 11:06 +0800, Jason Wang wrote:
>
> On 2017年08月19日 14:41, Koichiro Den wrote:
> > To depend on vq.num and the usage of VHOST_MAX_PEND is not succinct
> > and in some case unexpected, so revert its logic part only.
>
> Hi:
>
> Could you explain
On Mon, 2017-08-21 at 20:33 +0800, Jason Wang wrote:
>
> On 2017年08月19日 14:38, Koichiro Den wrote:
> > Facing the possible unbounded delay relying on freeing on xmit path,
> > we also better to invoke and clear the upper layer zerocopy callback
> > beforehand to ke
On Sun, 2017-08-20 at 16:49 -0400, Willem de Bruijn wrote:
> On Sat, Aug 19, 2017 at 2:38 AM, Koichiro Den wrote:
> > Facing the possible unbounded delay relying on freeing on xmit path,
> > we also better to invoke and clear the upper layer zerocopy callback
> > beforeh
On Sun, 2017-08-20 at 16:30 -0400, Willem de Bruijn wrote:
> On Sat, Aug 19, 2017 at 2:37 AM, Koichiro Den wrote:
> > The module param napi_tx needs not to be writable for now since we do
> > not have any means of activating/deactivating it online,
>
> A virtio_net device
To depend on vq.num and the usage of VHOST_MAX_PEND is not succinct
and in some case unexpected, so revert its logic part only.
Signed-off-by: Koichiro Den
---
drivers/vhost/net.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost
Signed-off-by: Koichiro Den
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e4613a3c362d..93e909afc1c3 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1184,7 +1184,7 @@ static int
zerocopy-enabled vhost-net.
This does not apply if napi_tx is enabled since it will be called in
reasonale time.
Signed-off-by: Koichiro Den
---
drivers/net/virtio_net.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4302f313d9a7
The module param napi_tx needs not to be writable for now since we do
not have any means of activating/deactivating it online, which seems to
be a low priority. Also make it clear that napi_tx is disabled when it
has been dynamically disabled behind the scenes.
Signed-off-by: Koichiro Den
Sorry I mistakenly focused on NET case, please pass it over. I will do any
relevant suggestion in patch-based way. Thanks.
On Sun, 2017-08-13 at 23:11 +0900, Koichiro Den wrote:
> Thanks for your comments, Michael and Jason. And I'm sorry about late
> response.
> To be honest, I
Thanks for your comments, Michael and Jason. And I'm sorry about late response.
To be honest, I am on a summer vacation until next Tuesday.
I noticed that what I wrote was not sufficient. Regardless of caching mechanism
existence, the "event" could legitimately be at any point out of the latest
in
l but the aforementioned case.
Signed-off-by: Koichiro Den
---
net/xfrm/xfrm_state.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 6c0956d10db6..a792effdb0b5 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1
reckons
it as a bad csum.
This patch makes remcsum_offload being reset at the same time of GRO
remcsum cleanup, so as to make it work in such case as before.
Fixes: b7fe10e5ebac ("gro: Fix remcsum offload to deal with frags in GRO")
Signed-off-by: Koichiro Den
---
net/ipv4/fou.c | 1
kons
it as a bad csum.
This patch makes remcsum_offload being reset at the same time of GRO
remcsum cleanup, so as to make it work in such case as before.
Fixes: b7fe10e5ebac ("gro: Fix remcsum offload to deal with frags in GRO")
Signed-off-by: Koichiro Den
---
drivers/net/vxlan.c | 1
37 matches
Mail list logo
