On Fri, 2019-07-26 at 12:39 +0200, Davide Caratti wrote:
> On Thu, 2019-07-25 at 21:27 +0000, Saeed Mahameed wrote:
> > On Thu, 2019-07-25 at 14:25 +0200, Davide Caratti wrote:
> > > On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > > > On Wed, 2019-07-24 at 16:02 +0200, Davide Caratti wrote:
> > > > > ensure to call netdev_features_change() when the driver flips
> > > > > its
> > > > > hw_enc_features bits.
> > > > >
> > > > > Signed-off-by: Davide Caratti <dcara...@redhat.com>
> > > >
> > > > The patch is correct,
> > >
> > > hello Saeed, and thanks for looking at this!
> > >
> > > > but can you explain how did you come to this ?
> > > > did you encounter any issue with the current code ?
> > > >
> > > > I am asking just because i think the whole dynamic changing of
> > > > dev-
> > > > > hw_enc_features is redundant since mlx4 has the
> > > > > featutres_check
> > > > callback.
> > >
> > > we need it to ensure that vlan_transfer_features() updates
> > > the (new) value of hw_enc_features in the overlying vlan:
> > > otherwise,
> > > segmentation will happen anyway when skb passes from vxlan to
> > > vlan,
> > > if the
> > > vxlan is added after the vlan device has been created (see:
> > > 7dad9937e064
> > > ("net: vlan: add support for tunnel offload") ).
> > >
> >
> > but in previous patch you made sure that the vlan always sees the
> > correct hw_enc_features on driver load, we don't need to have this
> > dynamic update mechanism,
>
> ok, but the mlx4 driver flips the value of hw_enc_features when VXLAN
> tunnels are added or removed. So, assume eth0 is a Cx3-pro, and I do:
>
> # ip link add name vlan5 link eth0 type vlan id 5
> # ip link add dev vxlan6 type vxlan id 6 [...] dev vlan5
>
> the value of dev->hw_enc_features is 0 for vlan5, and as a
> consequence
> VXLAN over VLAN traffic becomes segmented by the VLAN, even if eth0,
> at
> the end of this sequence, has the "right" features bits.
>
your patch handled this issue already, no need for flipping and
updating features if features check ndo will cover the cases we don't
support.
> > features_check ndo should take care of
> > protocols we don't support.
>
> I just had a look at mlx4_en_features_check(), I see it checks if the
> packet is tunneled in VXLAN and the destination port matches the
> configured value of priv->vxlan_port (when that value is not zero).
> Now:
>
> On Wed, 2019-07-24 at 20:47 +0000, Saeed Mahameed wrote:
> > I am asking just because i think the whole dynamic changing of
> > dev-> hw_enc_features is redundant since mlx4 has the
> > featutres_check
> > callback.
>
> I read your initial proposal again. Would it be correct if I just use
> patch 1/2, where I add an assignment of
>
> dev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \
> NETIF_F_RXCSUM | \
> NETIF_F_TSO | NETIF_F_TSO6 | \
> NETIF_F_GSO_UDP_TUNNEL | \
> NETIF_F_GSO_UDP_TUNNEL_CSUM | \
> NETIF_F_GSO_PARTIAL;
>
> in mlx4_en_init_netdev(), and then remove the code that flips
> dev->hw_enc_features in mlx4_en_add_vxlan_offloads() and
> mlx4_en_del_vxlan_offloads() ?
>
yes, this is exactly what I meant.
Thanks,
Saeed.
