At S800, packets may up to 4096 bytes + headers (+ OHCI trailer) large.
This was not handled by firewire-ohci until now.
As Maxim Levitsky points out, 8k buffer segments instead of 4k ones let
us easily fix the bug that async packets with 4096 bytes payload cannot
be received. Plus, this is a quick and easy way to reduce ack-busy-*
events without having to change the ar_context_tasklet to deal with more
than two segments. (In my testing, firewire-net is still able to
saturate some controllers even with its current low transmitter queue
depth of <= 8 datagrams at default MTU of 1500 bytes. FTP over fw-net
throughput from a XIO2213A to an FW323 is only improved by about 4% by
this change, and even less in the other direction.)
Clemens Ladisch found that rather about 20k are required to converge to
optimum performance, but for now I do not dare to rely on slab
allocations larger than 8k (times two per context, for two contexts).
Better defer that to a code change for more than two RA buffer segments.
Also,
- since "firewire: ohci: avoid reallocation of AR buffers",
ar_context_add_page is only used by ar_context_init/ pci_probe and
therefore can allocate with GFP_KERNEL,
- add WARN_ON(allocation failure) as a lame way of error handling.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/ohci.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
Index: b/drivers/firewire/ohci.c
===================================================================
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -580,6 +580,8 @@ static int ohci_update_phy_reg(struct fw
return ret;
}
+#define AR_PAGE_SIZE (8*1024)
+
static void ar_context_link_page(struct ar_context *ctx,
struct ar_buffer *ab, dma_addr_t ab_bus)
{
@@ -591,9 +593,9 @@ static void ar_context_link_page(struct
DESCRIPTOR_STATUS |
DESCRIPTOR_BRANCH_ALWAYS);
offset = offsetof(struct ar_buffer, ...
