I am trying to get a Mylex lne390 run on my alpha. It receives well, but the
card allows only 32-bit accesses to its shadow-ram and I have problems sending
packages. The method memcopy_toio will do such accesses, but only if the copied
buffer is aligned on 32-bit boundaries.
My problem is now, that the "block_output" method of the netdevice-drivers get
often a buffer address that is aligned on a 16-bit boundary.
At the moment I am trying to fix the most important protocol-entities of the
tcp/ip-stack (arp and ip run, now I am messing with icmp) so that they produce
skb->data aligned on 16-byte boundaries ...
However, would it be possible in future terms to establish an
alignment-standard for the skb->data pointer before it is handed to the
block_output method? It would not only make my Mylex run, but an aligned
buffer would also increase the performance of the block_output since it enables
the driver to use 32-bit or even 64-bit accesses when copying the data to the
shadowram.
And then there are some lines in arp.c and ip_output.c that I donīt understand:
arp.c line 449:
skb_reserve(skb, (dev->hard_header_len+15)&~15);
^^^^^^^
ip_output.c line 627:
int hh_len = (rt->u.dst.dev->hard_header_len + 15)&~15;
^^^^^^^
Does the operation at the and ensure a 16-byte alignment? I have removed them
on my Alpha and that made arp and ip run on my Mylex. In fact this additions
were responsible for consequential misalignment. The buffer moved forward to an
aligned address, but skb_push calls after the reservation destroyed the
alignment and produced the 16-bit bouandaries.
Of course it is not easy to hold skb->data aligned, but it may be worth it ...
Carsten
----------------------------------
E-Mail: Carsten Jacobi <carsten@jakes.kawo1.rwth-aachen.de>
Date: 30-Jul-98
Time: 30-Jul-9
This message was sent by XFMail
----------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html