5 ms·

These are complex parts of the kernel and since they impact virtually any user getting anything wrong is bad. It takes a while to merge such changes and to even

by baruch 11y ago

These are complex parts of the kernel and since they impact virtually any user getting anything wrong is bad. It takes a while to merge such changes and to even just get them right in order to feel fine with submitting such changes. I've worked in an area close to that (TCP performance tuning), my patches never made it to the kernel. Someone else later came and took a slightly different approach and wrote a much cleaner code and got the changes in. Small patches are rather easy to get applied, more intrusive ones (and changing locks is highly intrusive) is much harder. Not impossible though and the reward (for the community) is high, the internal feeling for succeeding is also great :-)

iheartmemcache 11y ago
A compare and contrast of your code vs their code would be awesome to see. E.g., an analysis of the difference between the two approaches and why his managed to get pulled upstream and yours didn't. Perhaps, a retrospective on what you would have changed as well.
- baruch 11y ago
  There are few small patches of mine that did enter: 8a3c3a9 [TCP]: Check num sacks in SACK fast path 6f74651 [TCP]: Seperate DSACK from SACK fast path fda03fb [TCP]: Advance fast path pointer for first block only db3ccda [TCP]: Fix sorting of SACK blocks. One can find the accepted patches from Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> in the git history log. I'm trying to find my old patches. Look for commits from 2006-2007 which are mostly relevant to this topic. The big issue was that the retransmit list was over 10,000 items long and SACK/DSACK/retransmit loops needed to traverse this list from the start for each new packet that arrived. It made transmission fall in performance when doing 100Mbps at 200msec latency (high Bandwidth Delay Product means a very large queue of inflight packets). Edit: I found a set of patches but to do a proper analysis will take me just too much time that I prefer to invest into new things. Maybe I'll do that when I will want a distraction from my current projects :-)
baruch 11y ago
An addition to that is that getting things right sometimes takes multiple attempts, at least for me. I've seen that in that work I attempted to do for the Linux Kernel TCP stack and also in prior and later work related projects. Large sweeping changes may require familiarization with a large body of code and the impacts of any single change to the overall system behavior. This may be well intentioned and a good direction but the details may prove a pitfall if a slightly bad turn is taken. At that point you need to backtrack and that backtracking takes a while to conclude it is needed and to find a different approach that will work. Sometimes it takes time to realize that a direction is incorrect and a backtrack is needed and then some more time to clear your head off and find the right approach.

by baruch 11y ago

iheartmemcache 11y ago

A compare and contrast of your code vs their code would be awesome to see. E.g., an analysis of the difference between the two approaches and why his managed to get pulled upstream and yours didn't. Perhaps, a retrospective on what you would have changed as well.

baruch 11y ago
There are few small patches of mine that did enter: 8a3c3a9 [TCP]: Check num sacks in SACK fast path 6f74651 [TCP]: Seperate DSACK from SACK fast path fda03fb [TCP]: Advance fast path pointer for first block only db3ccda [TCP]: Fix sorting of SACK blocks. One can find the accepted patches from Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> in the git history log. I'm trying to find my old patches. Look for commits from 2006-2007 which are mostly relevant to this topic. The big issue was that the retransmit list was over 10,000 items long and SACK/DSACK/retransmit loops needed to traverse this list from the start for each new packet that arrived. It made transmission fall in performance when doing 100Mbps at 200msec latency (high Bandwidth Delay Product means a very large queue of inflight packets). Edit: I found a set of patches but to do a proper analysis will take me just too much time that I prefer to invest into new things. Maybe I'll do that when I will want a distraction from my current projects :-)

baruch 11y ago

An addition to that is that getting things right sometimes takes multiple attempts, at least for me. I've seen that in that work I attempted to do for the Linux Kernel TCP stack and also in prior and later work related projects. Large sweeping changes may require familiarization with a large body of code and the impacts of any single change to the overall system behavior. This may be well intentioned and a good direction but the details may prove a pitfall if a slightly bad turn is taken. At that point you need to backtrack and that backtracking takes a while to conclude it is needed and to find a different approach that will work. Sometimes it takes time to realize that a direction is incorrect and a backtrack is needed and then some more time to clear your head off and find the right approach.