Simplify handling of fragments in net_buf

[carlescufi]

Today, fragment support in net_buf uses the frags pointer which is unioned with the node one to save 4 bytes (in a structure of 24 bytes without the optimization).

zephyr/include/zephyr/net/buf.h

Lines 915 to 921 in 1217d85

	union {
	/** Allow placing the buffer into sys_slist_t */
	sys_snode_t node;
	/** Fragments associated with this buffer. */
	struct net_buf *frags;
	};

This forces the net_buf code to provide special net_buf_get and net_buf_put functions instead of being able to call k_fifo_get and k_fifo_put directly:

zephyr/subsys/net/buf.c

Lines 508 to 520 in 1217d85

	void net_buf_put(struct k_fifo *fifo, struct net_buf *buf)
	{
	struct net_buf *tail;
	__ASSERT_NO_MSG(fifo);
	__ASSERT_NO_MSG(buf);
	for (tail = buf; tail->frags; tail = tail->frags) {
	tail->flags |= NET_BUF_FRAGS;
	}
	k_fifo_put_list(fifo, buf, tail);
	}

zephyr/subsys/net/buf.c

Lines 412 to 439 in 1217d85

	struct net_buf *net_buf_get(struct k_fifo *fifo, k_timeout_t timeout)
	#endif
	{
	struct net_buf *buf, *frag;
	NET_BUF_DBG("%s():%d: fifo %p", func, line, fifo);
	buf = k_fifo_get(fifo, timeout);
	if (!buf) {
	return NULL;
	}
	NET_BUF_DBG("%s():%d: buf %p fifo %p", func, line, buf, fifo);
	/* Get any fragments belonging to this buffer */
	for (frag = buf; (frag->flags & NET_BUF_FRAGS); frag = frag->frags) {
	frag->frags = k_fifo_get(fifo, K_NO_WAIT);
	__ASSERT_NO_MSG(frag->frags);
	/* The fragments flag is only for FIFO-internal usage */
	frag->flags &= ~NET_BUF_FRAGS;
	}
	/* Mark the end of the fragment list */
	frag->frags = NULL;
	return buf;
	}

This implies that net_buf_get is not atomic when using fragments (although net_buf_put is) which is a problem. It also forces the net_buf layer to duplicate existing k_fifo/lifo APIs due to this behavior. This is because today all fragments are actually placed in the fifo, instead of just the "head" one.

This issue suggests reverting this optimization:

struct net_buf {

		/** Allow placing the buffer into sys_slist_t */
		sys_snode_t node;

		/** Fragments associated with this buffer. */
		struct net_buf *frags;
...

to simplify the code, increase execution speed at the cost of 4 bytes per net_buf.

Important note: this would not constitute an API change, because none of the public APIs would have to be modified at all.

[jfischer-no]

                            .....                           
                          ......'..                         
                         .,.......''                        
                         .,........''                       
                         .,'........,.                      
                          ''........',                      
                          .,........';.                     
                          .,........':.                     
                           '........':.                     
                           '.......';;                      
                          .'.......';'                      
                         .'........';.                      
                        .''........',                       
                        ''.........',.                      
                       ''..........','                      
                     .''............',,'..                  
                   .,,...............,,,,,,'...........     
                  .,'..............',,,''............'''    
      .'''.......''...............',''''...............''   
     .''.......''................';''''''..............';   
    .............................,:,''''''...........'';;   
    ............................';lc;;,,,,'''''''',,;::;.   
   ............................',;lddollccc:::::cclodd:.    
   ...........................'',;cloc::::;;;;;;:::;;,,,.   
   ...........................'',,:c;,''''.............',.  
   ..........................''',,::,,,,,''...........',:.  
   ..........................''',,:c;,,,,,''......'''',;:.  
   ...........................'',,;ll::::;;,,,,,,,,,,;;:.   
   ...........................'',,,:oollllllllllllcclc,.    
   ...........................''',,:c;;,;,,,''''''''',,.    
   .............'..............''',:;,,,,,'..........','    
   .......''''',,,''''''''.....''',:;,,,,,''........'',,    
    .'''''',,,,;:cc;,,,''''''''''',cc:;;;;,''''''''',;:.    
    .'',,;;;;::ccodoc;,,,,,,'''''',:odolcc:;;;;;;;:::;.     
     .,;:ccloodddddoccc:;,,,,,,,,,;:lollllllllllloo;.       
       ':oool:;'..   .,lcc:;;;;;;;;:c;,,,,''''''',;;.       
         .             .;lollccccc:cc:;,,,''.''''',;.       
                          .';clodddddl::;;,,,,,,;:c;        
                                ....'.';:::cccccc;'         
                                         .',,,,..   

[carlescufi]

@jfischer-no thanks, I guess that means this would be welcome for USB
@jhedberg @jori-nordic any objections for Bluetooth?
@rlubos @jukkar would you OK this for networking?

[rlubos]

Well, it comes at a cost (networking subsystem RAM consumption increases by 128 bytes only in the default configuration, usually more though as the default buffer count is rather small), but if the processing speed can benefit from this change, I guess we can live with it.

[carlescufi]

Well, it comes at a cost (networking subsystem RAM consumption increases by 128 bytes only in the default configuration, usually more though as the default buffer count is rather small), but if the processing speed can benefit from this change, I guess we can live with it.

Yes, but I don't see how we can maintain the current RAM footprint if we want to achieve atomicity in fragments, aside from reducing complexity.

[jukkar]

This proposal LGTM.

[jhedberg]

@jhedberg @jori-nordic any objections for Bluetooth?

I'm ok with it

[jori-nordic]

okay too