On 07/09/14 18:31, Navdeep Parhar wrote:
On Wed, Jul 09, 2014 at 04:36:53PM +0200, Hans Petter Selasky wrote:
On 07/08/14 21:17, Navdeep Parhar wrote:
...
I think we need to design this to be as generic as possible. I have
quite a bit of code that does this stuff but I haven't pushed it
upst
On Wed, Jul 09, 2014 at 04:36:53PM +0200, Hans Petter Selasky wrote:
> On 07/08/14 21:17, Navdeep Parhar wrote:
...
> >
> >I think we need to design this to be as generic as possible. I have
> >quite a bit of code that does this stuff but I haven't pushed it
> >upstream or even offered it for revi
On 07/08/14 21:17, Navdeep Parhar wrote:
On 07/08/14 10:46, Hans Petter Selasky wrote:
Hi,
I'm working on a new feature which will allow TCP connections to be
timing controlled by the ethernet hardware driver, actually the mlxen
driver. The main missing piece in the kernel is to allow the mbuf'
Hi!
The flowid value has way, way too many possible meanings but it's
always been a mostly-static value. I'm worried about overriding it
with multiple meanings that cause features to not work at all
together.
So I'd rather leave the flowid/flowtype as it currently is so it
doesn't upset packet re
On 07/08/14 10:46, Hans Petter Selasky wrote:
> Hi,
>
> I'm working on a new feature which will allow TCP connections to be
> timing controlled by the ethernet hardware driver, actually the mlxen
> driver. The main missing piece in the kernel is to allow the mbuf's
> flowid value to be overwritten
Hi,
I'm working on a new feature which will allow TCP connections to be
timing controlled by the ethernet hardware driver, actually the mlxen
driver. The main missing piece in the kernel is to allow the mbuf's
flowid value to be overwritten in "struct inpcb" once the connection is
established
