<div dir="ltr">So, wrong list for this, but since the conversation has evolved best here, would having gro on along with the other bits in these two threads also be beneficial? We are looking to consolidate suricata and bro into one system on low bandwidth environments, and having compatible ethtool settings would be nice. Currently gro is explicitly turned off in our Bro deployment, but turned on (now) in our Suri deployment...</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 26, 2017 at 11:44 PM, Michał Purzyński <span dir="ltr"><<a href="mailto:michalpurzynski1@gmail.com" target="_blank">michalpurzynski1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Let's face the GRO!! Those endless nights spent on reading ixgbe source, e40i source, Linux networking stack code while doing perf tracing in another window ;)<div><br></div><div>LRO = card's CPU merges 'everything in sight' based on some very relaxed rules before card pushes data to DMA area. Deprecated as it was harmful, for example it had to be disabled for bridging. Rules 'what can be merged' were too relaxed.</div><div><br></div><div>GRO is done by the kernel. </div><div><br></div><div>SoftNet starts with net_rx_action() - which in turn calls the (registered by the driver on initialization) card-specific polling routine, which will be used to move packets from the 'DMA area' to 'consumers' such as taps code (like AF_Packet), IP and the like.</div><div><br></div><div>ixgbe_poll() is our example hero. And it calls...</div><div><br></div><div>ixgbe_clean_rx_irq() - which constructs the skb (a socket buffer structure) and calls...</div><div><br></div><div>napi_gro_receive() - even if you have GRO disabled ;) This function handles both cases and the name is tricky. And it passes the packet up the network stack to 'taps' / IP and what not. And it calls...</div><div><br></div><div>dev_gro_receive() - also for cases when GRO is disabled. It is dev_gro_receive responsibility to check if GRO is enabled.</div><div><br></div><div>If it is - the upper layer (protocol layer) is consulted "is this packet part of an already being-offloaded flow?". That's cool because say, TCP can decide to have ACK merged with another packet or not merged. And that's how it's different from LRO (in hardware) - the protocol layer can decide.</div><div>Once again - you can consult upper layers what gets merged, and TCP knows better, because it has access to the current TCP-state-machine. If you want to have it done in hardware, you would have to implement TCP in hardware. With 'just taps' it is simpler but at least those rules are more strict than a pure LRO 'I WILL merge because I can. What? Everythyyyyying!!'</div><div><br></div><div>Finally the protocol layer tells the dev_gro_receive 'yo, give me all my packets' and a giant packet is "pulled" from the DMA-area up the stack (without copying anything, usually it's a pointer magic unless it's not).</div><div><br></div><div><br></div><div>Why is it faster with GRO than without it? We are saving lots of function calls done per packet and just fetch entire NN kB from the DMA-area.</div><div><br></div><div>An important point to remember - it is NOT about the bandwidth, it is all about the latency. Calling each function takes nn nanoseconds and there are only that many nanoseconds you have before next packet overwrites your data.</div><div><br></div><div><br></div><div>I promise to be more active for next questions.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 26, 2017 at 12:14 PM, Cooper F. Nelson <span dir="ltr"><<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just checked and using the 'rx-all: on' shorthand results in LRO being<br>
turning off and GRO/GSO on:<br>
<br>
> generic-segmentation-offload: on<br>
> generic-receive-offload: on<br>
> large-receive-offload: off<br>
<br>
-Coop<br>
<span class="m_2750450564170422953im m_2750450564170422953HOEnZb"><br>
On 1/26/2017 12:07 PM, Marcus Eagan wrote:<br>
> Just saw LRO and wanted to remark for the record that I had a ton of<br>
> problems with af_packet because of cheap Realtek NICs. I've heard they have<br>
> improved but I have since moved on.<br>
><br>
> Marcus<br>
<br>
<br>
</span><div class="m_2750450564170422953HOEnZb"><div class="m_2750450564170422953h5">--<br>
Cooper Nelson<br>
Network Security Analyst<br>
UCSD ITS Security Team<br>
<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a> x41042<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>