public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: Bhanu Gollapudi <bprakash@broadcom.com>
Cc: "devel@open-fcoe.org" <devel@open-fcoe.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Michael Chan <mchan@broadcom.com>
Subject: Re: [v2 PATCH 4/5] bnx2fc: Broadcom FCoE Offload driver submission - part 2
Date: Wed, 02 Feb 2011 03:24:14 -0600	[thread overview]
Message-ID: <4D4922BE.40907@cs.wisc.edu> (raw)
In-Reply-To: <1295311066.3536.105.camel@ltsjc-bprakash2.corp.ad.broadcom.com>

On 01/17/2011 06:37 PM, Bhanu Gollapudi wrote:
>>
>> Are you sending a abort when a lun or target reset has been successfully
>> completed? Does your hw need the reset? SCSI spec wise the lun or target
>> reset will take care of the scsi commands on its side, so there is no
>> need to send an abort.
>
> It is better to send ABTS on all the outstanding IOs after issuing
> lun/target reset.  targets may take care of scsi commands on its side.
> But the commands on the flight may have to be aborted. This is as per
> the FCP-4 spec in "Table 8 - Clearing effects of initiator FCP-Port
> actions" :-
> "Exchanges are cleared internally within the target FCP_Port, but open
> FCP Sequences shall be individually aborted by the initiator FCP_Port
> using ABTS-LS that also has the effect of aborting the associated FCP
> Exchange. See 12.3."

Ughh. I must have misread that before. I think libfc is broken then.



>>
>>> +}
>>> +
>>> +static int bnx2fc_map_sg(struct bnx2fc_cmd *io_req)
>>> +{
>>> +     struct bnx2fc_hba *hba = io_req->port->hba;
>>> +     struct scsi_cmnd *sc = io_req->sc_cmd;
>>> +     struct fcoe_bd_ctx *bd = io_req->bd_tbl->bd_tbl;
>>> +     struct scatterlist *sg;
>>> +     int byte_count = 0;
>>> +     int sg_count = 0;
>>> +     int bd_count = 0;
>>> +     int sg_frags;
>>> +     unsigned int sg_len;
>>> +     u64 addr;
>>> +     int i;
>>> +
>>> +     sg = scsi_sglist(sc);
>>> +     sg_count = pci_map_sg(hba->pcidev, sg, scsi_sg_count(sc),
>>> +                           sc->sc_data_direction);
>>
>>
>> I think you could also use scsi_dma_map instead.
>>
>> And if not I think we are supposed to be using the dma functions instead
>> of the pci ones.
>
> OK. I can use dma_map_sg() intead. But this function inturn calls
> pci_map_sg(). Is there any reason why we cannot directly call it?
>

People like abstractions. I guess we are trying to move to the dma 
functions. If you had some other bus then the dma wrappers would hide that.


>
>>
>>
>>
>>> +
>>> +static int bnx2fc_post_io_req(struct bnx2fc_rport *tgt,
>>> +                            struct bnx2fc_cmd *io_req)
>>> +{
>>
>>
>>> +
>>> +     /* Time IO req */
>>> +     bnx2fc_cmd_timer_set(io_req, BNX2FC_IO_TIMEOUT);
>>
>> Hard coding this does not seem right becuase the scsi cmnd timer can be
>> set through sysfs. It could be set lower than this which makes it
>> useless. I think libfc is dropping their similar timer like this and
>> just relying on the scsi_cmnd timer now (I think they just do the rec
>> but not the abort now).
>
> if it is a lower value, eh_abort_handler() code kicks in. Default scsi
> cmd timer is 60 secs, which may be too long to wait to sends an ABTS.


Do not work around scsi-ml and the classes. If really useful it seems 
this should be in libfc or the fc class so all drivers do the same thing 
if capable.

Also if the abort fails you still have to wait for the scsi eh to run.

And if the the scsi timer is too long why don't you just set it lower?

Also, it is 30 secs by default in the kernel, but some distro's have 
udev's that set it to 60.

  reply	other threads:[~2011-02-02  9:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-24  6:02 [v2 PATCH 4/5] bnx2fc: Broadcom FCoE Offload driver submission - part 2 Bhanu Gollapudi
2011-01-15  9:17 ` Mike Christie
2011-01-18  0:37   ` Bhanu Gollapudi
2011-02-02  9:24     ` Mike Christie [this message]
2011-02-02  9:57       ` [Open-FCoE] " Mike Christie
2011-02-03  3:42       ` Bhanu Gollapudi
2011-02-03  4:05         ` Mike Christie
2011-02-03  4:16           ` [Open-FCoE] " Mike Christie
2011-02-03  4:47           ` Mike Christie
2011-02-03  7:04             ` Bhanu Gollapudi
2011-02-03 20:55               ` Mike Christie
2011-02-03 21:02                 ` Mike Christie
2011-02-03 21:26                 ` Mike Christie
2011-01-18  2:44 ` Mike Christie
2011-01-18  3:29   ` Bhanu Gollapudi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D4922BE.40907@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=bprakash@broadcom.com \
    --cc=devel@open-fcoe.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mchan@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox