Re: InfiniBand/RDMA merge plans for 2.6.24

[Shirley Ma]

Roland Dreier [EMAIL PROTECTED] wrote on 09/17/2007 02:47:42 PM:

IPoIB CM handles this properly by gathering together single pages 
in
skbs' fragment lists.
 
   Then can we reuse IPoIB CM code here?
 
 Yes, if possible, refactoring things so that the rx skb allocation
 code becomes common between CM and non-CM would definitely make sense.

IPoIB-CM rx skb allocation is not generic to be used by UD, it allocates 
more buffers than needed if mtu is not 64K, and doesn't query the real 
max_num_sg from the device. I am thinking to have a generic skb allocation 
in IPoIB based on matrix of (ipoib-mtu-size, page-size, max_num_sg, 
head-size).

Thanks
Shirley 
-
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

Re: InfiniBand/RDMA merge plans for 2.6.24

[Shirley Ma]

 IPoIB CM handles this properly by gathering together single pages in
 skbs' fragment lists.
 
  - R.

Then can we reuse IPoIB CM code here?

Thanks
Shirley 

-
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

Re: InfiniBand/RDMA merge plans for 2.6.24

[Shirley Ma]

Hello Roland,
 
Since ehca can support 4K MTU, we would like to see a patch in 
IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24 
kernel. The idea is IPoIB link MTU will pick up a return value from SM's 
default broadcast MTU. This patch should be a small patch, I hope you are 
OK with this.

Thanks
Shirley
-
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

Re: RFC: issues concerning the next NAPI interface

[Shirley Ma]

 Just to be clear, in the previous email I posted on this thread, I
 described a worst-case network ping-pong test case (send a packet, wait
 for reply), and found out that a deffered interrupt scheme just damaged
 the performance of the test case. 

When splitting rx and tx handler, I found some performance gain by 
deffering interrupt scheme in tx not rx in IPoIB driver.

Shirley
-
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

Re: [PATCH RFC]: napi_struct V5

[Shirley Ma]

Hello Roland,

 Shirley, I think it would still be useful to run benchmarks of IPoIB
 on ehca with Dave's NAPI patches, both V5 that changed the missed
 event behavior and V6 that didn't.  At least I'm curious to know how
 much the difference is.
 
  - R.

The performance difference was huge before. Most of the time the poll more 
method was only polling one packet again and agin. 
Yes, we will definitely run the performance measurement, but I have 
lowered this task priority since Dave has V6 version. Actually IPoIB is 
not the only one device using rescheduling instead of polling more for 
NAPI. I think it's not a bad idea to do so.

Thanks
Shirley 
-
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

Re: [PATCH RFC]: napi_struct V5

[Shirley Ma]

Dave,

 I reverted everything Roland had an issue with, I got tired of arguing
 my position and doing all of the coding too.  He won.
Thanks. I think the reschedule in the IPoIB poll should maintain fairness.

Shirley
-
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

Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB

[Shirley Ma]

Hello Herbert,

  Not because I think it obviates your work, but rather because I'm
  curious, could you test a TSO-in-hardware driver converted to
  batching and see how TSO alone compares to batching for a pure
  TCP workload?
 
 You could even lower the bar by disabling TSO and enabling
 software GSO.

We had a discuss before. GSO doesn't benefit device which has no HW 
checksum (like IPoIB) by inducing an extra copy. And GSO benefits one 
stream, batching benefits multiple streams.

Thanks
Shirley
-
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