Re: [RFC 1/6] bidi support: request dma_data_direction

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

 



On Mon, 2007-01-22 at 10:05 -0500, Douglas Gilbert wrote:
> Perhaps the right use of DMA_BIRECTIONAL needs to be
> defined.
> 
> Could it be used with a XDWRITE(10) SCSI command
> defined in sbc3r07.pdf at http://www.t10.org ? I suspect
> using two scatter gather lists would be a better approach.
> 
> >>> - Introduce new blk_rq_init_unqueued_req() and use it in places ad-hoc
> >>>   requests were used and bzero'ed.
> >> With a bi-directional transfer is it always unambiguous
> >> which transfer occurs first (or could they occur at
> >> the same time)?
> > 
> > The bidi transfers can occur in any order and in parallel.

> Then it is not sufficient for modern SCSI transports in which
> certain bidirectional commands (probably most) have a well
> defined order.

Right, that's why I think bi-directional needs to be one way op followed
by one way op ... even if it is to the same buffer.  That should be a
general enough paradigm for everything.

> So DMA_BIDIRECTIONAL looks PCI specific and it may have
> been a mistake to replace other subsystem's direction flags
> with it. RDMA might be an interesting case.

It's bus specific ... it means that the bus must be programmed to expect
the device to transfer both to and from the memory buffer.  There are a
very few drivers which do this when they don't know the actual transfer
direction, so it might be reasonably tested on architectures ... but
we'd probably have to check.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux