how to lock TX DMA buffer in RAM ?

how to lock TX DMA buffer in RAM ?

Post by Mark Galec » Sat, 20 Oct 2001 11:04:48



Hello,

there was a thread a while ago (by Robert Keiser), about how a driver
is supposed to lock pages in RAM, with no definite solution.  I have a
similar problem:

I am working on a network driver, which receives data buffers to be
transmitted (the buffers are in a struct sk_buff) by a DMA network
card.

When a buffer arrives, I have to do two things which I don't know how
to do:
1.  Before I tell the device what to DMA from, I have to lock the
buffer in RAM.
2.  I have to keep it in RAM until the device reports it is done.  

(Of course I could copy the buffer to a driver allocated resident
buffer, but for a Gigabit driver, this is a waste of time).

So, is there really no easy way to do this??  

Other OS's I worked on have a driver-accessible system call to do this
kind of thing, and it seems it is indispensible.

----------------------
Or, is it guaranteed that sk_buff data buffer will be resident in RAM
from the time it is given to the driver, to the time the driver
releases the sk_buff?

If you look at the current Intel Gigabit e1000 driver, present in
Linux source, this driver does not even care about that:  it just
assumes the buffer is locked.  Either it is faulty, it is really
guaranteed to be locked.  Which is the case?

Thank you,

Mark Galecki

 
 
 

how to lock TX DMA buffer in RAM ?

Post by Pete Zaitc » Sat, 20 Oct 2001 14:14:41


Quote:> Or, is it guaranteed that sk_buff data buffer will be resident in RAM
> from the time it is given to the driver, to the time the driver
> releases the sk_buff?

It is guaranteed to be resident and in DMA-able memory, period.
However, you have to do your own pci_map_single()/pci_unmap_single()
upon the skb that you got from alloc_skb() (actually, better do
pci_map_sg(), if your board supports it).

Quote:> If you look at the current Intel Gigabit e1000 driver, present in
> Linux source, this driver does not even care about that:  it just
> assumes the buffer is locked.  Either it is faulty, it is really
> guaranteed to be locked.  Which is the case?

The e1000 is not a very good driver, because it is poorly written.
First of all, Intel does not give a rat's ass about portability,
because their task is to sell Intel CPUs (this is changing with
introduction of Itanic, but...). There are other problems, that
I might be able to enumerate in a fit of mental brightness.
We have to put up with e1000 mostly because there is no documentation
about the chipset.

I suggest you looked at sunhme.c. It is not a gigabit driver,
so it does not know a lot about interrupt mitigation, for instance.
But it is a very good starting point. Once you grokked sunhme.c,
move on to acenic.c.

-- Pete

 
 
 

how to lock TX DMA buffer in RAM ?

Post by Mark Galec » Sun, 21 Oct 2001 06:03:12



> It is guaranteed to be resident and in DMA-able memory, period.

I grepped the source and doc and I see that sk_buff data is allocated
with kmalloc and then it seems implied (but I have not seen it stated
explicitly) in a few places that kmalloc returns kernel memory and:

 kernel memory is not swappable.  

Is this obvious?  (There are other OS's where you can allocate memory
from kernel, that is swappable, so it is not obvious from an
OS-theoretic standpoint).

Quote:> The e1000 is not a very good driver, because it is poorly written.
>  We have to put up with e1000 mostly because there is no documentation
> about the chipset.

Soon you won't have to :)  I am actually upgrading this driver!  The
story is:
my company, SBS, makes Gig cards and we have access to confidential
Intel docs on the chip.  To support our cards, a while ago (in fact,
about a year ago) I looked at the Intel e1000 driver.  I realized it
was bad (1.  ugly, and 2.  inefficient) and started rewriting it so it
was pretty and the TX routine and ISR (RX) was as efficient as I could
make them.
I then got swapped to other projects, while the rewrite was in beta,
and now I am back at it on my own time, because I think it would be a
good idea to contribute it to the Linux community.
In the meantime, Intel upgraded their driver, so that it is not ugly
anymore, and supports our cards, so we don't need my rewrite anymore,
but is still, IMHO, not as efficient as could be.  However, it has a
bunch of new features.

So wwhat I am doing, is:  I took the current driver 3.1.23 from Intel
Web site and I am merging it with my TX and ISR routines.  I don't
have much time to devote to that, as this is after-work and I don't
really do programming outside work.  But some time in the future I
will submit this to whoever the maintainer is, I guess, Alan Cox.

Now, here is a question:  I looked at the most current kernel source,
2.4.12, and there seems to be no e1000 driver there at all??  Why??

Mark Galecki

 
 
 

1. Modem TX and RX status via Num Lock-Caps Lock-Scroll Lock

'Netters,

A time ago someone asked about implementing their Num Lock, Caps Lock,
and Scroll Lock keyboard lights as a modem transmit and receive status
indicator.  

Has anyone accomplished this?  If so, is the code at an archive site?

-Rod
--
-----------
If you yell try : Rod Troch                  | Zeta Beta Tau

Pgp key available upon request.              | happyHappy joyJoy
         Don't mess with TEXAS. (Lonestar - A Linux box)

2. Need specs for documentless KLH MN170 monitor

3. DMA-Support on TX "Pro" boards (ALi Chipset...)

4. 2.5.70: some power management changes

5. Intel TX chipset drivers for ULTRA DMA/33

6. Commercial X Server Web page?

7. ERROR: "eth0: Tx Ring full, refusing to send buffer"

8. demand dial from lan WS

9. urgent: tx buffer allocation failed, Orinoco WaveLAN woes

10. PROBLEM: nfs & "Warning - running *really* short on DMA buffers"

11. if over 64 megs of ram on Intel TX chipset..

12. SCSI error : Running low on SCSI DMA buffers

13. DMA buffering below 1MB?