> I'll have a look at converting these atomic operations into regular
> locking. The current implementation should be fine though.
I believe that the current implementation is correct. However it is
much harder for someone naive like me to understand, since using cmpxchg
is much subtler than ju
On Wed, Jan 5, 2011 at 9:21 PM, Roland Dreier wrote:
>
> So, just looking over some of the atomic_t usage here (which is usually
> one of the first places I review):
>
> > +struct srpt_send_ioctx {
> > ...
> > + atomic_t state;
>
> this seems to be accessed only with atomic_re
So, just looking over some of the atomic_t usage here (which is usually
one of the first places I review):
> +struct srpt_send_ioctx {
> ...
> +atomic_tstate;
this seems to be accessed only with atomic_read(), atomic_set() and
atomic_cmpxchg() (without any memory barriers).
On Tue, Dec 21, 2010 at 2:50 AM, Jack Wang wrote:
>
> >
> > This patch adds the kernel module ib_srpt, which is a SCSI RDMA Protocol
> (SRP)
> > target implementation. This driver uses the InfiniBand stack and the SCST
> core.
> [ ... ]
>
> [Jack] This README looks should update to new sysfs inter
>
> This patch adds the kernel module ib_srpt, which is a SCSI RDMA Protocol
(SRP)
> target implementation. This driver uses the InfiniBand stack and the SCST
core.
>
> It is a high performance driver capable of handling 600K+ 4K random write
> IOPS by a single target as well as 2.5+ GB/s sequent
