Date: Mon, 22 Mar 1999 01:18:22 -0500 (EST) From: "Matthew N. Dodd" <winter@jurai.net> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG Subject: Re: CAM entry point for SCSI-to-Ethernet device. Message-ID: <Pine.BSF.4.02.9903220036430.2158-100000@sasami.jurai.net> In-Reply-To: <199903220205.TAA63565@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Mar 1999, Kenneth D. Merry wrote: > That sounds reasonable, I suppose. I guess you should call xpt_schedule() > once for each transaction you need to send. After reading the rest of this post I need to xpt_schedule() in my if_start() and then in my cam_done() routine, since I shouldn't bother trying to setup multiple CCBs as they must be executed serialy. Is there any way of handing the CAM subsystem a list of CCBs to be executed or adding a CCB to the queue of runable CCBs? I'd like to submit CCBs to the queue, xpt_schedule() then pull the next available CCB to be executed, clean up after it in se_cam_done() and call xpt_schedule() again if there are still runable CCBs in the queue. > > 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. That really depends on how much work I want to do at splnet() vs. splbio(). My thought was to de-queue and process the mbufs and return them to the system since I'll be able to allocate a buffer of the correct size for each packet. Its unfortunate that I can't get CAM to do a scatter/gather type thing and pass it a descriptor list that describes the location and length of each mbuf data element. Regardless, all I need do in se_cam_start() is setup the command (which involves calling cam_fill_csio() and call xpt_action() and I'm done with the packet. > 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. I was planning on malloc()'ing them on the fly since I'll know how long they need to be. > 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.) This is a fairly stupid device. No tagged queueing. > I suppose this is a unique device, since you need driver-local storage > space to put transactions in. Indeed. The NetBSD driver has one big horking buffer it doesn't free which I'm beginning to see the sense of. > > 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. Heh. Polling. The device has space for 10 packets of 1500 bytes each, but only 10 packets (regardless of size will be buffered) It will start dropping packets if the system can't keep up (poll and issue ether_recv commands fast enough). I've got a few ideas on how to implement this polling behavior but I'm afraid I can't convey them coherntly enough at this hour. Some manner of adaptive polling rate that takes into account # of packets returned by each ether_recv command, and the size of the packets. I'm not sure how I'm going to calculate overhead and interrupt latency but something will come to me or I'll settle for a gross hack or something. After all, this device really isn't all that pretty and is only serving as a diversion from working on Other Things. (eventually I have to get off my ass and resurrect my token ring test box and figure out my problems with the TMS380 driver.) > > 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. But I never wanted to be a SCSI hacker! I just want to... to... -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | 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?Pine.BSF.4.02.9903220036430.2158-100000>