2010-06-15 15:35:39

by Jan-Bernd Themann

Subject: [PATCH 1/2] ehea: fix delayed packet processing

In the eHEA poll function an rmb() is required. Without that some packets
on the receive queue are not seen and thus delayed until the next interrupt
is handled for the same receive queue.

Signed-off-by: Jan-Bernd Themann <[email protected]>

---
Patch created against 2.6.35-rc3

drivers/net/ehea/ehea_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f547894..fd890fa 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -867,6 +867,7 @@ static int ehea_poll(struct napi_struct *napi, int budget)
ehea_reset_cq_ep(pr->send_cq);
ehea_reset_cq_n1(pr->recv_cq);
ehea_reset_cq_n1(pr->send_cq);
+ rmb();
cqe = ehea_poll_rq1(pr->qp, &wqe_index);
cqe_skb = ehea_poll_cq(pr->send_cq);

--
1.7.0

2010-06-15 16:46:12

by Jay Vosburgh

Subject: Re: [PATCH 1/2] ehea: fix delayed packet processing

Jan-Bernd Themann <[email protected]> wrote:

>In the eHEA poll function an rmb() is required. Without that some packets
>on the receive queue are not seen and thus delayed until the next interrupt
>is handled for the same receive queue.
>
>Signed-off-by: Jan-Bernd Themann <[email protected]>

To add a bit of background, this could manifest during a netperf
TCP_RR or UDP_RR on an otherwise idle network. TCP would occasionally
retransmit, but then both the original segment and the retransmission
would simultaneously appear at the receiver. For UDP_RR, message sizes
in excess of the mtu would occasionally "lose" an IP fragment, and
eventually IP reassembly would time out.

-J

Signed-off-by: Jay Vosburgh <[email protected]>


>---
>Patch created against 2.6.35-rc3
>
> drivers/net/ehea/ehea_main.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
>index f547894..fd890fa 100644
>--- a/drivers/net/ehea/ehea_main.c
>+++ b/drivers/net/ehea/ehea_main.c
>@@ -867,6 +867,7 @@ static int ehea_poll(struct napi_struct *napi, int budget)
> ehea_reset_cq_ep(pr->send_cq);
> ehea_reset_cq_n1(pr->recv_cq);
> ehea_reset_cq_n1(pr->send_cq);
>+ rmb();
> cqe = ehea_poll_rq1(pr->qp, &wqe_index);
> cqe_skb = ehea_poll_cq(pr->send_cq);
>
>--
>1.7.0
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html

2010-06-17 01:05:30

by David Miller

Subject: Re: [PATCH 1/2] ehea: fix delayed packet processing

From: Jay Vosburgh <[email protected]>
Date: Tue, 15 Jun 2010 09:45:47 -0700

> Jan-Bernd Themann <[email protected]> wrote:
>
>>In the eHEA poll function an rmb() is required. Without that some packets
>>on the receive queue are not seen and thus delayed until the next interrupt
>>is handled for the same receive queue.
>>
>>Signed-off-by: Jan-Bernd Themann <[email protected]>
>
> To add a bit of background, this could manifest during a netperf
> TCP_RR or UDP_RR on an otherwise idle network. TCP would occasionally
> retransmit, but then both the original segment and the retransmission
> would simultaneously appear at the receiver. For UDP_RR, message sizes
> in excess of the mtu would occasionally "lose" an IP fragment, and
> eventually IP reassembly would time out.
>
> -J
>
> Signed-off-by: Jay Vosburgh <[email protected]>

Applied.