* Must dev->set_multicast_list() complete before returning?
@ 2003-04-01 17:26 Rask Ingemann Lambertsen
0 siblings, 0 replies; 5+ messages in thread
From: Rask Ingemann Lambertsen @ 2003-04-01 17:26 UTC (permalink / raw)
To: linux-net, netdev
Hi.
Must dev->set_multicast_list() complete the configuration of a network device before returning?
Regards,
Rask Ingemann Lambertsen
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Must dev->set_multicast_list() complete before returning?
[not found] <3e89cbe235cd78.41777977@not right>
@ 2003-04-02 3:50 ` Donald Becker
2003-04-02 13:09 ` Rask Ingemann Lambertsen
2003-04-02 16:18 ` David Brownell
0 siblings, 2 replies; 5+ messages in thread
From: Donald Becker @ 2003-04-02 3:50 UTC (permalink / raw)
To: Rask Ingemann Lambertsen; +Cc: linux-net, netdev
On Tue, 1 Apr 2003, Rask Ingemann Lambertsen wrote:
> Must dev->set_multicast_list() complete the configuration of a network
> device before returning?
The promiscuous setting must complete before return, but there are
several drivers where the updated multicast filter does not immediately
take effect.
I have not seen hardware where setting promiscuous mode is a queued
command. If you have such hardware, you may have to do some extra
software filtering and accept missing some packets during transitions.
--
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Must dev->set_multicast_list() complete before returning?
2003-04-02 3:50 ` Must dev->set_multicast_list() complete before returning? Donald Becker
@ 2003-04-02 13:09 ` Rask Ingemann Lambertsen
2003-04-02 16:18 ` David Brownell
1 sibling, 0 replies; 5+ messages in thread
From: Rask Ingemann Lambertsen @ 2003-04-02 13:09 UTC (permalink / raw)
To: linux-net, netdev
Donald Becker wrote:
> The promiscuous setting must complete before return, but there are
> several drivers where the updated multicast filter does not immediately
> take effect.
>
> I have not seen hardware where setting promiscuous mode is a queued
> command.
Intel i82586, i82596 and, as far as I can tell from other drivers, several other Intel i825xx Ethernet chips. IIRC, the function must not sleep. That means busy-wait for it to complete. :-(
Regards,
Rask Ingemann Lambertsen
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Must dev->set_multicast_list() complete before returning?
2003-04-02 3:50 ` Must dev->set_multicast_list() complete before returning? Donald Becker
2003-04-02 13:09 ` Rask Ingemann Lambertsen
@ 2003-04-02 16:18 ` David Brownell
2003-04-02 19:40 ` Donald Becker
1 sibling, 1 reply; 5+ messages in thread
From: David Brownell @ 2003-04-02 16:18 UTC (permalink / raw)
To: Donald Becker; +Cc: Rask Ingemann Lambertsen, linux-net, netdev
Donald Becker wrote:
>
> I have not seen hardware where setting promiscuous mode is a queued
> command. If you have such hardware, you may have to do some extra
> software filtering and accept missing some packets during transitions.
Every USB network adapter will need to queue such commands,
unless they don't support such operations at all. So you
have probably seen such hardware, without realizing it!
I just looked ... none of them do any extra filtering.
- Dave
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Must dev->set_multicast_list() complete before returning?
2003-04-02 16:18 ` David Brownell
@ 2003-04-02 19:40 ` Donald Becker
0 siblings, 0 replies; 5+ messages in thread
From: Donald Becker @ 2003-04-02 19:40 UTC (permalink / raw)
To: David Brownell; +Cc: Rask Ingemann Lambertsen, linux-net, netdev
On Wed, 2 Apr 2003, David Brownell wrote:
> Donald Becker wrote:
> >
> > I have not seen hardware where setting promiscuous mode is a queued
> > command. If you have such hardware, you may have to do some extra
> > software filtering and accept missing some packets during transitions.
>
> Every USB network adapter will need to queue such commands,
> unless they don't support such operations at all. So you
> have probably seen such hardware, without realizing it!
Errrm, a previous message pointed out to me that there were several
other Intel chips that _I had written drivers for_ that queue commands.
And yes, I had also forgotten about bridged NICs such as USB (which I've
also written drivers for).
> I just looked ... none of them do any extra filtering.
I've not added extra filtering to any driver USB or otherwise.
It may be that there is a problem here that is rarely encountered and
never identified as a problem. A filter change from promiscuous to
normal mode is at worst a narrow window.
The atp.c driver is special because it put the hardware into promiscuous
mode for allmulti, and thus any potential problem became a continuous
issue.
Alan, do you remember what piece of code had a problem with unicast
packets to other hosts that would normally be filtered out by the
hardware? It may be that issue is gone with 2.4 and later kernels.
(Multicast is not an issue because most chips use an imperfect hash
filter and thus the kernel has always needed additional filtering.)
--
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-04-02 19:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <3e89cbe235cd78.41777977@not right>
2003-04-02 3:50 ` Must dev->set_multicast_list() complete before returning? Donald Becker
2003-04-02 13:09 ` Rask Ingemann Lambertsen
2003-04-02 16:18 ` David Brownell
2003-04-02 19:40 ` Donald Becker
2003-04-01 17:26 Rask Ingemann Lambertsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).