Prev: [PATCH 06/37] x86: call early_res_to_bootmem one time
Next: lockdep: Add information of file and line to lockdep_map
From: Ha, Tristram on 19 Jan 2010 19:00
Stephen Hemminger wrote:
>> Now for the driver implementation for STP support. I programmed the
>> switch's static MAC table to always pass the following frames to the
>> host: BPDU frames with specific multicast address, broadcast frames,
>> unicast frames with the device bridge's MAC address, and multicast
>> frames with ICMPv6 multicast address. All other frames are not
passed
>> to the host and are handled by the switch, forwarding each frame with
>> its standard forwarding logic. The port can be shut off if it is
>> blocked and those frames will not pass through that port. The host
>> gets BPDU frames so that the bridge can determine each port's state.
>> The other broadcast, unicast, and multicast frames passed to the host
>> are necessary if some other network devices want to communicate with
>> the host. As the forwarding is done by hardware rather than
software,
>> overall performance does increase.
>
> What about LACP needed by bridging?
>

I am not aware of LACP and do not know how this protocol works under
bridging. If the requirement is certain multicast frames do not get
forwarded and must pass to the host bridge, I can add those fixed
multicast addresses. The static MAC table has 8 entries, so there are 4
more to use.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ha, Tristram on 19 Jan 2010 19:20
Alan Cox wrote:
>>> If you make a private copy of pdev in your struct you should
>>> refcount
>> it and use
>>> pci_dev_get/pci_dev_put when you take and release the reference.
>
>> I do not understand how pci_dev_get/pci_dev_put work. Does the pdev
>> pointer actually change during the lifetime of the PCI driver?
>
> No but it can go away if the device is removed. The pci_dev_get
ensures it won't go away while
> you have a pointer to it. and the pci_dev_put gives up your reference.

>

If the PCI device is removed, like physically removing the card,
shouldn't the kernel also close the network device assocated with the
PCI device? The driver does actually cleanup the network devices and
free all memory when the pci remove function is called.

From the PCI network drivers included in the kernel I found most drivers
use pci_dev_put only on devices that are outside their own PCI devices,
retrieved from the pci_get_device call. (They never call pci_dev_get.)
That makes sense as those PCI devices are outside PCI driver control.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Hemminger on 19 Jan 2010 19:20
On Tue, 19 Jan 2010 15:48:50 -0800
"Ha, Tristram" <Tristram.Ha(a)Micrel.Com> wrote:

> Stephen Hemminger wrote:
> >> Now for the driver implementation for STP support. I programmed the
> >> switch's static MAC table to always pass the following frames to the
> >> host: BPDU frames with specific multicast address, broadcast frames,
> >> unicast frames with the device bridge's MAC address, and multicast
> >> frames with ICMPv6 multicast address. All other frames are not
> passed
> >> to the host and are handled by the switch, forwarding each frame with
> >> its standard forwarding logic. The port can be shut off if it is
> >> blocked and those frames will not pass through that port. The host
> >> gets BPDU frames so that the bridge can determine each port's state.
> >> The other broadcast, unicast, and multicast frames passed to the host
> >> are necessary if some other network devices want to communicate with
> >> the host. As the forwarding is done by hardware rather than
> software,
> >> overall performance does increase.
> >
> > What about LACP needed by bridging?
> >
>
> I am not aware of LACP and do not know how this protocol works under
> bridging. If the requirement is certain multicast frames do not get
> forwarded and must pass to the host bridge, I can add those fixed
> multicast addresses. The static MAC table has 8 entries, so there are 4
> more to use.

Anything 01:80:C2:00:00:00 should go local host.
LACP is part of 802.3ad bonding and uses 01:80:C2:00:02

