Re: Improving qos_flows mark feature - obtaining mark later

On Mon, 2011-10-17 at 10:03 +0200, Kinkie wrote:
> On Mon, Oct 17, 2011 at 5:30 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> > On 17/10/11 11:23, Andrew Beverley wrote:
> >>
> >> Hi,
> >>
> >> I've been using the qos_flows feature for preserving a netfilter mark,
> >> but have run into some problems.
> >>
> >> Currently, the netfilter mark for the connection is obtained in
> >> forward.cc, during the stages of opening a connection to the remote
> >> server. The problem with this is that the connection mark may change
> >> once the reply is received.
> >>
> >> So, I would like to move Ip::Qos::getNfmarkFromServer() from
> >> FwdState::dispatch to a function that is called during the server reply
> >> stage. However, I can't work out where it should go.
> >>
> >> I've looked at moving it to client_side_reply.cc, but I can't find a way
> >> to retrieve the remote server connection information. I've also looked
> >> at comm_read() in comm.cc, but I can't find the client connection
> >> information and it looks like the wrong place anyway.
> >>
> >> Where is the best place to move it to, where it has access to both the
> >> client and server side connection, but where it is late enough to read
> >> the mark value if it changes during the server reply?
> >>
> >> Hope this makes sense!
> >>
> >
> > FwdState::dispatch is called at the start of Server request sending. TO
> > start the construction and write of request headers to the server.
> >
> > For persistent and pinned connections it is essentially in the pause
> > position between end of reading one reply and start of sending the next
> > request.
> >
> > I think you mean that it may change on reading the first bytes of reply,
> > yes?
> >
> > In which case the best position is in HttpStateData::processReplyHeader().
> > With matching positions in ftp.cc and tunnel.cc reply starting handlers.
> > The server connection is produced by a method dataConnection() of the state
> > object.
> > The client connection is not exposed. Although it could be. It is in the
> > parent ServerStateData::FwdState::clientConn.
>
> Instead of moving it , why not doing both control points? like
> http_access / http_reply_access.
> It shouldn't hurt performance, and give greater flexibility..

I don't think that there is much point to having it in both places, as
the value is only used when sending data to the client.

Something like this will happen: the mark will be retrieved during the
request to the server and saved (as now); the mark will then be
retrieved again during the server reply; and then the mark will be used
to mark packets leaving Squid to the client.

I think it makes sense just to retrieve the mark during the server reply
stage and use that.

Andy
Received on Mon Oct 31 2011 - 21:07:21 MDT