RE: [PATCH net-next] bridge: multicast to unicast
> -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Stephen Hemminger > Envoyé : samedi 7 janvier 2017 04:14 > À : Linus Lüssing > Cc : net...@vger.kernel.org; David S . Miller; bridge@lists.linux- > foundation.org; linux-kernel@vger.kernel.org; linux- > wirel...@vger.kernel.org; Felix Fietkau > Objet : Re: [PATCH net-next] bridge: multicast to unicast > > On Mon, 2 Jan 2017 20:32:14 +0100 > Linus Lüssingwrote: > > > This feature is intended for interface types which have a more > > reliable and/or efficient way to deliver unicast packets than > > broadcast ones (e.g. wifi). > > > Why is this not done in MAC80211 rather than bridge? OTOH mac80211 has more information to decide whether it is more economic to send one multicast or several unicast. It depends on the bitrate of each station, number of stations and the (not necessarily slower) bitrate of multicasts.
RE: [PATCH net-next] bridge: multicast to unicast
> -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] De la part de Stephen Hemminger > Envoyé : samedi 7 janvier 2017 04:14 > À : Linus Lüssing > Cc : net...@vger.kernel.org; David S . Miller; bridge@lists.linux- > foundation.org; linux-kernel@vger.kernel.org; linux- > wirel...@vger.kernel.org; Felix Fietkau > Objet : Re: [PATCH net-next] bridge: multicast to unicast > > On Mon, 2 Jan 2017 20:32:14 +0100 > Linus Lüssing wrote: > > > This feature is intended for interface types which have a more > > reliable and/or efficient way to deliver unicast packets than > > broadcast ones (e.g. wifi). > > > Why is this not done in MAC80211 rather than bridge? OTOH mac80211 has more information to decide whether it is more economic to send one multicast or several unicast. It depends on the bitrate of each station, number of stations and the (not necessarily slower) bitrate of multicasts.
RE: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: > "Tosoni" <[EMAIL PROTECTED]> writes: > > As far as I know in the old times this was the *standard* > way to use a modem > > (per CCITT V24), and even nowadays many modems can handle > this method for > > transmit, to stay compatible with the standard. > > I think it wasn't standard for real modems as they were full-duplex > (even these 1200/75 or what was that) but it was for other devices > such as current loops (which were frequently half-duplex). > It has always been the standard for all modems. The mistake comes from the fact that the serial ports has been used extensively to drive things which are *not* modems (say, printers and VT100 consoles on Unix systems). Such devices did not need the standard-specified RTS function. CCITT V24 says about RTS: "...this signal drives the DCE and sets it to transmit data..." (translated from french) CCITT V24 does not constraint the DCE to being half or full duplex. CCITT V24 says nothing about using RTS to handle flow control. > I've seen such devices quite recently, perhaps ~ 10 years ago. > OTOH I think even "current" PC BIOSes use such signaling. Even Windows implements the CCITT view of RTS, via a flag named "RTS_TOGGLE" > > > Think of radio modems. Some are inherently half duplex. > > Sure. But /dev/ttyS* ports are full-duplex, with CRTSCTS or without, > so they don't use such handshaking. A full duplex port can be used for both full- and half- duplex. A half duplex modem cannot be used on a full-duplex-only port. So Linux should be adapted to the standard, since we cannot adapt the standard to Linux. > /proc is probably no-no. Then sysfs sounds good to me. > > For such signaling, it would perhaps be better to invent another flag, > similar to CRTSCTS. The driver would, of course, need some real code > for that. Another flag would help to drive modems, yes. But it would not help keeping RTS low at open, because we need to open the port (which raises RTS) in order to set the flag. Hence the need for an extra parameter in sysfs. Best regards, Jean-Pierre Tosoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: Tosoni [EMAIL PROTECTED] writes: As far as I know in the old times this was the *standard* way to use a modem (per CCITT V24), and even nowadays many modems can handle this method for transmit, to stay compatible with the standard. I think it wasn't standard for real modems as they were full-duplex (even these 1200/75 or what was that) but it was for other devices such as current loops (which were frequently half-duplex). It has always been the standard for all modems. The mistake comes from the fact that the serial ports has been used extensively to drive things which are *not* modems (say, printers and VT100 consoles on Unix systems). Such devices did not need the standard-specified RTS function. CCITT V24 says about RTS: ...this signal drives the DCE and sets it to transmit data... (translated from french) CCITT V24 does not constraint the DCE to being half or full duplex. CCITT V24 says nothing about using RTS to handle flow control. I've seen such devices quite recently, perhaps ~ 10 years ago. OTOH I think even current PC BIOSes use such signaling. Even Windows implements the CCITT view of RTS, via a flag named RTS_TOGGLE Think of radio modems. Some are inherently half duplex. Sure. But /dev/ttyS* ports are full-duplex, with CRTSCTS or without, so they don't use such handshaking. A full duplex port can be used for both full- and half- duplex. A half duplex modem cannot be used on a full-duplex-only port. So Linux should be adapted to the standard, since we cannot adapt the standard to Linux. /proc is probably no-no. Then sysfs sounds good to me. For such signaling, it would perhaps be better to invent another flag, similar to CRTSCTS. The driver would, of course, need some real code for that. Another flag would help to drive modems, yes. But it would not help keeping RTS low at open, because we need to open the port (which raises RTS) in order to set the flag. Hence the need for an extra parameter in sysfs. Best regards, Jean-Pierre Tosoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: > OTOH I wonder what does the device in question require WRT the > serial port and WRT RTS line in particular. > I know there are some half-duplex converters which drive RTS only > while sending and which require CTS to send. As far as I know in the old times this was the *standard* way to use a modem (per CCITT V24), and even nowadays many modems can handle this method for transmit, to stay compatible with the standard. Think of radio modems. Some are inherently half duplex. > They are perhaps a bit broken No, no, they apply an old standard. Probably they are old as well. > > I don't know if one can expect RTS to stay low all the time. Even > a simple /sbin/setserial from /etc/rc.* would drive it high for > a moment. I'm afraid the only way which makes sense may be using > a customized plug. It's a pity that Linux (or Unixes) never handled RTS this way. I feel that the /proc or sysfs solutions are the best to alter this well established default in this driver. It would not break existing installed hardware. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: OTOH I wonder what does the device in question require WRT the serial port and WRT RTS line in particular. I know there are some half-duplex converters which drive RTS only while sending and which require CTS to send. As far as I know in the old times this was the *standard* way to use a modem (per CCITT V24), and even nowadays many modems can handle this method for transmit, to stay compatible with the standard. Think of radio modems. Some are inherently half duplex. They are perhaps a bit broken snip No, no, they apply an old standard. Probably they are old as well. I don't know if one can expect RTS to stay low all the time. Even a simple /sbin/setserial from /etc/rc.* would drive it high for a moment. I'm afraid the only way which makes sense may be using a customized plug. It's a pity that Linux (or Unixes) never handled RTS this way. I feel that the /proc or sysfs solutions are the best to alter this well established default in this driver. It would not break existing installed hardware. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/