Tue, Nov 13, 2018 at 09:19:19PM CET, michaels...@gmail.com wrote:
>Jiri,
>that seems to work.. Thanks.
>Let's upstream this patch
Done:
http://patchwork.ozlabs.org/patch/997403/
>
>Michael
>
>בתאריך יום ג׳, 13 בנוב׳ 2018 ב-12:13 מאת Jiri Pirko <j...@resnulli.us
>>:
>
>> Mon, Nov 12,
Jiri,
that seems to work.. Thanks.
Let's upstream this patch
Michael
בתאריך יום ג׳, 13 בנוב׳ 2018 ב-12:13 מאת Jiri Pirko <j...@resnulli.us
>:
> Mon, Nov 12, 2018 at 09:22:03PM CET, michaels...@gmail.com wrote:
> >Calling it from net_dev_init doesn't look clean.
> >If you will see who is
Mon, Nov 12, 2018 at 09:22:03PM CET, michaels...@gmail.com wrote:
>Calling it from net_dev_init doesn't look clean.
>If you will see who is calling 'dev_add_offload' you will find out that
>there are couple of modules that doing that except of the 8021q. so either
>all modules should add offload
Calling it from net_dev_init doesn't look clean.
If you will see who is calling 'dev_add_offload' you will find out that
there are couple of modules that doing that except of the 8021q. so either
all modules should add offload from net_dev_init or stay with the current
model where each module adds
Sun, Oct 28, 2018 at 03:03:42PM CET, michaels...@gmail.com wrote:
>Jiri,
>I am not sure it would be simple to move the add_offload to vlan_Core.c as
>the add_offload should happen once.
Just call it from net_dev_init()
>in vlan.c it's done as part of module init but in vlan_core.c we are not
Jiri,
I am not sure it would be simple to move the add_offload to vlan_Core.c as
the add_offload should happen once.
in vlan.c it's done as part of module init but in vlan_core.c we are not
initializing any model and making some logic for doing that once looks
awkward to me.
Why can't we just load
Thu, Oct 25, 2018 at 01:34:04PM CEST, michaels...@gmail.com wrote:
>I'v used ftrace to see which paths we take in the kernel.
>I remind you that the packet (in my scenario) looks like the following:
>ETH | IP | UDP | VXLAN | L2 | VLAN | IP | TCP | payload
>
>When 8021q is not loaded:
I'v used ftrace to see which paths we take in the kernel.
I remind you that the packet (in my scenario) looks like the following:
ETH | IP | UDP | VXLAN | L2 | VLAN | IP | TCP | payload
When 8021q is not loaded:
dev_gro_receive <-napi_gro_receive
inet_gro_receive <-dev_gro_receive
Wed, Oct 24, 2018 at 10:12:54PM CEST, michaels...@gmail.com wrote:
>Hi,
>I noticed that there is a performance issue when running traffic on a vlan
>interface that was created by OVS.
>If we create a bridge with a vlan interface, the 8021q module is not loaded.
>Then when packets with a 8021q tag
