Re: [RFC] Bluetooth: Provide L2CAP ops callback for memcpy_fromiovec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jukka,

>> so this patch is just the groundwork to deal with the socket vs kernel internal handling of TX path. And this patch should most likely also be split into providing the default for alloc_skb and then adding memcpy_fromiovec.
> 
> Earlier in 6lowpan coc patches, you suggested that we would not use
> msghdr for kernel internal data because of extra memory copy that is
> needed in 6lowpan side. Is that suggestion now reverted?

you can allocate msghdr and iovec on the stack and just have it point to a single buffer you have your message in. The msghdr will be modified by the underlying default implementation, but besides having to allocate the message itself you do not have an extra allocation. Look at how A2MP does it.

In the future steps we should look into how we can take a SKB with the existing message and clone or copy it efficiently so it will split over multiple ACL fragments.

As I mentioned before, I never realized how well optimized our L2CAP is to deal with iovec structs from userspace. It never occurred to me that kernel internal TX path is non existent and that A2MP is actually buggy.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux