[openib-general] Re: [PATCH] repost: IPoIB queue size tune patch

[Shirley Ma]

Hello Michael,

"Michael S. Tsirkin" <mst at mellanox.co.il> wrote on 04/04/2006 10:22:08 AM:

> Quoting r. Shirley Ma <xma at us.ibm.com>:
> > Subject: Re: [PATCH] repost: IPoIB queue size tune patch
> > 
> > 
> > Hello Roland,
> > 
> > Thanks.
> > 
> > Roland Dreier <rdreier at cisco.com> wrote on 04/03/2006 10:50:37 PM:
> > 
> > > Sorry I hadn't gotten a chance to read this over until now...
> > >
> > >  > -       IPOIB_RX_RING_SIZE        = 128,
> > >  > -       IPOIB_TX_RING_SIZE        = 64,
> > >  > +       IPOIB_SENDQ_SIZE          = 64,
> > >  > +       IPOIB_RECVQ_SIZE          = 128,
> > >
> > > Can you explain again why it's a good idea to rename these?  Is the
> > > name "sendq_size" really clearer than "tx_ring_size," especially in
> > > the context of a network driver?
> > 
> > tx_ring and rx_ring are not good names for IPoIB. tx_ring in IPoIBis a 
place
> > to save pointers and rx_ring a place to allocate skb buffs.
> 
> Actually names make sense to me - they are cyclic buffers, hence ring.
> 
> > I am working on
> > a patch to remove tx_ring and replace rx_ring with a list, which would
> > reduce some tx_ring overhead.
> 
> What overhead?  Please don't, lists are bad for cache, require locks ...
> Circular buffers are much better, I don't have the time now but I think 
we can
> even make event handler completely lockless with them.

IPoIB is not a real driver. Packets can be dropped from dev xmit queue to 
QPs send queue directly. Why we use tx_ring to induce overhead in 
send path?

Also, using a list doesn't always mean to induce a lock. I will test the 
patch
performance before I submit for review.

We really want this patch to be in RC2 release. I will change the name 
back 
if this would prevent the patch from being into upper stream.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060404/789d7c65/attachment.html>