Thread (2 messages) flat view 2 messages, 2 authors, 2014-07-16

Re: [PATCH net-next] net-gre-gro: Fix a bug that breaks the forwarding path

From: Or Gerlitz <hidden>
Date: 2014-07-16 12:15:54

On Tue, Jul 15, 2014 at 11:22 PM, Jerry Chu [off-list ref] wrote:
On Tue, Jul 15, 2014 at 11:21 AM, Or Gerlitz [off-list ref] wrote:
quoted
I am not near the code now, but AFAIK, the "stack" sets it in the TX path
and the driver sets it in the RX path, any deviation you see there for this
convension except for the change introduced by this patch.
Where does the forwarding path (e.g., the case at hand) belong then?
yep, so forwarding flow is something like

HW --> driver RX --> stack RX --> some stack processing --> stack TX
--> driver TX --> HW

and this is different from a path of

application --> stack TX --> driver TX --> HW

It seems as of even before we throw in the tunneling thing, the GRO stack
which is part of that "stack RX" code I mentioned above sets the
gso_type of SKBs
for the sake of forwarding  so these things already happen.
AFAICT the current dev_hard_start_xmit() code pretty much requires
skb->encapsulation to be set on all tunneled pkts in order for the proper
TX offload to be possible.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help