User Tools

Site Tools


en:developers:summits:ottawa-2015

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
en:developers:summits:ottawa-2015 [2015/02/15 13:38]
Robert Copeland fix formatting
en:developers:summits:ottawa-2015 [2015/02/15 18:24]
Johannes Berg
Line 40: Line 40:
 == Notes == == Notes ==
   * netconf recap   * netconf recap
-    * add sysctl knobs for filtering ​route lookup for hotspot 2.0+    * add sysctl knobs for client-side ​filtering ​(needing ​route lookupfor hotspot 2.0
       * need to do a route lookup in ipv4 for mcast -- can't tell whether something is multicast or unicast without knowing the netmask       * need to do a route lookup in ipv4 for mcast -- can't tell whether something is multicast or unicast without knowing the netmask
 +      * 4 new knobs
 +        * drop-unicast-IPv4-in-multi/​broadcast-L2 (even for RFC SHOULD compliance)
 +          * originally suggested code in IP stack broke cluster ip, so sysctl needed
 +        * same for IPv6
 +        * drop gratuitous ARP
 +        * drop unsolicited NA
     * proxy arp     * proxy arp
     * perceived difficult to add stuff to bridging code     * perceived difficult to add stuff to bridging code
-    * drop certain unicast frames do it in the IP stack? breaks cluster ip, so unlikely to happen there 
     * some feedback from mac80211 on queuing time to improve transmit time     * some feedback from mac80211 on queuing time to improve transmit time
   * new wiki   * new wiki
Line 69: Line 74:
     * intel: build AMSDU for TSO frames     * intel: build AMSDU for TSO frames
       * take one TSO packet, split into AMSDUs       * take one TSO packet, split into AMSDUs
-      * doing segmentation in TCP stack: have to have some delays, or put in HW queue to do AMPDUs +      * doing AMSDUs without help from TCP stack: have to have some delays, or put in HW queue to do AMPDUs 
-      * problem: w/TSO packets can get really large, AMSDUs max out at 4/8k +      * problem: w/ TSO packets can get really large, AMSDUs max out at 4/8k 
-      * when packets don't fit in AMSDU, we have to split them and generate new PNs.  If we can guarantee TSO limit, then host can still generate sequence numbers +      * when packets don't fit in AMSDU, we have to split them and generate new PNs.  If we can guarantee TSO limit, then mac80211 ​can still PNs 
-    * Eric: per-flow limit for TSO/GSO exist, and MSS limits, you need both+    * Eric: per-flow ​size limit for TSO/GSO exist, and packet ​limits, you need both to protect against peers using tiny MSS
     * can we start small and increase size once we have some traffic with the stations?     * can we start small and increase size once we have some traffic with the stations?
     * terminology:​ "​DSO"​ - driver segmentation offload     * terminology:​ "​DSO"​ - driver segmentation offload
Line 134: Line 139:
   * hw address from userspace   * hw address from userspace
     * mfr's want to separate mac address from otp area     * mfr's want to separate mac address from otp area
-    * firmware is 6 bytes long and includes ​mac address+    * "firmware" file that is 6 bytes long and has mac address
     * some people don't want to add device with empty mac and configure it later     * some people don't want to add device with empty mac and configure it later
     * using same interface as firmware loader could be problematic (e.g. would mac address files need to be signed?)     * using same interface as firmware loader could be problematic (e.g. would mac address files need to be signed?)
Line 147: Line 152:
     * new attributes in the connect and roaming events     * new attributes in the connect and roaming events
     * can use exisitng nl80211 attributes in vendor commands to avoid copying them?  not validated     * can use exisitng nl80211 attributes in vendor commands to avoid copying them?  not validated
 +    * problem: vendor extensions could completely change semantics?
   * bt coex subsystem   * bt coex subsystem
     * wireless wants to know BT states, might not have a gpio or register in common, or be on separate chip from BT     * wireless wants to know BT states, might not have a gpio or register in common, or be on separate chip from BT
Line 160: Line 166:
     * need to make sure statistics, crypto are still functional     * need to make sure statistics, crypto are still functional
     * Jouni: this can cause fragmentation of features across drivers     * Jouni: this can cause fragmentation of features across drivers
-  * opw - Luis+  * opw - Jes
     * converting orinoco to cfg80211     * converting orinoco to cfg80211
- 
- 
  
en/developers/summits/ottawa-2015.txt · Last modified: 2015/02/27 08:03 by Johannes Berg