On Tue, Jan 5, 2021 at 1:21 PM Greg KH <greg@xxxxxxxxx> wrote: > > On Tue, Jan 05, 2021 at 12:37:38PM -0500, Christopher Friedt wrote: > > Hi Alex & all. > > The fact that gbridge uses a separate socket per CPort (although kind > > of nice conceptually) does have a non-negligable impact on > > memory-constrained devices though. > > In what way? Is this because a socket has a lot of memory state needed, > or is this some other greybus overhead? Nothing to do with Greybus. I'm pulling numbers out of thin air here, but in Zephyr, each TCP service consumes * >= 2 POSIX fd's (and entries in the fd table) * >= 2 TCP contexts * >= some minimal number of network buffers (each consuming some size) Most of those are statically allocated (configured via Kconfig), but they do add up. I don't have a specific number of bytes for each of these. The real gotcha is in the TLS contexts. So for each TLS service, there are * additional fd's (2 iirc, but don't quote me on it) * 2 buffers of >= 512 bytes (one for each of TX, RX) **per socket** * 1 buffer for the client cert (if mutual auth is used) **per socket** * 1 buffer for the ca cert (if mutual auth is used) **per socket** RSA key minimum safe-ish size is 2k, so those numbers do add up on a tiny device with e.g. 64k of SRAM, especially when considering that most Greybus handlers are threaded (I think the default thread size is 1k). > > At this point, my Greybus for Zephyr module is alpha ready. It works > > over UART, but also any other transport that supports TCP/IP such as > > Ethernet, WiFi, BLE, 802.15.4 (both 2.4 GHz and Sub GHz), CAN > > (although that's untested). Still lots of work to be done (like > > support for different Greybus protocols), but it's quite usable for > > GPIO, I2C, and SPI now ;-) > > Any Linux kernel-side changes needed for any of this? So far, none. The only caveat to that is, that to automagically probe the Linux driver for a number of SPI or I2C devices, some platform data is required. Vaishnav Ma is working on that atm (for microbus) and he's pretty far along now. The same ideas could be reused for different form factors such as Feather, etc, so there is some overlap. > I am interested in getting the remaining greybus code out of staging > this year, as there's no good reason for it to be hanging around with no > real development happening. If there's anything left to be done on the > Linux portion, that would be good to know, otherwise I think we'll just > start moving indivdual drivers out of staging slowly... I can appreciate that. Nothing that I've seen in upstream has seemed to cause any issues that I've encountered at this point. I believe that gb_netlink and gbridge require some work to be done in terms of graceful shutdown, error, and connection handling, as there are occasionally panics, but (from my experience) those are most likely due to issues in gb_netlink or gbridge and not the upstream kernel code. For example, https://github.com/anobli/gbridge/blob/master/controllers/tcpip.c#L207 Also, the simple fact that the gbridge process does not require root privileges is (a bit) concerning. The gb_netlink module should probably be modified to check the permissions of the process sending it data, maybe some userspace greybus user / group should be created, etc. C _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|