In general anything to 01:80:C2:00:00:XX is likely to be
used by some IEEE 802 standard for link only multicast.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ha, Tristram on 19 Jan 2010 19:40
Stephen Hemminger wrote:
> On Tue, 19 Jan 2010 15:48:50 -0800
> "Ha, Tristram" <Tristram.Ha(a)Micrel.Com> wrote:
>
>> Stephen Hemminger wrote:
>>>> Now for the driver implementation for STP support. I programmed
>>>> the switch's static MAC table to always pass the following frames
>>>> to the
>>>> host: BPDU frames with specific multicast address, broadcast
>>>> frames, unicast frames with the device bridge's MAC address, and
>>>> multicast frames with ICMPv6 multicast address. All other frames
>>>> are not
>> passed
>>>> to the host and are handled by the switch, forwarding each frame
>>>> with its standard forwarding logic. The port can be shut off if it
>>>> is blocked and those frames will not pass through that port. The
>>>> host gets BPDU frames so that the bridge can determine each port's
state.
>>>> The other broadcast, unicast, and multicast frames passed to the
>>>> host are necessary if some other network devices want to
>>>> communicate with the host. As the forwarding is done by hardware
>>>> rather than
>> software,
>>>> overall performance does increase.
>>>
>>> What about LACP needed by bridging?
>>>
>>
>> I am not aware of LACP and do not know how this protocol works under
>> bridging. If the requirement is certain multicast frames do not get
>> forwarded and must pass to the host bridge, I can add those fixed
>> multicast addresses. The static MAC table has 8 entries, so there
are
>> 4 more to use.
>
> Anything 01:80:C2:00:00:00 should go local host.
> LACP is part of 802.3ad bonding and uses 01:80:C2:00:02
>
> In general anything to 01:80:C2:00:00:XX is likely to be used by some
IEEE 802 standard for link
> only multicast.

If the strict requirement is to support all 01:80:C2:00:00:XX multicast
addresses, my scheme will not work. It was designed only for STP, as
most our customers request that feature.

I will pass your suggestions to our hardware engineers so that they can
develop a better switch engine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Hemminger on 19 Jan 2010 20:00
On Tue, 19 Jan 2010 16:34:38 -0800
"Ha, Tristram" <Tristram.Ha(a)Micrel.Com> wrote:

> Stephen Hemminger wrote:
> > On Tue, 19 Jan 2010 15:48:50 -0800
> > "Ha, Tristram" <Tristram.Ha(a)Micrel.Com> wrote:
> >
> >> Stephen Hemminger wrote:
> >>>> Now for the driver implementation for STP support. I programmed
> >>>> the switch's static MAC table to always pass the following frames
> >>>> to the
> >>>> host: BPDU frames with specific multicast address, broadcast
> >>>> frames, unicast frames with the device bridge's MAC address, and
> >>>> multicast frames with ICMPv6 multicast address. All other frames
> >>>> are not
> >> passed
> >>>> to the host and are handled by the switch, forwarding each frame
> >>>> with its standard forwarding logic. The port can be shut off if it
> >>>> is blocked and those frames will not pass through that port. The
> >>>> host gets BPDU frames so that the bridge can determine each port's
> state.
> >>>> The other broadcast, unicast, and multicast frames passed to the
> >>>> host are necessary if some other network devices want to
> >>>> communicate with the host. As the forwarding is done by hardware
> >>>> rather than
> >> software,
> >>>> overall performance does increase.
> >>>
> >>> What about LACP needed by bridging?
> >>>
> >>
> >> I am not aware of LACP and do not know how this protocol works under
> >> bridging. If the requirement is certain multicast frames do not get
> >> forwarded and must pass to the host bridge, I can add those fixed
> >> multicast addresses. The static MAC table has 8 entries, so there
> are
> >> 4 more to use.
> >
> > Anything 01:80:C2:00:00:00 should go local host.
> > LACP is part of 802.3ad bonding and uses 01:80:C2:00:02
> >
> > In general anything to 01:80:C2:00:00:XX is likely to be used by some
> IEEE 802 standard for link
> > only multicast.

I wouldn't worry about anything but STP.

> If the strict requirement is to support all 01:80:C2:00:00:XX multicast
> addresses, my scheme will not work. It was designed only for STP, as
> most our customers request that feature.
>
> I will pass your suggestions to our hardware engineers so that they can
> develop a better switch engine.

It is fine as is, just a warning of what standards committees are
likely to invent in future.

--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [PATCH 06/37] x86: call early_res_to_bootmem one time
Next: lockdep: Add information of file and line to lockdep_map