Thanks for the reply. We looked at your module and found it interesting that you avoided to change the core.
Our code marks each buffer flush individually. We can control the ToS for each request even when using keep-alive (using the X-Accel-ClassID header). After the response has been sent the ToS is reset back to the default (location configuration). In your module you mark only at the beginning of the response (at the header filter stage). Don't you have problems with different requests using the same connection? You can only have one ToS mark for each location if you relying on a static configuration. Can it be set by variable "tos $class_id" ? It may be interesting to merge our patch with your module... Dani On Tue, 16 Dec 2014 15:46:36 +0000 Maxim Dounin <mdou...@mdounin.ru> wrote: > Hello! > > On Tue, Dec 16, 2014 at 02:21:59PM +0000, Dani Bento wrote: > > > Hello, > > > > We are using nginx-1.6 in a production environment for caching data > > from multiple remote origins. > > > > To improve our data distribution over the network we thought that > > using IP DiffServ/ToS to traffic shape by backend would be useful. > > > > We developed a small patch for the nginx core to mark packets. > > Because the nginx workers don't seem to have CAP_NET_ADMIN > > privileges we are using the TOS field instead of socket marks. This > > patch only marks client packets and not upstream/backend packets. > > I had a module to set IP ToS for serveral years now, see here: > > http://mdounin.ru/hg/ngx_http_ip_tos_filter_module/ > > It doesn't seem to be used much though, and hence we don't import > it (or an equivalent code) into nginx, at least yet. > > > Besides that, we added an X-Accel-ClassID header so that the > > upstream/backend itself can choose the class id to use. > > This doesn't looks like a good solution for me. If you want > allow backends to control ToS set, it may be a better idea to > support variables in the directive in question. > > > Do you find this an interesting feature to add to the nginx core? > > How can we proceed and submit a patch? > > See above. Just in case, some general guidelines on submitting > patches can be found here: > > http://nginx.org/en/docs/contributing_changes.html > -- Dani Bento Direção de Internet e Tecnologia DTS/DVS tlm: +351 91 429 72 81 d...@telecom.pt _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
