Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/9/2020 7:32 AM, Lev Serebryakov wrote:
> On 07.11.2020 2:46, Eric Joyner wrote:
>
>> The other issue is that I still don't know which devices need a
>> restart / which devices do not, or whether a restart is strictly
>> necessary and if there is another way to do this without worrying
>> about restarting the device.
> Could this be copied from pre-iflib driver? It did right things
> without unneeded resets, including some `em` chips.
>
> BTW, I'm surprised, that pre-iflib drivers still available on Intel
> site and in ports. And sometimes works better :-(
>
For my specific case (no DHCLIENT and I210 chipset), I just used
--- if_em.c 2020-09-26 07:46:16.474942000 -0400
+++ /tmp/if_em.c 2020-11-09 08:13:55.888378000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And that seems to work for my particular chipset and use case.
---Mike
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 07.11.2020 2:46, Eric Joyner wrote: The other issue is that I still don't know which devices need a restart / which devices do not, or whether a restart is strictly necessary and if there is another way to do this without worrying about restarting the device. Could this be copied from pre-iflib driver? It did right things without unneeded resets, including some `em` chips. BTW, I'm surprised, that pre-iflib drivers still available on Intel site and in ports. And sometimes works better :-( -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
Ah -- I didn't implement the fix I had in that bugzilla correctly -- em and
igb devices will use the same function instead of using two different ones
even though it seems em devices generally require the interface restart yet
igb devices do not.
The other issue is that I still don't know which devices need a restart /
which devices do not, or whether a restart is strictly necessary and if
there is another way to do this without worrying about restarting the
device.
- Eric
On Fri, Nov 6, 2020 at 3:35 PM mike tancsa wrote:
> On 11/6/2020 5:32 PM, Eric Joyner wrote:
> > Could you reply to that issue with what you've found?
> >
> > Though, as far as I can recall, igb(4) devices are not supposed to do
> > the iflib reset talked about in the bug, so I wouldn't expect to see a
> > link flap on those.
> >
> Hi Eric,
>
> I have added my findings to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
> I tried it on 3 different vendor's boards. All I210 variants it seems.
>
> I am testing with
>
> --- if_em.c 2020-11-06 15:00:22.120953000 -0500
> +++ /tmp/if_em.c2020-11-06 14:59:55.678195000 -0500
> @@ -4047,6 +4047,7 @@
> {
> switch (event) {
> case IFLIB_RESTART_VLAN_CONFIG:
> + return (false);
> default:
> return (true);
> }
>
> And if fixes the problem, but not quite sure if it introduces any
> regressions or other issues ?
>
> ---Mike
>
>
> > - Eric
> >
> > On Fri, Nov 6, 2020 at 12:48 PM mike tancsa > > wrote:
> >
> > On 11/6/2020 2:17 PM, mike tancsa wrote:
> > > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> > >> Hello Ian,
> > >>
> > >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> > >>
> > >>> I noticed that my VLAN interfaces stopped working after a
> > recent build.
> > >>> tcpdump showed traffic leaving leaving and entering the
> > interface but no
> > >>> host on the network actually received any packets from this
> > host. A
> > >>> binary search led me to r360902 and indeed the following
> > change fixed
> > >>> the issue for me:
> > >> Problem is, this change will return terrible situation when
> > adding new VLAN
> > >> will flap connection status.
> > >>
> > >> It all worked before iflib: hardware VLAN filtering worked, and
> > >> adding/removing new VLAN didn't cause link to flap.
> > >>
> > >> Now, with iflib, looks like we can not have all good things at
> > once :(
> >
> >
> > Looks like this is captured in
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
> >
> >
> >
> > > Hi All,
> > >
> > > Just came across this thread as I am running into this behaviour on
> > > RELENG_12. Adding a new vlan causes all vlans on the parent
> > interface
> > > to flap. Not the greatest thing as it bounces a LOT of traffic
> > > potentially, flaps routing etc. Is there a way around this ?
> > >
> > > This is on r367411 releng12
> > >
> > > igb0@pci0:2:0:0:class=0x02 card=0x153315d9
> > chip=0x15338086
> > > rev=0x03 hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'I210 Gigabit Network Connection'
> > > class = network
> > > subclass = ethernet
> > >
> > > eg. just something simple like
> > >
> > > ifconfig vlan16 create 10.1.2.3/29 vlandev
> > igb1 vlan 16
> > >
> > > # dmesg | tail -8
> > > igb1: link state changed to DOWN
> > > vlan16: link state changed to DOWN
> > > vlan2049: link state changed to DOWN
> > > vlan15: link state changed to DOWN
> > > igb1: link state changed to UP
> > > vlan16: link state changed to UP
> > > vlan2049: link state changed to UP
> > > vlan15: link state changed to UP
> > >
> > >
> > > ---Mike
> > >
> > >
> > >
> > >
> > > ___
> > > freebsd-current@freebsd.org
> > mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >
> > > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org
> > "
> > >
> > ___
> > freebsd-current@freebsd.org
> > mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org
> > "
> >
>
___
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 5:32 PM, Eric Joyner wrote:
> Could you reply to that issue with what you've found?
>
> Though, as far as I can recall, igb(4) devices are not supposed to do
> the iflib reset talked about in the bug, so I wouldn't expect to see a
> link flap on those.
>
Hi Eric,
I have added my findings to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
I tried it on 3 different vendor's boards. All I210 variants it seems.
I am testing with
--- if_em.c 2020-11-06 15:00:22.120953000 -0500
+++ /tmp/if_em.c 2020-11-06 14:59:55.678195000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And if fixes the problem, but not quite sure if it introduces any
regressions or other issues ?
---Mike
> - Eric
>
> On Fri, Nov 6, 2020 at 12:48 PM mike tancsa > wrote:
>
> On 11/6/2020 2:17 PM, mike tancsa wrote:
> > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> >> Hello Ian,
> >>
> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> >>
> >>> I noticed that my VLAN interfaces stopped working after a
> recent build.
> >>> tcpdump showed traffic leaving leaving and entering the
> interface but no
> >>> host on the network actually received any packets from this
> host. A
> >>> binary search led me to r360902 and indeed the following
> change fixed
> >>> the issue for me:
> >> Problem is, this change will return terrible situation when
> adding new VLAN
> >> will flap connection status.
> >>
> >> It all worked before iflib: hardware VLAN filtering worked, and
> >> adding/removing new VLAN didn't cause link to flap.
> >>
> >> Now, with iflib, looks like we can not have all good things at
> once :(
>
>
> Looks like this is captured in
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
>
>
> > Hi All,
> >
> > Just came across this thread as I am running into this behaviour on
> > RELENG_12. Adding a new vlan causes all vlans on the parent
> interface
> > to flap. Not the greatest thing as it bounces a LOT of traffic
> > potentially, flaps routing etc. Is there a way around this ?
> >
> > This is on r367411 releng12
> >
> > igb0@pci0:2:0:0: class=0x02 card=0x153315d9
> chip=0x15338086
> > rev=0x03 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'I210 Gigabit Network Connection'
> > class = network
> > subclass = ethernet
> >
> > eg. just something simple like
> >
> > ifconfig vlan16 create 10.1.2.3/29 vlandev
> igb1 vlan 16
> >
> > # dmesg | tail -8
> > igb1: link state changed to DOWN
> > vlan16: link state changed to DOWN
> > vlan2049: link state changed to DOWN
> > vlan15: link state changed to DOWN
> > igb1: link state changed to UP
> > vlan16: link state changed to UP
> > vlan2049: link state changed to UP
> > vlan15: link state changed to UP
> >
> >
> > ---Mike
> >
> >
> >
> >
> > ___
> > freebsd-current@freebsd.org
> mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>
> > To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> "
> >
> ___
> freebsd-current@freebsd.org
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> "
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
Could you reply to that issue with what you've found? Though, as far as I can recall, igb(4) devices are not supposed to do the iflib reset talked about in the bug, so I wouldn't expect to see a link flap on those. - Eric On Fri, Nov 6, 2020 at 12:48 PM mike tancsa wrote: > On 11/6/2020 2:17 PM, mike tancsa wrote: > > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: > >> Hello Ian, > >> > >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: > >> > >>> I noticed that my VLAN interfaces stopped working after a recent > build. > >>> tcpdump showed traffic leaving leaving and entering the interface but > no > >>> host on the network actually received any packets from this host. A > >>> binary search led me to r360902 and indeed the following change fixed > >>> the issue for me: > >> Problem is, this change will return terrible situation when adding new > VLAN > >> will flap connection status. > >> > >> It all worked before iflib: hardware VLAN filtering worked, and > >> adding/removing new VLAN didn't cause link to flap. > >> > >> Now, with iflib, looks like we can not have all good things at once :( > > > Looks like this is captured in > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > > > > Hi All, > > > > Just came across this thread as I am running into this behaviour on > > RELENG_12. Adding a new vlan causes all vlans on the parent interface > > to flap. Not the greatest thing as it bounces a LOT of traffic > > potentially, flaps routing etc. Is there a way around this ? > > > > This is on r367411 releng12 > > > > igb0@pci0:2:0:0:class=0x02 card=0x153315d9 chip=0x15338086 > > rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'I210 Gigabit Network Connection' > > class = network > > subclass = ethernet > > > > eg. just something simple like > > > > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 > > > > # dmesg | tail -8 > > igb1: link state changed to DOWN > > vlan16: link state changed to DOWN > > vlan2049: link state changed to DOWN > > vlan15: link state changed to DOWN > > igb1: link state changed to UP > > vlan16: link state changed to UP > > vlan2049: link state changed to UP > > vlan15: link state changed to UP > > > > > > ---Mike > > > > > > > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 2:17 PM, mike tancsa wrote: > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: >> Hello Ian, >> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: >> >>> I noticed that my VLAN interfaces stopped working after a recent build. >>> tcpdump showed traffic leaving leaving and entering the interface but no >>> host on the network actually received any packets from this host. A >>> binary search led me to r360902 and indeed the following change fixed >>> the issue for me: >> Problem is, this change will return terrible situation when adding new VLAN >> will flap connection status. >> >> It all worked before iflib: hardware VLAN filtering worked, and >> adding/removing new VLAN didn't cause link to flap. >> >> Now, with iflib, looks like we can not have all good things at once :( Looks like this is captured in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > Hi All, > > Just came across this thread as I am running into this behaviour on > RELENG_12. Adding a new vlan causes all vlans on the parent interface > to flap. Not the greatest thing as it bounces a LOT of traffic > potentially, flaps routing etc. Is there a way around this ? > > This is on r367411 releng12 > > igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I210 Gigabit Network Connection' > class = network > subclass = ethernet > > eg. just something simple like > > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 > > # dmesg | tail -8 > igb1: link state changed to DOWN > vlan16: link state changed to DOWN > vlan2049: link state changed to DOWN > vlan15: link state changed to DOWN > igb1: link state changed to UP > vlan16: link state changed to UP > vlan2049: link state changed to UP > vlan15: link state changed to UP > > > ---Mike > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
