Date: Sun, 21 Mar 1999 19:05:33 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: winter@jurai.net (Matthew N. Dodd) Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. Message-ID: <199903220205.TAA63565@panzer.plutotech.com> In-Reply-To: <Pine.BSF.4.02.9903211958130.2158-100000@sasami.jurai.net> from "Matthew N. Dodd" at "Mar 21, 1999 8:12:33 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew N. Dodd wrote... > Humm... > > Let me tell you what I'm trying to do and how I think I need to go about > doing it and you guys can tell me if I've got an incomplete understanding > of how things work. (simple port... not!) > > Sending a packet: > > The network layer calls ifp->if_start, which in my case is a > routeine called 'se_if_start'. > > se_if_start() loops on IF_DEQUEUE() if the interface is currently > up and not already IFF_OACTIVE. > > For each packet I aggregate the data into an linear tx buffer if > it setup a ether_send CCB and somehow schedule it to be run (its > not important that it be run 'now') This is the bit I'm fuzzy on. > I can hang the aggregated buffers (1 per packet) off of a softc > queue and xpt_schedule() myself and setup the CCBs in my > se_cam_start() routine, issuing xpt_schedule()'s until there are > not more tx buffers in the queue. That sounds reasonable, I suppose. I guess you should call xpt_schedule() once for each transaction you need to send. > Once the scsi ether_send CCBs complete I can free the tx buffers > (having alread freed the mbufs the system passed the packetes to > me in se_if_start()) or I can add them back to the queue and > reschedule a transmit if the command failed. I'll show my ignorance about network drivers here... It looks/sounds like you can get multiple packets per invocation of se_if_start(). Each packet consists of one or more mbufs. You then cram the mbufs into one big buffer, that you have allocated, per packet. I think it might be better to wait until you have a CCB to send the buffer in before freeing the mbufs. It seems like it might be fairly easy for the system to queue lots of packets to the interface, and for you to fall behind in sending them. You may want to queue the *mbufs*, then schedule yourself for a CCB. In your CAM start() routine, you can grab one of your TX buffer(s), copy the data in, setup the CCB and xpt_action() the CCB. Does this thing support tagged queueing? You didn't include the transfer negotiation line in the dmesg output in your previous message. If it doesn't support tagged queueing, it will make things much easier, since you'll only have to have one transmit buffer to copy things into. (You'll only be able to have one oustanding transaction at a time.) I suppose this is a unique device, since you need driver-local storage space to put transactions in. > I'll talk about the receive routine once I've got a good understanding of > the flow of the TX routines. I'm curious to hear about the receive end of things. Unless this thing can act as an initiator as well as a target (and your HBA can do both as well), you'll have to be polling for incoming packets one way or another. > Thanks for the patience. The learning curve on CAM isn't as bad as I > thought but its still not cake either. Yeah, it isn't too bad. It'll eventually all make sense, you just have to understand what the various functions do. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903220205.TAA63565>