Re: [PATCH v9 06/25] RDMA/rtrs: client: main functionality

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 05, 2020 at 02:37:59PM +0100, Jinpu Wang wrote:
> On Thu, Mar 5, 2020 at 2:27 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> >
> > On Thu, Mar 05, 2020 at 12:26:01PM +0100, Jinpu Wang wrote:
> >
> > > We have to admit, the code snip is from null_blk, get_tag function,
> > > not invented by us.
> > > the get_cpu/put_cpu was added to get/save the current cpu_id, which
> > > can be removed around the do-while loop.,
> > > we only need to raw_smp_processor_id to get current cpu, we use it
> > > later to pick which connection to use.
> >
> > Be careful copying crazy core code into drivers..
> >
> > > > You have to do something to provably guarantee the send q cannot
> > > > overflow. send q overflow is defined as calling post_send before a
> > > > poll_cq has confirmed space is available for send.
> >
> > > Shouldn't the cq api handle that already,  with IB_POLL_SOFTIRQ,
> > > poll cq is done on very softirq run, so send queue space should be reclaimed
> > > fast enough, with IB_POLL_WORKQUEUE, when cq->com_handler get called,
> > > the ib_cq_poll_work will do the poll_cq, together with extra
> > > send_queue size reserved,
> > > the send queue can not overflow!
> >
> > Somehow that doesn't sound like 'provably guarentee' - that is some
> > statistical argument..
> Could you give an example which meets the "provably guarantee",
> seems most of the driver is based on the cq API.

You are supposed to directly keep track of completions and not issue
sends until completions are seen.

Jason



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux