[Top] [All Lists]

Re: Q: (ab)using zerocopy for drivers with alignment contraints

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: Q: (ab)using zerocopy for drivers with alignment contraints
From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
Date: Mon, 11 Jun 2001 18:46:57 +0200
Cc: netdev@xxxxxxxxxxx
References: <> <>
Sender: owner-netdev@xxxxxxxxxxx
"David S. Miller" wrote:
> Manfred Spraul writes:
>  > Several cheap busmaster nics only accept tx buffers that are 32-bit
>  > aligned.
> I'm going to assume that it is safe to bet that such cards cannot take
> multiple buffers for a TX packet too.
> Because if they could, then we could do something like copy the header
> forward a few bytes to get it aligned, and set up two buffer pointers
> into the packet such that the 32-bit alignment requirement is met.
> There'd be some difficulty with SKB sharing...
> BTW, a routine exists already doing what you propose, only to user
> space.  Make skb_copy_datagram{,_iovec}_kernel(), export these
> routines to modules, and I'd be more than happy to accept that patch.
skb_copy_datagram & friends follow the fragment list. My function
doesn't/mustn't follow skb_shinfo(skb)->frag_list. Should I still call
it skb_copy_datagram{,_iovec}_kernel? I don't like functions with
similar names and subtile differences.
What about

int skb_dblbuf_copy(void *buf, const struct sk_buff *skb, unsigned long
* return value: 1 -> skb copied.
*     0 -> copy unnecessary, data accessible with skb->data
* addr_mask: bitmask with the required alignment mask.


<Prev in Thread] Current Thread [Next in Thread>