Tuesday, December 15, 2015< ^ >
Thomas Watteyne has set the subject to: IETF93 ROLL WG meeting
Room Configuration
Room Occupants

[09:52:20] eintopf joins the room
[09:54:54] <eintopf>
[09:55:04] <eintopf> sorry I just see you answer on these logs
[09:55:16] eintopf doesn't like logs in chatrooms
[09:56:44] <eintopf> I meant there: I thought it can be $CTX_TABLE_A[DCI] != $CTX_TABLE_B[SCI]
[09:56:59] <eintopf> then it _could_ be the prefix can be different
[09:57:10] <eintopf> but it's only one table
[09:57:25] <eintopf> I believe so
[09:58:02] <eintopf> @(then it _could_ be the prefix can be different) in case of DCI == SCI
[09:58:31] <eintopf> but then $CTX_TABLE[DCI] == $CTX_TABLE[SCI] it must be the same prefix
[10:00:12] <eintopf> and I don't know how to handle multicast stateful compression if the prefix len is above 64. I mean, it can't be that the prefix is above 64 because it's the network_prefix of multicast address. Currently I cut-off and copy 8 bytes only from prefix and look if the address match.
[10:02:15] <eintopf> maybe I should drop it if it looks invalid.
[10:04:54] <eintopf> anyway, I think there are more bugs than this. We should have something which we can work on.
[10:11:51] <eintopf> that's the whole thing which I submitted, also with radvd patches. The most people don't know "how it can be working". This is one solution, if it's the best solution? I don't think so..., but this is why we are open source. I am little afraid to introducing UAPI, because UAPI should be never changed and torvalds doesn't like that.
[10:13:46] <eintopf> For example: the ctx_table UAPI, if we move that to sysfs. I also can imagine to introduce "commands" echo "add ..."/"del/"set"(for c flag)/..., for now we update static entries and the application need to have to remind "how does the ctx table inside the kernel looks like". Both has they advantages and disadvantages
[10:14:51] <eintopf> anyway, the "command way" can also be a second UAPI for the ctx_table, if it's better we deprecate the other one and delete it in ~2 years.
[15:11:18] <mcr2> yes, it's one table.
[15:11:42] <mcr2> you can ask about the multicast situation on the 6lo list.
[15:12:44] <mcr2> I'd like to just have 16 files that userspace can write into...
[16:40:51] <eintopf> ah
[16:40:52] <eintopf> 16 files...
[16:41:10] <eintopf> current solution is one file :D
[16:43:02] <eintopf> so you want some subdirectory ctx/0, ctx/1, ctx/2, ctx/3 ... upto ctx/15
[16:46:35] <eintopf> one file means, you can always update a entry by write:
"$ID $PREFIX/$PREFIX_LEN $FLAG", the $ID will update the right line. To parse it you need some for (i = 0; i < 16; i++) and read each line and put it into $STATIC_16_ENTRY_TABLE.
[16:46:56] <eintopf> But I would say, don't parse it. Init with something at start and then remember all changes
[16:47:25] <eintopf> if some other programm manipulate the table -> things getting complex and races are there
[16:48:53] <eintopf> maybe you can getting notify about that with "inotify" this can inform you when somebody manipulates the file
[16:49:35] <eintopf> but you can't control "notify about file changes" and "parse/read the file again".
[16:50:48] <eintopf> you can't control it -> you can't control that nobody others do file changes again in the middle of that mechanism. I am not sure how to deal with that.
[17:05:22] <eintopf> or we do both
[17:06:24] <eintopf> we do the ctx_table to dump everything, then subdirectory ctx/$ID/{prefix, prefix_len, active, compression} files
[17:06:43] <eintopf> this has the benefit to make current changes without knowing the other values
[17:06:59] <eintopf> like if you want to change compression flag only
[17:13:53] <mcr2> I don't think it matters if something else messes with it...
[17:14:29] <mcr2> I like small simple files for each thing myself.  I thought that was the sysfs mantra :-)
[17:33:00] <eintopf> yes, not do it complex in sysfs
[17:33:37] <eintopf> I mean the parsing, should not complex
[17:34:13] <eintopf> okay, small simple files for each thing sounds good. :-)
[17:34:23] <eintopf> I will change that for a next RFC
[17:34:49] <eintopf> then I ask about stateful multicast thing, fine.
[17:35:57] <mcr2> thank you!
[20:15:28] <eintopf>
[20:15:35] <eintopf> now subfiles
[20:16:47] <eintopf> I did a 01, 02, etc. the order is wrong then by default ls. Don't know if it's a good idea
[20:17:03] <eintopf> applications need to build the pathstring somehow anyway
[21:09:46] <eintopf> good night
[21:10:37] eintopf leaves the room: Disconnected: closed
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!