Attached is the patch for implementing 2-buffer mode on Rx path. More description of this mode of operation follows. On certain systems when a DMA has to happen on an un-aligned memory location perf
no objections but two comments: 1) can this not be done with SKB fragments? 2) the following code needlessly uses GFP_ATOMIC: + ba = &nic->ba[i][j][k]; + + ba->ba_0_org = (void *) kmalloc + (BUF0_LEN
To acheve what is required, the H/W still has to split the Rx'ed frame into 2 parts. By implementing this through the SKB fragments method, the only thing we avoid is usage of ba_0 and ba_1 fields,
This change would pass skbs from the driver without the MAC header? What happens in a bridging configuration? And dev->hard_header_parse is set to eth_header_parse, which expects skb->mac.ethernet to
Hi Chris, I think you have a point. As an alternative I can allocate some extra buffer space for buffer 2 (Ethernet payload) to begin with and in Rx path copy the buffer 1(Ethernet header) to the sta
"fragmented SKB on Rx" is an old problem - we tried to deploy 2 and 5 buffer Xframe modes before and it did not work in Linux. Is anyone aware of any network driver that successfully uses fragmented
Leonid Grossman wrote: "fragmented SKB on Rx" is an old problem - we tried to deploy 2 and 5 buffer Xframe modes before and it did not work in Linux. Is anyone aware of any network driver that succes
iirc it was originally implemented for HIPPI because the MM system had some problems with allocating 64K linear buffers reliably. But I'm not sure anybody still uses the HIPPI driver so it may have b
In this submission I'll use copy for 2Buff mode, but continue to debug the fragmented skb Rx. If we do get it working sometime, I'll submit another patch to update the driver. Is this Ok? - Koushik
Hi, Attached is the patch for implementing 2-buffer mode on Rx path. More description of this mode of operation follows. On certain systems when a DMA has to happen on an un-aligned memory location p
no objections but two comments: 1) can this not be done with SKB fragments? 2) the following code needlessly uses GFP_ATOMIC: + ba = &nic->ba[i][j][k]; + + ba->ba_0_org = (void *) kmalloc + (BUF0_LEN
To acheve what is required, the H/W still has to split the Rx'ed frame into 2 parts. By implementing this through the SKB fragments method, the only thing we avoid is usage of ba_0 and ba_1 fields,
This change would pass skbs from the driver without the MAC header? What happens in a bridging configuration? And dev->hard_header_parse is set to eth_header_parse, which expects skb->mac.ethernet to
Hi Chris, I think you have a point. As an alternative I can allocate some extra buffer space for buffer 2 (Ethernet payload) to begin with and in Rx path copy the buffer 1(Ethernet header) to the sta
"fragmented SKB on Rx" is an old problem - we tried to deploy 2 and 5 buffer Xframe modes before and it did not work in Linux. Is anyone aware of any network driver that successfully uses fragmented
Leonid Grossman wrote: "fragmented SKB on Rx" is an old problem - we tried to deploy 2 and 5 buffer Xframe modes before and it did not work in Linux. Is anyone aware of any network driver that succes
iirc it was originally implemented for HIPPI because the MM system had some problems with allocating 64K linear buffers reliably. But I'm not sure anybody still uses the HIPPI driver so it may have b